Kubernetes 网络模型
Kubernetes 对网络设施的基本要求
Pod 能够与所有其它节点上的 Pod 相互通信, 且不需要网络地址转译(NAT)
节点上的代理(比如:系统守护进程、kubelet)可以和节点上的所有 Pod 相互通信
Kubernetes 网络解决四方面的问题
Pod中的容器之间可以通过本地回路(loopback)相互通信
集群网络在不同 Pod 之间提供通信
Service API 允许向外暴露 Pod 中运行的应用, 以支持来自于集群外部的访问
Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能
Service
-  K8S 可以保证任意 Pod 挂掉时自动从任意节点启动一个新的Pod进行代替,以及某个Pod超负载时动态对Pod进行扩容。每当 Pod 发生变化时其 IP地址也会发生变化,且Pod只有在K8S集群内部才可以被访问,为了解决Pod发生变化导致其IP动态变化以及对外无法访问的问题,K8S引进了 Service 的概念 
-  K8S 使用 Service 来管理同一组标签下的 Pod ,当外界需要访问 Pod 中的容器时,只需要访问 Service 的这个虚拟 IP 和端口,由 Service 把外界的请求转发给它背后的Pod 
Service暴露服务类型
1、ClusterIP(默认)
- 自动为当前Service分配虚拟IP,在不重启Service前提下该IP是不会改变的,只能在集群内部访问
2、NodePort
- 需要在K8S集群的所有 Node 节点上开放特定的端口【30000-32767】,通过(公网ip : 端口)访问Service服务。缺点:每个端口只能挂载一个Service,从安全角度讲开放更多的端口是存在一定风险的,从维护角度讲开放的端口越多维护的成本越大
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    # 默认情况下,为了方便起见,`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 可选字段
      # 默认情况下,为了方便起见,Kubernetes 控制平面会从某个范围内分配一个端口号(默认:30000-32767)
      nodePort: 30007
3、LoadBalancer
-  和Nodeport相似,目的都是向外暴露一个端口,但 LoadBalancer 模式需要开发者在K8S集群外部的公有云服务器上做一个负载均衡设备(当前主流的阿里云、腾讯云、华为云、微软云等等厂商都有提供相关收费的服务),外部服务发送到公有云服务上的请求都会被负载并转发到K8S集群中LoadBalancer服务上 
-  如果要在私网环境下测试LoadBalancer,必须要创建一个MetalLB, MetalLB相当于一个负载均衡器的角色 
-  LoadBalancer原理:外部请求首先被转发到外部LB负载设备,再通过匹配规则转发到k8s集群的任意node节点上,最终通过Service资源找到对应的pod 
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127
4、ExternalName
- 通过返回 CNAME 记录和对应值,可以将服务映射到 externalName 字段的内容(例如:foo.bar.example.com),无需创建任何类型代理
 注意:需要使用 kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才能使用 ExternalName 类型
apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com
Service代理模式
Service 创建成功后会通过 api-server 向 etcd 中写入相关配置信息,kube-proxy会监听创建好的配置信息并将最新的service配置信息转化成对应的访问规则,最终实现外网对Pod的访问。常见的service访问规则有:iptables 和 ipvs
1、iptables
kube-proxy 为 service 后端的每个Pod创建对应的iptables规则,当用户访问ClusterIP时,直接将发送到ClusterIP的请求重定向到Pod
 缺点:kube-proxy 不承担四层路由转发的角色,只负责创建iptables规则,无法实现LB策略
2、ipvs(性能高于iptables)
kube-proxy 监控Pod的变化并创建相应的ipvs规则,当用户访问ClusterIP时,直接将发送到ClusterIP的请求重定向到Pod
 相比于iptables,支持LB策略
3、切换到IPVS模式
- 查询当前代理模式
kubectl get pod -o wide -n kube-system | grep kube-proxy # 查新kube-proxy有关的pod

kubectl logs -n kube-system kube-proxy-7bst7

- ipvs 安装(K8S集群的所有节点安装)
# yum install -y ipvsadm.x86_64   # Centos
apt install -y ipvsadm ipset # Debian
ipvsadm -Ln # 查看ipvs模式开启状态

- 切换Sevice代理模式为ipvs(K8S集群的Master节点修改)
kubectl edit configmap kube-proxy -n kube-system # 编辑configmap将mode改为ipvs 

- 删除指定Pod
kubectl get pod -o wide -n kube-system | grep kube-proxy

kubectl delete pod kube-proxy-7bst7 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-9l7qr -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-cqht2 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-h8znm -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-l4p42 -n kube-system # 删除pod后自动创建新的Pod
kubectl delete pod kube-proxy-xlqtg -n kube-system # 删除pod后自动创建新的Pod

