2.k8sPod、控制器、service

一、Pod生命周期

• Pod是k8s中最小的管理单元（逻辑上存在，实际不存在），是一组容器的集合
• 同一个Pod中的容器共享网络和存储（通过pause容器实现），由一个统一的IP向集群内部提供服务
• Pod分为自主式（死亡之后就会消失）和被控制器控制的（死亡之后会被控制器拉起来保持Pod的副本数量）
• Pod的生命周期是短暂的，Pod死亡之后，重新创建的Pod和原来的Pod完全不一样

1、init c

• init c 即 init container （初始化容器）

• Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的Init容器

• Init容器与普通的容器非常像，除了如下两点

  • Init容器总是运行到成功完成为止
  • 每个Init容器都必须在下一个Init容器启动之前成功完成

• 如果Pod的Init容器失败， Kubernetes 会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的 restartPolicy为Never,他不会重新启动

2、init c的作用

• 因为Init容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势
  • 它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
  • 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似 sed 、 awk 、 python或 dig这样的工具
  • 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像
  • Init容器使用 Linux Namespace ，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用程序容器则不能
  • 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件
• 也就是说在主容器启动之前使用init c可以做一些其他事情
  • 读取配置文件等等（为保证主容器运行）
  • 读取私密文件等等（保证系统的安全，init c一旦成功结束，就会删除，而读取私密文件放在主容器中，可能会出现安全隐患，因为主容器时一直运行）
  • 但是不建议用init c去监测其他容器（比如，我们的服务mysql应该先启动，用init c去监测mysql的容器时是正常的，init c成功结束，但是主容器启动时mysql容器可能又挂了，所以这种方法不太准确）

3、特殊说明

• 在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出，init c按顺序执行，上一个执行成功之后才会执行下一个
• 如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always ，Init容器失败时会使用RestartPolicy策略
• 在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的 Pod处于 Pending 状态，但应该会将 Initializing状态设置为 true
• 如果Pod重启，所有Init容器必须重新执行
• 对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod
• Init容器具有应用容器的所有字段。除了 readinessProbe ，因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
• 在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误
• start和stop会在main c 启动之后和结束之前做一些事情
• 

4、init c资源清单示例

• # pod 资源清单
  apiVersion: v1
  kind: Pod
  metadata:
    name: initc-pod
    labels:
      app: myapp
  spec:
    containers:
    - name: initc-container
      image: busybox
      command: ['sh', '-c', 'echo The app is running! && sleep 3600']
    # 以下为init c容器
    initContainers:
    # 第一个init c容器
    - name: init-myservice
      image: busybox
      # 监测service 看集群中有无名为myservice的service 直至监测到才会成功推出（直接写service名称可能不能解析，ping不同，解决方法如下）
      command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2;done;']
    # 第一个init c容器
    - name: init-mydb
      image: busybox
      # 监测service 看集群中有无名为mydb的service 直至监测到才会成功推出
      command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
  

• # 查看pod状态
  [root@k8smaster pods]# kubectl get pod
  NAME        READY   STATUS     RESTARTS   AGE
  initc-pod   0/1     Init:0/2   0          43s
  
  # 查看pod日志
  [root@k8smaster pods]# kubectl logs initc-pod -c  init-myservice
  ;; connection timed out; no servers could be reached
  
  waiting for myservice
  ;; connection timed out; no servers could be reached
  
  waiting for myservice
  ;; connection timed out; no servers could be reached
  
  ......
  
  

• # service 资源清单 简写svc
  kind: Service
  apiVersion: v1
  metadata:
    name: myservice
  spec:
    ports:
    	# 使用的协议 TCP和UDP可选
      - protocol: TCP
        # 暴露给k8s内部集群的端口
        port: 80
        # 也监听就是sevice的pod下容器 并且容器暴露端口为9376
        targetPort: 9376
  # 用--- 分开表示一个yaml文件
  ---
  kind: Service
  apiVersion: v1
  metadata:
    name: mydb
  spec:
    ports:
      - protocol: TCP
        port: 80
        targetPort: 9377
  

• # 启动名为myservice的service 查看pod状态
  [root@k8smaster pods]# kubectl get pod
  NAME                   READY   STATUS     RESTARTS   AGE
  initc-pod              0/1     Init:1/2   0          57s
  
  # 启动名为mydb的service 查看pod状态
  [root@k8smaster pods]# kubectl get pod
  NAME                   READY   STATUS    RESTARTS   AGE
  initc-pod              1/1     Running   0          2m34s
  

• 解决pod内不能通过域名进行访问其他servce或者pod（ping 不同 不管是clusterIp，还是名称）

  • 问题原因：kubeadm安装的k8s的kube-proxy使用的iptables，需要修改为ipvs

  • 1.开启ipvs支持（每个节点执行）

    • yum -y install ipvsadm ipset （好像可省略）
    • 永久生效：cat > /etc/sysconfig/modules/ipvs.modules <<EOF
      
      modprobe -- ip_vs
      
      modprobe -- ip_vs_rr
      
      modprobe -- ip_vs_wrr
      
      modprobe -- ip_vs_sh
      
      modprobe -- nf_conntrack_ipv4
      
      EOF
    • 临时生效：modprobe -- ip_vs
      
      modprobe -- ip_vs_rr
      
      modprobe -- ip_vs_wrr
      
      modprobe -- ip_vs_sh
      
      modprobe -- nf_conntrack_ipv4

  • 2.修改权限（每个节点执行，好像可省略）

    • chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4

  • 3.修改kube-proxy的configMap

    • kubectl edit cm kube-proxy -n kube-system

    • ipvs:
            excludeCIDRs: null
            minSyncPeriod: 0s
            scheduler: ""
            strictARP: false
            syncPeriod: 30s
          kind: KubeProxyConfiguration
          metricsBindAddress: 127.0.0.1:10249
          mode: "ipvs" # 修改此处为ipvs
      

  • 4.重启kube-proxy

    • kubectl get pod -n kube-system | grep kube-proxy |awk '{system("kubectl delete pod "$1" -n kube-system")}'

  • 5.查看kube-proxy启动日志，确认是否为ipvs

    • kubectl logs -n kube-system kube-proxy-ff74q（自己的kube-proxy pod名）

    • # 有Using ipvs Proxier则配置成功
      I1215 09:18:42.852942       1 server_others.go:259] Using ipvs Proxier.
      

  • 6.进入Pod中使用ping 命令测试，如果不行重启k8s集群后再试

5、健康检查（探针）

• 探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的Handler 。有三种类型的处理程序

  • ExecAction ：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功
  • TCPSocketAction ：对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的
  • HTTPGetAction ：对指定的端口和路径上的容器的 IP地址执行 HTTP Get请求。如果响应的状态码大于等于200且小于400 ，则诊断被认为是成功的，可以防止端口是开的但是服务已经挂掉