4、验证IPVS
# kubectl get service -o wide -n kube-system # 查询Service
#
NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE   SELECTOR
calico-typha   ClusterIP   10.96.26.184   <none>        5473/TCP                 13d   k8s-app=calico-typha
kube-dns       ClusterIP   10.96.0.2      <none>        53/UDP,53/TCP,9153/TCP   13d   k8s-app=kube-dns
# ipvsadm -Ln
#
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.111.30:6443          Masq    1      1          0
  -> 192.168.111.31:6443          Masq    1      1          0
  -> 192.168.111.32:6443          Masq    1      1          0
  
TCP  10.96.0.2:53 rr
  -> 10.244.166.141:53            Masq    1      0          0
UDP  10.96.0.2:53 rr
  -> 10.244.166.141:53            Masq    1      0          0
  
TCP  10.96.0.2:9153 rr
  -> 10.244.166.141:9153          Masq    1      0          0
  
TCP  10.96.26.184:5473 rr
  -> 192.168.111.40:5473          Masq    1      0          0
部署Nginx应用并对外访问
方式1:创建deployment并将其显示为Service
# kubectl create deployment <deployment名称> --image=<镜像> --replicas=<pod副本数量> -n <命名空间名称>
# kubectl expose deployment <deployment名称> --name=<Service名称> --type=<Service服务类型> --port=<service端口> --target-port=<容器端口> -n <命名空间名称>
#
# 强制删除Pod
# kubectl delete deployment <deployment名称> -n <命名空间名称> --force --grace-period=0
# kubectl delete pod <pod名称> -n <命名空间名称> --force --grace-period=0
# 
# 强制删除NameSpace
# kubectl delete ns <命名空间名称> --force --grace-period=0 
# kubectl get deployment,pods,service -n kube-system -o wide
# kubectl get deployment,pods,service -n dev -o wide
# kubectl describe -n kube-system pod podName
#
# kubectl delete ns dev --force --grace-period=0 
# kubectl delete deployment nginx -n dev --force --grace-period=0
# kubectl delete pod podName -n dev --force --grace-period=0
- 创建 Deployment
kubectl create ns dev && kubectl get ns dev
kubectl create deployment nginx --image=nginx --replicas=1 -n dev # 级联创建Pod
# kubectl get deployment,pods -n dev -o wide # 查看创建的Deployment和Pod信息
# kubectl logs -n dev nginx-748c667d99-phdxv # 查看Pod创建的日志
# kubectl describe -n dev pod nginx-748c667d99-phdxv # 查看Pod创建的详细信息
- 暴露 Deployment 为 Service 服务(将Service的8080端口转发至容器的80端口)
kubectl expose deployment nginx --name=nginx --type=NodePort --port=8080 --target-port=80 -n dev
方式2:创建Service(yaml文件)
注意:基于Kubernetes Pod和工作负载文章已创建好的资源进行演示
- 创建 Service
vi service-nginx.yaml # 在线编辑文件
apiVersion: v1
kind: Service
metadata:
  namespace: dev
  name: nginx
  labels: 
      app: nginx
spec: 
  selector: # 标签选择器,指定对哪些deployment的Pod进行暴露
    app: nginx # deployment名称
  type: NodePort # Service暴露服务的类型
  ports:
  - protocol: TCP # 通讯协议
    nodePort: 30000 # Node端口,结合 type: NodePort 使用
    port: 8080 # service端口
    targetPort: 80 # pod端口
kubectl create -f service-nginx.yaml
kubectl delete -f service-nginx.yaml
- 查看已创建的资源
kubectl get deployment,replicaSet,pods,service -n dev -o wide --show-labels

curl 10.244.104.10:80 # 任意Node节点,通过Pod的IP访问nginx
curl 10.244.166.157:80 # 任意Node节点,通过Pod的IP访问nginx
curl 10.96.73.217:8080 # 任意Node节点,通过Service的IP访问Nginx
http://192.168.111.40:30000 # 浏览器通过任意Node节点访问nginx
http://192.168.111.41:30000 # 浏览器通过任意Node节点访问nginx
http://192.168.111.42:30000 # 浏览器通过任意Node节点访问nginx
Ingress
Ingress(k8s内置的资源对象)
- Ingress 是 k8s 的资源对象,用于定义外部的(HTTP 和 HTTPS)请求如何转发到 Service 服务的规则
  
ingress-controller(需要单独安装)
-  ingress-controller 不是 k8s 自带的组件,只是一个统称,可以选择不同的 ingress-controller 实现对 service 的反向代理及负载均衡,常用的 ingress-controller 产品有:F5 Networks、Kong、Traefik、NGINX、HaProxy、Istio 
-  ingress-controller 本质是一个 pod,内部运行了 daemon 程序和反向代理程序。daemon程序通过 K8S API 不断监控集群的变化,对 ingress 定义的规则进行解析并刷新配置到反向代理程序 
  
 安装教程
ingress 暴露服务方式
1、Deployment + NodePort 的 Service 模式
1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务(type为NodePort),将ingress暴露在集群节点ip的特定端口上
 2、一般适用于宿主机ip地址相对固定不变的场景,由于 Nodeport 暴露的端口是随机端口,一般会在前面再搭建一套负载均衡器来转发请求,NodePort方式暴露 ingress 虽然简单,但多了一层NAT,在请求量级很大时对性能会有一定影响
2、Deployment + LoadBalancer 的 Service 模式
1、基于 Deployment 部署 ingress-controller 并创建对应的 Service 服务(type为 LoadBalancer)
 2、此模式需要将 ingress 部署在公有云,大部分公有云都会为 LoadBalancer 的 service 自动创建一个负载均衡器,通常还绑定了公网地址,只要把域名解析指向该公网地址就实现了集群服务的对外暴露
3、DaemonSet + HostNetwork + nodeSelector 的 Service 模式
1、基于 DaemonSet 结合 NodeSelector 来部署 ingress-controller 到特定的 node 上,再通过 HostNetwork 把该 pod 与宿主机 node 的网络打通,通过宿主机的80/433端口访问服务
 2、该方式相对NodePort模式的性能更好,缺点:由于直接利用宿主机节点的网络和端口,一个node只能部署一个ingress-controller,适合大并发的生产环境使用
部署 httpd 应用并对外访问(HTTP)
- 创建 Deployment
kubectl apply -f /home/lixing/demo/deployment-httpd.yaml # kubectl delete -f /home/lixing/demo/deployment-httpd.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: ns-httpd
  name: deployment-httpd
  labels: # 给Deployment打标签
    app: httpd
spec: 
  selector: # Pod选择器
    matchLabels:
      app: httpd # 对标签为httpd的Pod进行管理
  replicas: 1 # 默认Pod副本数量
  template: 
      metadata:
        labels: 
          app: httpd # 为Pod打标签
      spec:
        #hostNetwork: true
        #nodeSelector: #使用节点选择器将Pod调度到指定label的节点
          #component: pod-demo
        containers:
        - name: httpd
          image: httpd
          imagePullPolicy: IfNotPresent
          ports: 
          - name: port-name-httpd 
            protocol: TCP
            containerPort: 80
- 创建 Service
kubectl apply -f /home/lixing/demo/service-httpd.yaml # kubectl delete -f /home/lixing/demo/service-httpd.yaml
apiVersion: v1
kind: Service
metadata:
  namespace: ns-httpd
  name: service-httpd
spec: 
  selector: #Deployment选择器
    app: httpd
  #type: NodePort # Service暴露服务的类型
  ports:
  - protocol: TCP # 通讯协议
    #nodePort: 30000 # 集群上所有Node节点端口
    port: 8080 # Service端口
    targetPort: 80 # Pod端口
- 访问 Pod(直接访问Pod、通过Service访问Pod)
kubectl get deployment,pods,service,ingress -n ns-httpd -o wide

 
- 修改Master节点的host文件(这里以Master节点为例)
vi /etc/hosts # 编辑Host文件,添加当前节点的ip和自定义域名
192.168.111.30 www.lixing.com
- 创建 Ingress 规则
kubectl apply -f /home/lixing/demo/ingress-httpd.yaml # kubectl delete -f /home/lixing/demo/ingress-httpd.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: ns-httpd
  name: ingress-httpd
spec:
  ingressClassName: nginx
  rules:
    - host: www.lixing.com
      http:
        paths:
          - pathType: Prefix
            path: /
            backend:
              service:
                name: service-httpd # Service名称
                port:
                  number: 8080 # Service端口
- 路径类型匹配规则
# Ingress 中的每个路径都需要有对应的路径类型(pathType),未明确设置 pathType 的路径无法通过合法性检查。当前支持的路径类型有三种:
ImplementationSpecific:匹配方法取决于IngressClass。具体实现可以将其作为单独的 pathType 处理或者与 Prefix 或 Exact 类型作相同处理
Exact:精确匹配 URL 路径,且区分大小写
Prefix:基于以 / 分隔的URL路径前缀匹配。匹配区分大小写,并且对路径中的元素逐个完成

- 主机名通配符
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

- 通过 Ingress Nginx Controller 访问Pod
  
 注意:ingress-nginx-controller 服务的端口转化信息:80:32163/TCP,443:31590/TCP

 
部署 httpd 应用并对外访问(HTTPS)
创建证书
openssl reg -x509 -sha256 -nodes -days 365 -newkey rsa:2048-keyout tls.key-out tls.crt-subj '/C=CN/ST=BJ/L=BJ/O=nginx/CN=itheima.com"
创建密钥
kubectl create secret tls tls-secret --key tls.key --cert tls.crt
创建 Ingress 规则
kubectl apply -f /home/lixing/demo/ingress-httpd.yaml # kubectl delete -f /home/lixing/demo/ingress-httpd-https.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: ns-httpd
  name: ingress-httpd-https
spec:
  ingressClassName: nginx
  tls:
    - hosts:
      - www.lixing.com
      secretName: tls-secret # 指定密钥
  rules:
    - host: www.lixing.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              serviceName: service-httpd # Service名称
              servicePort: 8080 # Service端口



