• 每次探测都将获得以下三种结果之一

  • 成功：容器通过了诊断
  • 失败：容器未通过诊断
  • 未知：诊断失败，因此不会采取任何行动

• 探针分类

  • readinessProbe ：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure 。如果容器不提供就绪探针，则默认状态为 Success，也就是在主容器创建时，检测该主容器是否已经准备就绪，可以向外界提供服务了，防止出现，容器启动了，但是容器中的服务还没有启动，这个是否向外界提供服务就会出现异常

    • readinessProbe只影响Realy状态，不会重启pod，重启pod会重新执行readinessProbe

    • 资源清单示例

      • apiVersion: v1
        kind: Pod
        metadata:
          name: readiness-httpget-pod
          namespace: default
        spec:
          containers:
          - name: readiness-httpget-container
            image: nginx
            # 镜像拉取方式，如果本地有就用本地
            imagePullPolicy: IfNotPresent
            # 就绪检查方式采用httpGet，默认的nginx肯定没有index1.html
            readinessProbe:
              httpGet:
                port: 80
                path: /index1.html
              # 开始检测延迟时间1s
              initialDelaySeconds: 1
              # 检测间隔时间3s
              periodSeconds: 3
        

    • 启动readiness-httpget-pod并查看

      • # pod的状态为Running，但是READY没准备好
        [root@k8smaster pods]# kubectl get pod
        NAME                    READY   STATUS    RESTARTS   AGE
        readiness-httpget-pod   0/1     Running   0          5m51s
        
        # 查看pod的描述 就绪检测失败
        [root@k8smaster pods]# kubectl describe pod  readiness-httpget-pod
        Warning  Unhealthy  4m26s (x100 over 9m23s)  kubelet, k8snode2  Readiness probe failed: HTTP probe failed with statuscode: 404
        

    • 进入Pod中添加index1.html

      • # 向/usr/share/nginx/html 中添加index1.html 后查看pod状态已经就绪
        # kubectl exec -it pod名 -c 容器名（pod中只有一个容器可不指定） -- /bin/sh（执行的命令）
        [root@k8smaster pods]# kubectl exec -it readiness-httpget-pod -c readiness-httpget-container -- /bin/sh
        # cd /usr/share/nginx/html
        # echo "123" >> index1.html
        # ls
        50x.html  index.html  index1.html
        # exit
        
        [root@k8smaster pods]# kubectl get pod
        NAME                    READY   STATUS    RESTARTS   AGE
        readiness-httpget-pod   1/1     Running   0          16m
        

  • livenessProbe ：指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success，也就是为了防止僵尸进程存在，进程还在，不能提供服务

    • livenessProbe检测失败会重启pod，重启pod会重新执行readinessProbe

    • 资源清单示例一：exec方式

      • apiVersion: v1
        kind: Pod
        metadata:
          name: liveness-exec-pod
          namespace: default
        spec:
          containers:
          - name: liveness-exec-container
            image: busybox
            imagePullPolicy: IfNotPresent
            # 容器启动的命令 在/tmp下创建live文件 过30s删除
            command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
            # 存活检查采用 命令的方式 看/tmp下创建live文件存不存在 不存在则检测失败，使用Pod的重启策略
            livenessProbe:
              exec:
                command: ["test","-e","/tmp/live"]
              initialDelaySeconds: 1
              periodSeconds: 3
        

      • # 查看pod 在30s的时候进行了重启（也不一定是30s，因为容器启动也会浪费时间）
        [root@k8smaster pods]# kubectl get pod
        NAME                   READY   STATUS    RESTARTS   AGE
        liveness-exec-pod      1/1     Running   0          29s
        web-5dcb957ccc-r74d6   1/1     Running   0          28m
        
        [root@k8smaster pods]# kubectl get pod
        NAME                   READY   STATUS    RESTARTS   AGE
        liveness-exec-pod      1/1     Running   1          32s
        web-5dcb957ccc-r74d6   1/1     Running   0          28m
        

    • 资源清单示例二：httpGet方式

      • apiVersion: v1
        kind: Pod
        metadata:
          name: liveness-httpget-pod
          namespace: default
        spec:
          containers:
          - name: liveness-httpget-container
            image: nginx
            imagePullPolicy: IfNotPresent
            ports:
            - name: http
              # 该Pod监听其下容器的端口
              containerPort: 80
            # 存活检查采用 httpGet的方式 访问/index.html存不存在
            livenessProbe:
              httpGet:
                port: http
                path: /index.html
              initialDelaySeconds: 1
              periodSeconds: 3
              # 超时时间 超时代表失败
              timeoutSeconds: 10
        

      • # 查看pod状态
        [root@k8smaster pods]# kubectl get pod
        NAME                   READY   STATUS    RESTARTS   AGE
        liveness-httpget-pod   1/1     Running   0          5m12s
        
        # 进入pod删除index.html
        [root@k8smaster pods]# kubectl exec -it liveness-httpget-pod -c readiness-httpget-container -- /bin/sh
        # cd /usr/share/nginx/html
        # rm index.html
        
        # 查看pod状态
        [root@k8smaster pods]# kubectl get pod
        NAME                   READY   STATUS    RESTARTS   AGE
        liveness-httpget-pod   1/1     Running   1          9m43s
        

    • 资源清单示例三：tcp方式

      • apiVersion: v1
        kind: Pod
        metadata:
          name: liveness-tcp-pod
        spec:
          containers:
          - name: liveness-tcp-container
            image: nginx
            # 存活检查采用 tcp的方式 检查8080端口
            livenessProbe:
              initialDelaySeconds: 5
              timeoutSeconds: 1
              periodSeconds: 3
              tcpSocket:
                port: 8080
        

      • # 查看pod状态 一直重启 因为8080端口一直不存在
        NAME                   READY   STATUS    RESTARTS   AGE
        liveness-tcp-pod       1/1     Running   4          104s
        

  • readinessProbe和livenessProbe 同时使用

    • 资源清单示例

      • apiVersion: v1
        kind: Pod
        metadata:
          name: liveness-httpget-pod
          namespace: default
        spec:
          containers:
          - name: liveness-httpget-container
            image: nginx
            imagePullPolicy: IfNotPresent
            ports:
            - name: http
              # 该Pod监听其下容器的端口
              containerPort: 80
            readinessProbe:
              httpGet:
                port: 80
                path: /index1.html
              # 开始检测延迟时间1s
              initialDelaySeconds: 1
              # 检测间隔时间3s
              periodSeconds: 3
            # 存活检查采用 httpGet的方式 访问/index.html存不存在
            livenessProbe:
              httpGet:
                port: http
                path: /index.html
              initialDelaySeconds: 1
              periodSeconds: 3
              # 超时时间 超时代表失败
              timeoutSeconds: 10
        

6、start和stop

• Pod hook（钩子）是由 Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hookHook

• Hook 的类型包括两种

  • exec ：执行一段命令
  • HTTP ：发送 HTTP 请求

• 资源清单示例

  • apiVersion: v1
    kind: Pod
    metadata:
      name: lifecycle-demo
    spec:
      containers:
      - name: lifecycle-demo-container
        image: nginx
        lifecycle:
          # 容器启动后执行
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello from the postStart handler >/usr/share/message"]
          # 容器关闭前执行
          preStop:
            exec:
              command: ["/bin/sh", "-c", "echo Hello from the poststop handler >/usr/share/message"]
    

  • # 进入容器查看
    [root@k8smaster pods]# kubectl exec -it lifecycle-demo -- /bin/sh
    # cat /usr/share/message
    Hello from the postStart handler
    

7、pod状态

• 挂起（ Pending ）： Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod
• 运行中（ Running ）：该 Pod 已经绑定到了一个节点上， Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态
• 成功（ Succeeded ）： Pod 中的所有容器都被成功终止，并且不会再重启 常见job和cronjob
• 失败（ Failed ）： Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非 0
• 未知（ Unknown ）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败

二、控制器

• Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为，也就是说pod是最小的调度单元，而控制器用来管理pod,由控制器管理的pod死亡后，会被拉起，而没被管理的pod不会被管（也就是自主式pod）

1、Replication Controller(RC)

• Replication Controller(RC)是Kubernetes系统中核心概念之一，当我们定义了一个 RC并提交到Kubernetes集群中以后，Master节点上的Controller Manager组件就得到通知，定期检查系统中存活的Pod,并确保目标Pod实例的数量刚好等于RC的预期值，如果有过多或过少的Pod运行，系统就会停掉或创建一些Pod.此外我们也可以通过修改RC副本数量，来实现Pod的动态缩放功能，也就是说RC用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收

• 资源清单示例

  • apiVersion: v1
    kind: ReplicationController
    metadata:
      name: rcdemo
    spec:
      # pod需要保持的副本数
      replicas: 3
      # RC的标签选择器
      selector:
        # 所管理的Pod上有tier=frontend 这个标签，也就是说RC是通过labels来区分自己要管理的Pod，不支持集合式的selector
        tier: frontend
      # template 相当于定义的Pod
      template:
        metadata:
          # pod的标签key=value的形式 如果跟RC所需要的一致，就会被匹配到的RC管理
          labels:
            tier: frontend
        spec:
          # pod中的容器
          containers:
          - name: mynginx
            image: nginx
            # 容器内部添加环境变量
            env:
            - name: GET_HOSTS_FROM
              value: dns
            ports:
            - containerPort: 80
    

  • # 创建RC
    [root@k8smaster deployments]# kubectl apply -f rcdemo.yaml
    replicationcontroller/rcdemo created
    
    # 查看rc DESIRED：设计数量 CURRENT：当前数量 READY：准备的数量
    [root@k8smaster deployments]# kubectl get rc
    NAME     DESIRED   CURRENT   READY   AGE
    rcdemo   3         3         3       11m
    
    并查看Pod Pod名称规则（控制器name+随机字符串）
    [root@k8smaster deployments]# kubectl get pod
    NAME           READY   STATUS    RESTARTS   AGE
    rcdemo-4sgkd   1/1     Running   0          37s
    rcdemo-hkhfw   1/1     Running   0          37s
    rcdemo-xnr2n   1/1     Running   0          37s
    
    # 删除所有pod 在查看pod是否被控制器拉起
    [root@k8smaster deployments]# kubectl delete pod --all
    pod "rcdemo-4sgkd" deleted
    pod "rcdemo-hkhfw" deleted
    pod "rcdemo-xnr2n" deleted
    
    # --show-labels（显示标签） 被拉起的Pod和原来的完全不一样 说明是重新创建的
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME           READY   STATUS    RESTARTS   AGE   LABELS
    rcdemo-bxtzt   1/1     Running   0          62s   tier=frontend
    rcdemo-f2pnn   1/1     Running   0          62s   tier=frontend
    rcdemo-gbxt4   1/1     Running   0          62s   tier=frontend
    
    # 修改其中一个Pod的label 观察Pod情况 发现多了一个Pod（说明了控制器是通过label来控制Pod的）
    [root@k8smaster deployments]# kubectl label pod rcdemo-bxtzt tier=frontend123 --overwrite
    pod/rcdemo-bxtzt labeled
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME           READY   STATUS    RESTARTS   AGE     LABELS
    rcdemo-8kt4h   1/1     Running   0          14s     tier=frontend
    rcdemo-bxtzt   1/1     Running   0          7m34s   tier=frontend123
    rcdemo-f2pnn   1/1     Running   0          7m34s   tier=frontend
    rcdemo-gbxt4   1/1     Running   0          7m34s   tier=frontend
    

2、ReplicaSet(RS)

• Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

• 资源清单示例

  • apiVersion: apps/v1
    kind: ReplicaSet
    metadata:
      name: rsdemo
    spec:
      # pod需要保持的副本数
      replicas: 3
      # RC的标签选择器
      selector:
        # 所管理的Pod上需要有tier=frontend 这个标签，也就是说RS是通过labels来区分自己要管理的Pod，支持集合式的selector matchLabels等（RC不支持）
        matchLabels:
          tier: frontend
      # template 相当于定义的Pod
      template:
        metadata:
          # pod的标签key=value的形式 如果跟RC所需要的一致，就会被匹配到的RS管理
          labels:
            tier: frontend
        spec:
          # pod中的容器
          containers:
          - name: mynginx
            image: nginx
            # 容器内部添加环境变量
            env:
            - name: GET_HOSTS_FROM
              value: dns
            ports:
            - containerPort: 80
    

  • # 使用效果和RC一样
    

3、Deployment

• Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的ReplicationController来方便的管理应用，Kubenetes v1.2 引入的新概念，引入的目的是为了更好的解决 Pod 的编排问题，Deployment 内部使用了 Replica Set 来实现。Deployment 的定义与 Replica Set 的定义很类似

• 应用场景

  • RS和RC只能维持Pod的副本数量，功能薄弱
  • 定义 Deployment 来创建 Pod 和 ReplicaSet
  • 滚动升级和回滚应用：可以动态的切换版本，底层使用不同的RS来实现的
  • 扩容和缩容：增加或减少副本的数量
  • 暂停和继续 Deployment
  • 滚动升级和回滚

    • 

    • 说明：从V1版升级到V2版 共有三个Pod副本

      • 1.创建新的RS1，创建一个（数量可控）新的V2Pod，当新的V2Pod可以正常使用后，删除一个旧的V1Pod，保证k8s集群中该中Pod的数量不会变，直至所有的V1Pod换成V2Pod，并且旧的RS不会被删除（用于回滚）
      • 2.回滚的过程和上述相反，启动旧的RS

• 资源清单示例

  • apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      replicas: 3
      # 这个版本的Deployment不能省去selector
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.7.9
            ports:
            - containerPort: 80
    

  • # 启动Deployment 查看 Deployment 、rs（rs名称规则：Deployment的name+随机字符串） 和 pod （pod名称规则：rs的name+随机字符串）
    # --record 方便查看版本
    [root@k8smaster deployments]# kubectl apply -f nginx-deployment.yaml --record
    deployment.apps/nginx-deployment created
    
    [root@k8smaster deployments]# kubectl get deployment
    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           42s
    
    [root@k8smaster deployments]# kubectl get rs
    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-5bf87f5f59   3         3         3       47s
    
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    nginx-deployment-5bf87f5f59-hxj25   1/1     Running   0          93s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-wgw7w   1/1     Running   0          93s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-zcf82   1/1     Running   0          93s   app=nginx,pod-template-hash=5bf87f5f59
    
    # 动态扩容到10个Pod副本
    [root@k8smaster deployments]# kubectl scale deployment nginx-deployment --replicas 10
    deployment.apps/nginx-deployment scaled
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS    RESTARTS   AGE     LABELS
    nginx-deployment-5bf87f5f59-58vtn   1/1     Running   0          29s     app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-dmrrs   1/1     Running   0          29s     app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-f7cl6   1/1     Running   0          29s     app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-g5n6j   1/1     Running   0          29s     app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-gsvpd   1/1     Running   0          29s     app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-hfmjh   1/1     Running   0          29s     app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-hxj25   1/1     Running   0          2m30s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-wgw7w   1/1     Running   0          2m30s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-wzjtm   1/1     Running   0          29s     app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-zcf82   1/1     Running   0          2m30s   app=nginx,pod-template-hash=5bf87f5f59
    
    # 动态缩减到3个Pod副本 发现还是原来的那3个 说明会保留存活时间长的
    [root@k8smaster deployments]# kubectl scale deployment nginx-deployment --replicas 3
    deployment.apps/nginx-deployment scaled
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS    RESTARTS   AGE     LABELS
    nginx-deployment-5bf87f5f59-hxj25   1/1     Running   0          3m11s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-wgw7w   1/1     Running   0          3m11s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-zcf82   1/1     Running   0          3m11s   app=nginx,pod-template-hash=5bf87f5f59
    [root@k8smaster deployments]#
    
    # 动态扩容和缩减都不会重新创建新的RS
    [root@k8smaster deployments]# kubectl get rs
    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-5bf87f5f59   3         3         3       5m9s
    
    

  • # 滚动更新 更新镜像版本 查看 RS 和 pod
    [root@k8smaster deployments]# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
    deployment.apps/nginx-deployment image updated
    # 已经创建了新的RS
    [root@k8smaster deployments]# kubectl get rs
    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-5bf87f5f59   3         3         3       9m46s
    nginx-deployment-678645bf77   1         1         0       3s
    # 已经启动的新Pod
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS              RESTARTS   AGE     LABELS
    nginx-deployment-5bf87f5f59-hxj25   1/1     Running             0          9m49s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-wgw7w   1/1     Running             0          9m49s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-zcf82   1/1     Running             0          9m49s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-678645bf77-4k5ls   0/1     ContainerCreating   0          6s      app=nginx,pod-template-hash=678645bf77
    
    # 持续观察 RS 和 pod READY的数量始终会保持在我们需要的副本数量
    [root@k8smaster deployments]# kubectl get rs
    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-5bf87f5f59   1         1         1       10m
    nginx-deployment-678645bf77   3         3         2       41s
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS              RESTARTS   AGE   LABELS
    nginx-deployment-5bf87f5f59-wgw7w   1/1     Running             0          10m   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-678645bf77-4k5ls   1/1     Running             0          48s   app=nginx,pod-template-hash=678645bf77
    nginx-deployment-678645bf77-szk6f   1/1     Running             0          18s   app=nginx,pod-template-hash=678645bf77
    nginx-deployment-678645bf77-tm4jl   0/1     ContainerCreating   0          16s   app=nginx,pod-template-hash=678645bf77
    
    # 最终结果 旧的RS并没有删除
    [root@k8smaster deployments]# kubectl get rs -o wide
    NAME                          DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES        SELECTOR
    nginx-deployment-5bf87f5f59   0         0         0       23m   nginx        nginx:1.7.9   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-678645bf77   3         3         3       13m   nginx        nginx:1.9.1   app=nginx,pod-template-hash=678645bf77
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    nginx-deployment-678645bf77-4k5ls   1/1     Running   0          67s   app=nginx,pod-template-hash=678645bf77
    nginx-deployment-678645bf77-szk6f   1/1     Running   0          37s   app=nginx,pod-template-hash=678645bf77
    nginx-deployment-678645bf77-tm4jl   1/1     Running   0          35s   app=nginx,pod-template-hash=678645bf77
    
    # 使用 kubectl edit deployment/nginx-deployment 可以编辑资源的yaml
    

  • # 回滚到上一个版本 启用上一个版本对应的RS
    [root@k8smaster deployments]# kubectl rollout undo deployment/nginx-deployment
    deployment.apps/nginx-deployment rolled back
    [root@k8smaster deployments]# kubectl get rs -o wide
    NAME                          DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES        SELECTOR
    nginx-deployment-5bf87f5f59   2         2         1       27m   nginx        nginx:1.7.9   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-678645bf77   2         2         2       17m   nginx        nginx:1.9.1   app=nginx,pod-template-hash=678645bf77
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS        RESTARTS   AGE   LABELS
    nginx-deployment-5bf87f5f59-97lds   1/1     Running       0          9s    app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-lb7mm   1/1     Running       0          13s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-zltbv   1/1     Running       0          11s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-678645bf77-4k5ls   0/1     Terminating   0          18m   app=nginx,pod-template-hash=678645bf77
    nginx-deployment-678645bf77-szk6f   0/1     Terminating   0          17m   app=nginx,pod-template-hash=678645bf77
    nginx-deployment-678645bf77-tm4jl   0/1     Terminating   0          17m   app=nginx,pod-template-hash=678645bf77
    [root@k8smaster deployments]# kubectl get rs -o wide
    NAME                          DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES        SELECTOR
    nginx-deployment-5bf87f5f59   3         3         3       28m   nginx        nginx:1.7.9   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-678645bf77   0         0         0       18m   nginx        nginx:1.9.1   app=nginx,pod-template-hash=678645bf77
    [root@k8smaster deployments]# kubectl get pod --show-labels
    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    nginx-deployment-5bf87f5f59-97lds   1/1     Running   0          26s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-lb7mm   1/1     Running   0          30s   app=nginx,pod-template-hash=5bf87f5f59
    nginx-deployment-5bf87f5f59-zltbv   1/1     Running   0          28s   app=nginx,pod-template-hash=5bf87f5f59
    
    # 查看回滚状态如果 rollout 成功完成， kubectl rollout status 将返回一个0值的 Exit Code
    [root@k8smaster deployments]# kubectl rollout status deployment/nginx-deployment
    deployment "nginx-deployment" successfully rolled out
    [root@k8smaster deployments]# echo $?
    0
    
    # 查看版本 前面的REVISION可用于回退于指定版本
    [root@k8smaster deployments]# kubectl rollout history deployment/nginx-deployment
    
    deployment.apps/nginx-deployment
    REVISION  CHANGE-CAUSE
    2         kubectl apply --filename=nginx-deployment.yaml --record=true
    3         kubectl apply --filename=nginx-deployment.yaml --record=true
    
    

  • # Deployment 更新策略
    # Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）
    # Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）
    [root@k8smaster deployments]# kubectl describe deployments
    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Wed, 16 Dec 2020 10:57:54 +0800
    Labels:                 <none>
    Annotations:            deployment.kubernetes.io/revision: 3
                            kubernetes.io/change-cause: kubectl apply --filename=nginx-deployment.yaml --record=true
    Selector:               app=nginx
    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
    StrategyType:           RollingUpdate
    MinReadySeconds:        0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    
    # 未来的 Kuberentes 版本中，将从1-1变成25%-25%
    

  • Rollover（多个rollout并行）

    • 假如您创建了一个有5个niginx:1.7.9 replica的Deployment，但是当还只有3个nginx:1.7.9 的 replica 创建出来的时候您就开始更新含有5个 nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个 nginx:1.7.9 的 Pod，并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的5个 nginx:1.7.9 的Pod 都创建完成后才开始改变航道

  • 回退Deployment

    • # 查看版本历史记录 REVISION可用于回退于指定版本
      kubectl rollout history deployment/nginx-deployment
      [root@k8smaster deployments]# kubectl rollout history deployment/nginx-deployment
      
      deployment.apps/nginx-deployment
      REVISION  CHANGE-CAUSE
      2         kubectl apply --filename=nginx-deployment.yaml --record=true
      3         kubectl apply --filename=nginx-deployment.yaml --record=true
      
      # 回退到当前的上一个版本
      kubectl rollout undo deployment/nginx-deployment
      
      # 回退到指定版本 可以使用 --revision参数指定某个历史版本
      kubectl rollout undo deployment/nginx-deployment --to-revision=2
      
      # 暂停 deployment 的更新
      kubectl rollout pause deployment/nginx-deployment
      
      # 通过设置.spec.revisonHistoryLimit来指定deployment最多保留多少revision历史记录。默认会保留所有revision；如果将该项设置为0，Deployment 就不能回退
      

4、DaemonSet

• DaemonSet 确保全部（或者一些）Node上运行一个Pod 的副本。当有Node加入集群时，也会为他们新增一个Pod 。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod，也就是说由DaemoSet控制的Pod会在每个Node上都会运行一个，相当于一个守护模式，当有新的Node加入到集群时，新的Node也会有这种Pod，当有Node退出集群时，这个Node上的Pod就会删除

• 应用场景

  • 运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph
  • 在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash
  • 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、New Relic 代理，或 Ganglia gmond

• 资源清单示例

  • apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: deamonset-example
      labels:
        app: daemonset
    spec:
      selector:
        matchLabels:
          name: deamonset-example
      template:
        metadata:
          labels:
            name: deamonset-example
        spec:
          containers:
          - name: daemonset-example
            image: nginx
    

  • # 启动deamonset-example
    [root@k8smaster deployments]# kubectl apply -f deamonset-example.yaml
    daemonset.apps/deamonset-example created
    
    # 查看 DaemonSet
    [root@k8smaster deployments]# kubectl get daemonset
    NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    deamonset-example   2         2         2       2            2           <none>          71s
    
    # 查看 Pod node1和node2节点上各一个
    [root@k8smaster deployments]# kubectl get pod -o wide
    NAME                                READY   STATUS    RESTARTS   AGE    IP            NODE       NOMINATED NODE   READINESS GATES
    deamonset-example-5l9f6             1/1     Running   0          28s    10.244.2.31   k8snode1   <none>           <none>
    deamonset-example-lwhrl             1/1     Running   0          28s    10.244.1.35   k8snode2   <none>           <none>
    

5、StatefulSet

• StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序

• StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计）例如mysql

• 应用场景

  • 定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
  • 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
  • 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
  • 有序收缩，有序删除（即从N-1到0）

• 需要用到的知识有service，pvc存储等，可先跳过，先学习下前置知识

• 在PVC模块详细介绍

6、Job

• Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束

• Job Spec

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure（仅执行成功一次所以不能用Always）
  • 单个Pod时，默认Pod成功运行后Job即结束
  • .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1 （Pod的返回码为0时成功一次）
  • .spec.parallelism 标志并行运行的Pod的个数，默认为1
  • .spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试

• 资源清单示例

  • apiVersion: batch/v1
    kind: Job
    metadata:
      name: pi
    spec:
      template:
        metadata:
          name: pi
        spec:
          containers:
          - name: pi
            # 该镜像用于计算圆周率 CMD是将2000位的圆周率输出
            image: perl
            command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: Never
    

  • # 创建job
    [root@k8smaster deployments]# kubectl apply -f job-test.yaml
    job.batch/pi created
    
    # 查看job 已经成功结束
    [root@k8smaster deployments]# kubectl get job
    NAME   COMPLETIONS   DURATION   AGE
    pi     1/1           90s        109s
    
    # 查看pod 已经成功结束
    [root@k8smaster deployments]# kubectl get pod
    NAME                                READY   STATUS      RESTARTS   AGE
    pi-ljl4g                            0/1     Completed   0          101s
    
    # 查看pod日志
    [root@k8smaster deployments]# kubectl logs pi-ljl4g
    3.1415926535897932384626433832795028841971693993751058209...以后位数省略
    

7、CronJob

• CronJob管理基于时间的 Job

  • 在给定时间点只运行一次
  • 周期性地在给定时间点运行
  • 使用条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）
  • CronJob通过创建Job来进行管理

• 应用场景

  • 在给定的时间点调度 Job 运行
  • 建周期性运行的 Job，例如：数据库备份、发送邮件

• CronJob Spec

  • .spec.schedule指定任务运行周期，格式同Cron
  • .spec.jobTemplate指定需要运行的任务，格式同Job，包含了.spec.completions、.spec.parallelism、.spec.activeDeadlineSeconds
  • .spec.startingDeadlineSeconds ：启动 Job 的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限
  • .spec.concurrencyPolicy ：并发策略，该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：
    • Allow （默认）：允许并发运行 Job
    • Forbid ：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
    • Replace ：取消当前正在运行的 Job，用一个新的来替换
    • 注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行
  • .spec.suspend ：挂起，该字段也是可选的。如果设置为true ，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为 false
  • .spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit ：历史限制，是可选的字段。它们指定了可以保留多少完成和失败的 Job。默认情况下，它们分别设置为3和1 。设置限制的值为0 ，相关类型的Job完成后将不会被保留
  • .spec.startingDeadlineSeconds指定任务开始的截止期限

• 资源清单示例

  • apiVersion: batch/v1beta1
    kind: CronJob
    metadata:
      name: hello
    spec:
      # 一分钟创建一个Job去执行 （分钟 小时 天 月 周）
      schedule: "*/1 * * * *"
      jobTemplate:
        spec:
          template:
            spec:
              containers:
              - name: hello
                image: busybox
                args:
                - /bin/sh
                - -c
                - date; echo Hello from the Kubernetes cluster
              restartPolicy: OnFailure
    

  • # 启动cronjob
    [root@k8smaster deployments]# kubectl apply -f cronjob-test.yaml
    cronjob.batch/hello created
    
    # 查看cronjob
    [root@k8smaster deployments]# kubectl get cronjob
    NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    hello   */1 * * * *   False     0        <none>          12s
    
    # 等待几分钟查看job和pod 默认只保留3条
    [root@k8smaster deployments]# kubectl get job
    NAME               COMPLETIONS   DURATION   AGE
    hello-1608103680   1/1           16s        2m49s
    hello-1608103740   1/1           17s        108s
    hello-1608103800   1/1           17s        48s
    [root@k8smaster deployments]# kubectl get pod
    NAME                     READY   STATUS      RESTARTS   AGE
    hello-1608103680-68c5t   0/1     Completed   0          2m54s
    hello-1608103740-9rwpl   0/1     Completed   0          114s
    hello-1608103800-fjv7z   0/1     Completed   0          54s
    
    

  • 注意事项：

    • 创建Job操作应该是幂等的（防止后面的运行结果影响前面的结果）
    • cronjob不能连接到job的成功，只会周期的创建job，但是job是否运行成功可以监测到

三、Service

• Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组Pod能够被Service访问到，通常是通过Label Selector,标签选择不到创建的是空集群

• Kubernetes Service可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上，提供了服务注册与发现(因为Pod挂掉之后，新创建的Pod的原来的完全不一样，防止Pod失联)，相当于注册中心

• Service能够提供负载均衡的能力，但是在使用上有以下限制

  • 只提供 4 层负载均衡能力，而没有7层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的，仅支持轮询算法
  • 四层负载均衡：通过Ip和端口进行转发
  • 七层负载均衡：主机和域名进行转发（k8s通过ingress可以实现）

• service原理：

  • 

• service分类

  • ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP
  • NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务
  • LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort
  • ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持
  • 

• VIP和Service代理

  • 在 Kubernetes 集群中，每个 Node 运行一个kube-proxy 进程。kube-proxy负责为Service实现了一种VIP（虚拟 IP）的形式，而不是ExternalName的形式。 在Kubernetes v1.0 版本，代理完全在 userspace。在Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是iptables 代理。 在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理
    
    在 Kubernetes 1.14 版本开始默认使用 ipvs 代理
  • 在 Kubernetes v1.0 版本， Service 是 “4层”（TCP/UDP over IP）概念。 在 Kubernetes v1.1 版本，新增了Ingress API（beta 版），用来表示 “7层”（HTTP）服务
  • 为什么不使用DNS代理
    • 因为DNS有缓存，不能实现负载均衡

• 代理模式分类

  • userspace 代理模式

    • 

  • iptables 代理模式

    • 

  • ipvs 代理模式

    • 

    • 这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：

      • rr ：轮询调度
      • lc ：最小连接数
      • dh ：目标哈希
      • sh ：源哈希
      • sed ：最短期望延迟
      • nq ： 不排队调度

1、ClusterIp

• 默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP（自身节点也可访问）

• clusterIP 主要在每个 node 节点使用 iptables或ipvs，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口

• 

  • apiserver 用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中
  • kube-proxy kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中
  • iptables 使用NAT等技术将virtualIP的流量转至endpoint中
  • 服务支持tcp和UDP，但是默认的是TCP

• 资源清单示例

  • # deployment 的资源清单
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: myapp-deploy
      namespace: default
    spec:
      replicas: 3
      selector:
        # 需要匹配的标签
        matchLabels:
          app: myapp
          release: stabel
      template:
        metadata:
          # Pod携带的标签
          labels:
            app: myapp
            release: stabel
            env: test
        spec:
          containers:
          - name: myapp
            image: nginx
            imagePullPolicy: IfNotPresent
            ports:
            - name: http
              containerPort: 80
    

  • # ClusterIP service 的资源清单
    apiVersion: v1
    kind: Service
    metadata:
      name: myapp
      namespace: default
    spec:
      # service 的类型
      type: ClusterIP
      # 通过标签来选择pod，需全部满足
      selector:
        app: myapp
        release: stabel
      # 暴露端口
      ports:
      # name 是pod的一个端口
      - name: http
        # 集群内部使用的端口
        port: 80
        # 转发到其下Pod的容器端口 负载均衡算法是轮询
        targetPort: 80
    

  • # 创建myapp-deploy的deployment 并查看Pod
    [root@k8smaster services]# kubectl apply -f myapp-deploy.yaml
    deployment.apps/myapp-deploy created
    [root@k8smaster services]# kubectl get deployment
    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
    myapp-deploy   3/3     3            3           14s
    [root@k8smaster services]# kubectl get pod
    NAME                            READY   STATUS    RESTARTS   AGE
    myapp-deploy-7c4dbc97b9-qk62v   1/1     Running   0          20s
    myapp-deploy-7c4dbc97b9-qvx4h   1/1     Running   0          20s
    myapp-deploy-7c4dbc97b9-svsww   1/1     Running   0          20s
    
    # 创建service并查看
    [root@k8smaster services]# kubectl apply -f clusterip.yaml
    service/myapp created
    [root@k8smaster services]# kubectl get svc -o wide
    NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE     SELECTOR
    kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP   20h     <none>
    myapp        ClusterIP   10.110.54.87   <none>        80/TCP    6m28s   app=myapp,release=stabel
    
    # 使用 CLUSTER-IP 进行访问
    [root@k8smaster services]# curl 10.110.54.87:80
    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
        body {
            width: 35em;
            margin: 0 auto;
            font-family: Tahoma, Verdana, Arial, sans-serif;
        }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    

2、Headless

• 有时不需要或不想要负载均衡，以及单独的 Service IP 。遇到这种情况，可以通过指定 ClusterIP(spec.clusterIP) 的值为 “None” 来创建 Headless Service 。这类 Service 并不会分配 Cluster IP， kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由，简单点说CLUSTER-IP为None 部署有状态服务时必须使用

• 资源清单示例

  • apiVersion: v1
    kind: Service
    metadata:
      name: myapp-headless
      namespace: default
    spec:
      selector:
        app: myapp
      clusterIP: "None"
      ports:
      - port: 80
        targetPort: 80
    

  • # 创建无头service并查看
    [root@k8smaster services]# kubectl apply -f headless.yaml
    service/myapp-headless created
    [root@k8smaster services]# kubectl get svc -o wide
    NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE   SELECTOR
    kubernetes       ClusterIP   10.96.0.1    <none>        443/TCP   21h   <none>
    myapp-headless   ClusterIP   None         <none>        80/TCP    4s    app=myapp
    
    # 通过endpoints查看其关联的Pod
    [root@k8smaster services]# kubectl get endpoints
    NAME             ENDPOINTS                                      AGE
    kubernetes       192.168.47.150:6443                            66s
    myapp-headless   10.244.1.76:80,10.244.2.73:80,10.244.2.74:80   8s
    

• 通过解析域名的方式查看Headless所关联的Pod（也就意味着没有CLUSTER-IP，还能使用域名的方式去访问Headless）

  • # 查看系统Pod 其中 coredns 就是负责域名解析的
    [root@k8smaster services]# kubectl get pod -n  kube-system -o wide
    NAME                                READY   STATUS    RESTARTS   AGE     IP               NODE        NOMINATED NODE   READINESS GATES
    coredns-7ff77c879f-494fb            1/1     Running   2          41h     10.244.2.14      k8snode1    <none>           <none>
    coredns-7ff77c879f-tvgrz            1/1     Running   2          42h     10.244.1.20      k8snode2    <none>           <none>
    etcd-k8smaster                      1/1     Running   3          6d14h   192.168.47.150   k8smaster   <none>           <none>
    kube-apiserver-k8smaster            1/1     Running   3          6d14h   192.168.47.150   k8smaster   <none>           <none>
    kube-controller-manager-k8smaster   1/1     Running   15         6d14h   192.168.47.150   k8smaster   <none>           <none>
    kube-flannel-ds-amd64-hflj8         1/1     Running   4          6d1h    192.168.47.150   k8smaster   <none>           <none>
    kube-flannel-ds-amd64-s9xhk         1/1     Running   3          6d1h    192.168.47.162   k8snode2    <none>           <none>
    kube-flannel-ds-amd64-wp7mp         1/1     Running   4          6d1h    192.168.47.161   k8snode1    <none>           <none>
    kube-proxy-5l8kb                    1/1     Running   2          42h     192.168.47.150   k8smaster   <none>           <none>
    kube-proxy-6n8vp                    1/1     Running   2          42h     192.168.47.161   k8snode1    <none>           <none>
    kube-proxy-lgcxp                    1/1     Running   2          42h     192.168.47.162   k8snode2    <none>           <none>
    kube-scheduler-k8smaster            1/1     Running   16         6d14h   192.168.47.150   k8smaster   <none>           <none>
    
    # 使用dig 命令 解析域名 dig -t A service名.命名空间名.svc.cluster.local.（默认集群域名） @coredns的Ip（任意一个即可）
    # 如果没有dig 命令 安装即可 yum -y install bind-utils
    # 我们发现 其中所关联的Pod都显示了出来
    [root@k8smaster services]# dig -t A myapp-headless.default.svc.cluster.local. @10.244.2.14
    
    ; <<>> DiG 9.11.13-RedHat-9.11.13-3.el8 <<>> -t A myapp-headless.default.svc.cluster.local. @10.244.2.14
    ;; global options: +cmd
    ;; Got answer:
    ;; WARNING: .local is reserved for Multicast DNS
    ;; You are currently testing what happens when an mDNS query is leaked to DNS
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37833
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
    ;; WARNING: recursion requested but not available
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ; COOKIE: 96e732da9566602d (echoed)
    ;; QUESTION SECTION:
    ;myapp-headless.default.svc.cluster.local. IN A
    
    ;; ANSWER SECTION:
    myapp-headless.default.svc.cluster.local. 30 IN A 10.244.2.73
    myapp-headless.default.svc.cluster.local. 30 IN A 10.244.2.74
    myapp-headless.default.svc.cluster.local. 30 IN A 10.244.1.76
    
    ;; Query time: 2 msec
    ;; SERVER: 10.244.2.14#53(10.244.2.14)
    ;; WHEN: Thu Dec 17 11:02:40 CST 2020
    ;; MSG SIZE  rcvd: 249
    
    

3、NodePort

• nodePort的原理在于在node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步到给对应的pod

• 将服务暴露给集群外部使用，可指定端口

• NodePort，Kubernetes master会分配一个区域范围内，（默认是30000-32767），并且，每一个node，都会代理（proxy）这个端口到你的服务中，我们可以在spec.ports[*].nodePort 找到具体的值，如果我们向指定一个端口，我们可以直接写在nodePort上，系统就会给你指派指定端口，但是这个值必须是指定范围内的

• 

• 资源清单示例

  • apiVersion: v1
    kind: Service
    metadata:
      name: myapp-nodeport
      namespace: default
    spec:
      type: NodePort
      selector:
        app: myapp
        release: stabel
      ports:
      - name: http
        port: 80
        targetPort: 80
        # node暴露的端口 外界使用任意nodeIp:该端口  不指定随机分配
        nodePort: 30001
    

  • # 创建myapp-nodeport并查看service
    [root@k8smaster services]# kubectl apply -f nodeport.yaml
    service/myapp-nodeport created
    [root@k8smaster services]# kubectl get svc -o wide
    NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE   SELECTOR
    kubernetes       ClusterIP   10.96.0.1      <none>        443/TCP        21h   <none>
    myapp-nodeport   NodePort    10.111.91.90   <none>        80:30001/TCP   4s    app=myapp,release=stabel
    
    # 经过测试 在外界使用任意nodeIp:30001 都可访问成功
    
    # iptables -t nat -nvL  查询转发流程
    # ipvsadm -Ln 查询转发流程
    [root@k8smaster services]# 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.47.150:6443          Masq    1      1          0
    TCP  10.96.0.10:53 rr
      -> 10.244.1.20:53               Masq    1      0          0
      -> 10.244.2.14:53               Masq    1      0          0
    

4、LoadBalancer

• loadBalancer 和 nodePort 其实是同一种方式。区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用cloud provider 去创建LB来向节点导流（nodePort使用的是nginx等其他）
• 云服务商收费
• 

5、ExternalName

• 这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容( 例如：www.baidu.com )。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

• 在集群内部访问集群外部的服务

• 

• 资源清单示例

  • apiVersion: v1
    kind: Service
    metadata:
      # 名称externalName-1、externalName1 为什么不合法 不能使用驼峰 只能用-连接单词 并且还要小写
      name: external1
      namespace: default
    spec:
      type: ExternalName
      # 连接的外界域名
      externalName: www.baidu.com
    

  • #  查看ExternalName类型的service
    [root@k8smaster services]# kubectl get svc
    NAME             TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
    external1        ExternalName   <none>          www.baidu.com   <none>         15h
    

• 当查询主机 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的DNS 服务将返回一个值 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发

6、Multi-Port

• 可能很多服务需要开发不止一个端口,为了满足这样的情况，Kubernetes允许在定义时候指定多个端口，当我们使用多个端口的时候，我们需要指定所有端口的名称，这样endpoints才能清楚

• 资源清单示例

  • apiVersion: v1
    kind: Service
    metadata:
      name: multiPort
    spec:
      type: NodePort
      selector:
        app: myapp
        release: stabel
      ports:
      - name: http
        protocol: TCP
        port: 80
        targetPort: 9376
      - name: https
        protocol: TCP
        port: 443
        targetPort: 9377
    

  • # 查看service和endpoints
    [root@k8smaster services]# kubectl get svc
    NAME             TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
    kubernetes       ClusterIP      10.96.0.1       <none>          443/TCP                      16h
    
    [root@k8smaster services]# kubectl get endpoints
    NAME             ENDPOINTS                                                        AGE
    multi-port       10.244.1.76:9376,10.244.2.73:9376,10.244.2.74:9376 + 3 more...   48s
    
    

7、Endpoints

• 当我们创建一个service之后，我们可以使用这个service对Pod进行访问，而service是通过标签的选择来确定访问那些Pod，Kubernete提供了一个简单的Endpoints API，这个Endpoints api的作用就是当一个服务中的pod发生变化时，Endpoints API随之变化，对于哪些不是原生的程序，Kubernetes提供了一个基于虚拟IP的网桥的服务，这个服务会将请求转发到对应的后台pod，也就是service和pod的对应关系，通过Endpoints可以找到，当我们创建一个service之后，k8s就会创建一个同名的Endpoints（没有选择器的情况下 值为None），ExternalName是没有Endpoints的

• 资源清单示例

  • apiVersion: v1
    kind: Service
    metadata:
      name: myapp1
      namespace: default
    spec:
      type: ClusterIP
      # 通过标签来选择pod，需全部满足 当前环境下并没有携带app=myapp1的Pod，也就是该service连接不到任何Pod 所以Endpoints为null
      selector:
        app: myapp1
        release: stabel
      # 暴露端口
      ports:
      - name: http
        # 集群内部使用的端口
        port: 80
        # 转发到其下Pod的容器端口
        targetPort: 80
    

  • # 查看service
    [root@k8smaster services]# kubectl get svc
    NAME             TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                      AGE
    multi-port       NodePort       10.102.72.19    <none>          80:31277/TCP,443:31584/TCP   11s
    myapp1           ClusterIP      10.102.0.48     <none>          80/TCP                       17m
    
    # 查看endpoints 发现myapp1的为<none> 前面的Ip为Pod的ip，端口为targetPort
    [root@k8smaster services]# kubectl get endpoints -o wide
    NAME             ENDPOINTS                                                        AGE
    multi-port       10.244.1.76:9376,10.244.2.73:9376,10.244.2.74:9376 + 3 more...   63s
    myapp1           <none>                                                           18m
    
    # 查看pod 发现和endpoints中的ip一致
    [root@k8smaster services]# kubectl get pod -o wide
    NAME                            READY   STATUS    RESTARTS   AGE   IP            NODE       NOMINATED NODE   READINESS GATES
    myapp-deploy-7c4dbc97b9-7cdzf   1/1     Running   0          16h   10.244.2.74   k8snode1   <none>           <none>
    myapp-deploy-7c4dbc97b9-k44kg   1/1     Running   0          16h   10.244.2.73   k8snode1   <none>           <none>
    myapp-deploy-7c4dbc97b9-lglrv   1/1     Running   0          16h   10.244.1.76   k8snode2   <none>           <none>
    
    

• 这种情况下，我们需要手动创建Endpoints，将service和Pod进行关联

  • 资源清单示例

    • apiVersion: v1
      kind: Endpoints
      metadata:
        # 连接到的servcie名称 如果没有该service，会创建一个新的service 不会对原来的service进行更新
        name: myapp1
      subsets:
      # 连接Pod的Ip和port 外部的也可以
      - addresses:
        - IP: 10.244.2.74
        ports:
        - port: 80
      

    • # 创建endpoints 并查看
      [root@k8smaster services]# kubectl apply -f myapp1endpoints.yaml
      Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
      endpoints/myapp1 configured
      
      # 发现名为myapp1 的endpoints的ENDPOINTS 不在为<none> 为我们设置的值
      [root@k8smaster services]# kubectl get endpoints
      NAME             ENDPOINTS                                                        AGE
      multi-port       10.244.1.76:9376,10.244.2.73:9376,10.244.2.74:9376 + 3 more...   63m
      myapp1           10.244.2.74:80                                                   80m
      

8、service转发

• 我们使用上述NodePort的资源清单创建service 查看其转发规则

• 这就说明了创建NodePort的service，使用任意node:端口都能访问的原因（包含master），在每个node上都开启了该端口

• # 创建service
  [root@k8smaster services]# kubectl apply -f nodeport.yaml
  service/myapp-nodeport created
  
  # 查看service
  [root@k8smaster services]# kubectl get svc
  NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
  kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP        53s
  myapp-nodeport   NodePort    10.109.117.16   <none>        80:30001/TCP   10s
  
  # 查看service ipvs的转发 ipvsadm -Ln
  # 可以发现使用本机IP和127.0.0.1的30001端口 都会转发到任意Pod的80端口上
  # 使用CLUSTER-IP:80 都会转发到任意Pod的80端口上
  [root@k8smaster services]# ipvsadm -Ln
  IP Virtual Server version 1.2.1 (size=4096)
  Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
  
  TCP  192.168.47.150:30001 rr
    -> 10.244.1.76:80               Masq    1      0          0
    -> 10.244.2.73:80               Masq    1      0          0
    -> 10.244.2.74:80               Masq    1      0          0
  
  TCP  10.109.117.16:80 rr
    -> 10.244.1.76:80               Masq    1      0          0
    -> 10.244.2.73:80               Masq    1      0          0
    -> 10.244.2.74:80               Masq    1      0          0
  
  TCP  127.0.0.1:30001 rr
    -> 10.244.1.76:80               Masq    1      0          0
    -> 10.244.2.73:80               Masq    1      0          0
    -> 10.244.2.74:80               Masq    1      0          0
  
  UDP  10.96.0.10:53 rr
    -> 10.244.1.20:53               Masq    1      0          0
    -> 10.244.2.14:53               Masq    1      0          0
  
  # 还可以使用netstat -ano | grep 30001 查看