• Kubernetes崭露头角(Pod控制器详解)


    1、Pod控制器

    在kubernetes中,按照Pod的创建方式可以将其分为两类:

    • 自主式Pod:kubernetes直接创建出来的Pod,这种Pod删除后就没有了,也不会重建。

    • 控制器创建Pod:通过Pod控制器创建的Pod,这种Pod删除之后还会自动重建。

    Pod控制器:Pod控制器是管理Pod的中间层,使用了Pod控制器之后,我们只需要告诉Pod控制器,想要多少个什么样的Pod就可以了,它就会创建出满足条件的Pod并确保每一个Pod处于用户期望的状态,如果Pod在运行中出现故障,控制器会基于指定的策略重启或重建Pod。

    在kubernetes中,有很多类型的Pod控制器,每种都有自己的适合的场景,常见的有下面这些:

    • ReplicationController:比较原始的Pod控制器,已经被废弃,由ReplicaSet替代。

    • ReplicaSet:保证指定数量的Pod运行,并支持Pod数量变更,镜像版本变更。

    • Deployment:通过控制ReplicaSet来控制Pod,并支持滚动升级、版本回退。

    • Horizontal Pod Autoscaler:可以根据集群负载自动调整Pod的数量,实现削峰填谷。

    • DaemonSet:在集群中的指定Node上都运行一个副本,一般用于守护进程类的任务。

    • Job:它创建出来的Pod只要完成任务就立即退出,用于执行一次性任务。

    • CronJob:它创建的Pod会周期性的执行,用于执行周期性的任务。

    • StatefulSet:管理有状态的应用。

    2、ReplicaSet(RS)

    ReplicaSet的主要作用是保证一定数量的Pod能够正常运行,它会持续监听这些Pod的运行状态,一旦Pod发生故障,就会重启或重建。同时它还支持对Pod数量的扩缩容和版本镜像的升级。

    ReplicaSet的资源清单文件 :

    apiVersion: apps/v1 # 版本号 
    kind: ReplicaSet # 类型 
    metadata: # 元数据 
      name: # rs名称
      namespace: # 所属命名空间 
      labels: #标签 
        controller: rs 
    spec: # 详情描述 
      replicas: 3 # 副本数量 
      selector: # 选择器,通过它指定该控制器管理哪些pod
        matchLabels: # Labels匹配规则 
          app: nginx-pod 
        matchExpressions: # Expressions匹配规则 
          - {key: app, operator: In, values: [nginx-pod]} 
    template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本 
      metadata: 
        labels: 
          app: nginx-pod  # 与上面的Label对应
      spec: 
        containers: 
          - name: nginx 
            image: nginx:1.17.1 
            ports: 
            - containerPort: 80
            
    #在这里,需要新了解的配置项就是spec下面几个选项:
    
    # replicas:指定副本数量,其实就是当然rs创建出来的Pod的数量,默认为1.
    
    # selector:选择器,它的作用是建立Pod控制器和Pod之间的关联关系,采用了Label Selector机制(在Pod模块上定义Label,在控制器上定义选择器,就可以表明当前控制器能管理哪些Pod了)。
    
    # template:模板,就是当前控制器创建Pod所使用的模板,里面其实就是前面学过的Pod的定义。
    

    2.1、 创建ReplicaSet

    创建pc-replicaset.yaml文件

    apiVersion: apps/v1  # 版本号
    kind: ReplicaSet # 类型
    metadata:  # 元数据
      name: pc-replicaset  # rs的名称
      namespace: dev # 命名空间
    spec:
      replicas: 3 # 副本数量
      selector: # 选择器,通过它指定该控制器可以管理哪些Pod
        metchLabels: # Labels匹配规则
          app: nginx-pod
      template: # 模板 当副本数据不足时候,会更具下面的模板创建Pod副本
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
            - name: nginx # 容器名称
              image: nginx:1.17.1 # 容器需要的镜像地址
              ports:
                - containerPort: 80 # 容器所监听的端口
    

    创建和查看

    # 创建
    kubectl create -f pc-replicaset.yaml
    
    # 查看rs
    kubectl get rs -n dev -o wide
    
    NAME            DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES         SELECTOR
    pc-replicaset   3         3         3       19s   nginx        nginx:1.17.1   app=nginx-pod
    
    # 参数说明:
    #  DESIRED:期望的副本数量
    #  CURRENT:当前的副本数量
    #  READY:已就绪的副本数量
    
    # 查看创建的pod
    kubectl get pods -n dev
    
    NAME                  READY   STATUS    RESTARTS   AGE
    pc-replicaset-5djjp   1/1     Running   0          6m12s
    pc-replicaset-fj9mv   1/1     Running   0          6m12s
    pc-replicaset-nqc5h   1/1     Running   0          6m12s
    

    2.2、扩缩容

    扩缩容支持两种方式,一种是编辑文本配合,一种是通过命令行的方式。

    • 修改文件方式进行扩缩容
    # 编辑rs的副本数量,修改spec:replicas的数量即可,此处我将原来的3修改为6
    kubectl edit rs pc-replicaset -n dev
    
    # 查看rs,发现数量已经发生了变化
    kubectl get rs -n dev
    NAME            DESIRED   CURRENT   READY   AGE
    pc-replicaset   6         6         6       11m
    	
    # 查看pod
    NAME                  READY   STATUS    RESTARTS   AGE
    pc-replicaset-5djjp   1/1     Running   0          12m
    pc-replicaset-5gg6j   1/1     Running   0          116s
    pc-replicaset-6n27j   1/1     Running   0          116s
    pc-replicaset-fj9mv   1/1     Running   0          12m
    pc-replicaset-mnw76   1/1     Running   0          116s
    pc-replicaset-nqc5h   1/1     Running   0          12m
    
    • 使用命令行方式实现扩缩容

      使用scale命令实现扩缩容,后面加上--replicas=n直接指定目标数量即可

    # 这里我们将pod的数量恢复为3
    kubectl scale rs pc-replicaset --replicas=3 -n dev
    
    # 查看rs
    kubectl get rs -n dev
    
    NAME            DESIRED   CURRENT   READY   AGE
    pc-replicaset   3         3         3       17m
    
    # 查看pods
    kubectl get pods -n dev
     
    NAME                  READY   STATUS    RESTARTS   AGE
    pc-replicaset-5djjp   1/1     Running   0          17m
    pc-replicaset-fj9mv   1/1     Running   0          17m
    pc-replicaset-nqc5h   1/1     Running   0          17m
    

    2.3、镜像升级

    同样,镜像升级也分为两种方式,直接编辑配置文本和使用命令。

    • 编辑配置文件进行镜像升级
    # 将spec:containers:image:改掉对应的镜像版本即可
    # 此时,我将原来的1.17.1改为1.17.2
    kubectl edit rs pc-replicaset -n dev
    
    # 查看rs,不难发现镜像变成了17.2
    kubectl get rs -n dev -o wide
    NAME            DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES         SELECTOR
    pc-replicaset   3         3         3       31m   nginx        nginx:1.17.2   app=nginx-pod
    
    
    • 使用命令进行升级
    # 使用set命令实现镜像升级
    kubectl set image rs rs名称 容器名称=镜像版本 -n 命名空间
    
    kubectl set image rs pc-replicaset nginx=nginx:1.17.1 -n dev
    
    kubectl get rs -n dev -o wide
    NAME            DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES         SELECTOR
    pc-replicaset   3         3         3       34m   nginx        nginx:1.17.1   app=nginx-pod
    
    

    2.4、删除ReplicaSet

    使用kubectl delete rs 命令会删除ReplicaSet和其管理的Pod

    # 在kubernetes删除ReplicaSet前,会将ReplicaSet的replicas调整为0
    # 等到所有的Pod被删除后,再执行ReplicaSet对象的删除
    kubectl delete rs pc-replicaset -n dev
    

    如果希望仅仅删除ReplicaSet(保留Pod),只需要在使用kubectl delete rs命令后面加上--cascade=false选项(不推荐)

    kubectl delete rs pc-replicaset -n dev --cascade=false
    

    使用yaml直接删除(推荐):

    kubectl delete -f pc-replicaset.yaml
    

    3、Deployment(Deploy)

    为了更好的解决服务编排的问题,Kubernetes在v1.2版本开始,引入了Deployment控制器。值得一提的是,Deployment控制器并不直接管理Pod,而是通过管理ReplicaSet来简介管理Pod。即:Deployment管理ReplicaSet,ReplicaSet管理Pod。所以Deployment的功能比ReplicaSet强大。

    Deployment的主要功能如下:

    • 支持ReplicaSet的所有功能
    • 支持发布的停止和继续
    • 支持版本滚动更新和版本回退

    Deployment的资源清单:

    apiVersion: apps/v1 # 版本号 
    kind: Deployment # 类型 
    metadata: # 元数据 
      name: # rs名称 
      namespace: # 所属命名空间 
      labels: #标签 
        controller: deploy 
    spec: # 详情描述 
      replicas: 3 # 副本数量 
      revisionHistoryLimit: 3 # 保留历史版本,默认为10 
      paused: false # 暂停部署,默认是false 
      progressDeadlineSeconds: 600 # 部署超时时间(s),默认是600 
      strategy: # 策略 
        type: RollingUpdate # 滚动更新策略 
        rollingUpdate: # 滚动更新 
          maxSurge: 30% # 最大额外可以存在的副本数,可以为百分比,也可以为整数 
          maxUnavailable: 30% # 最大不可用状态的    Pod 的最大值,可以为百分比,也可以为整数 
      selector: # 选择器,通过它指定该控制器管理哪些pod 
        matchLabels: # Labels匹配规则 
          app: nginx-pod 
        matchExpressions: # Expressions匹配规则 
          - {key: app, operator: In, values: [nginx-pod]} 
      template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本 
        metadata: 
          labels: 
            app: nginx-pod 
        spec: 
          containers: 
          - name: nginx 
            image: nginx:1.17.1 
            ports: 
            - containerPort: 80
    

    3.1、创建Deployment

    创建pc-deployment.yaml文件,内容如下:

    apiVersion: apps/v1  # 版本号
    kind: Deployment # 类型
    metadata:  # 元数据
      name: pc-deployment  # deploy的名称
      namespace: dev # 命名空间
    spec:
      replicas: 3 # 副本数量
      selector: # 选择器,通过它指定该控制器可以管理哪些Pod
        matchLabels: # Labels匹配规则
          app: nginx-pod
      template: # 模板 当副本数据不足时候,会更具下面的模板创建Pod副本
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
            - name: nginx # 容器名称
              image: nginx:1.17.1 # 容器需要的镜像地址
              ports:
                - containerPort: 80 # 容器所监听的端口
    

    创建Deploy并查看

    # 创建
    kubectl create -f pc-deployment.yaml
    
    # 查看Deploy
    kubectl get deploy -n dev
    NAME            READY   UP-TO-DATE   AVAILABLE   AGE
    pc-deployment   3/3     3            3           87s
    
    # UP-TO-DATA:最新版本的Pod数量
    # AVAILABLE: 当前可用的Pod数量
    
    # 查看ReplicaSet
    kubectl get rs -n dev
    
    # 发现名称是deploy名称后添加了随机字串
    NAME                       DESIRED   CURRENT   READY   AGE
    pc-deployment-7d7dd5499b   3         3         3       3m40s
    
    
    # 查看pod
    kubectl get pods -n dev
    # pod名称实在rs名称技术上添加随机字串
    NAME                             READY   STATUS    RESTARTS   AGE
    pc-deployment-7d7dd5499b-pbqbm   1/1     Running   0          4m54s
    pc-deployment-7d7dd5499b-qpn6f   1/1     Running   0          4m54s
    pc-deployment-7d7dd5499b-szkdc   1/1     Running   0          4m54s
    

    3.2、扩缩容

    使用scale命令实现扩缩容,后面加上--replicas=n直接指定目标数量即可

    # 使用命令行扩容
    kubectl sacle deploy pc-deployment --replicas=5 -n dev
    
    kubectl get pods -n dev
    NAME                             READY   STATUS    RESTARTS   AGE
    pc-deployment-7d7dd5499b-ggtlw   1/1     Running   0          11s
    pc-deployment-7d7dd5499b-pbqbm   1/1     Running   0          25m
    pc-deployment-7d7dd5499b-q9zfc   1/1     Running   0          11s
    pc-deployment-7d7dd5499b-qpn6f   1/1     Running   0          25m
    pc-deployment-7d7dd5499b-szkdc   1/1     Running   0          25m
    

    编辑Delopyment,修改spec:replicas实现扩容

    kubectl edit deployment pc-depolyment -n dev
    # 将spec:replicas:5改为3
    
    # 查看pod
    kubectl get pods -n dev
    
    NAME                             READY   STATUS    RESTARTS   AGE
    pc-deployment-7d7dd5499b-ggtlw   1/1     Running   0          3m58s
    pc-deployment-7d7dd5499b-pbqbm   1/1     Running   0          29m
    pc-deployment-7d7dd5499b-qpn6f   1/1     Running   0          29m
    

    3.3、镜像更新

    Deployment支持两种镜像更新的策略:重建更新滚动更新(默认),可以通过strategy选项进行配置。

    strategy: # 指定新的Pod替代旧的Pod的策略,支持两个属性
      type: # 指定策略类型,支持两种策略
        Recreate:# 在创建出新的Pod之前会先杀掉所有已经存在的Pod
        RollingUpdate:# 滚动更新,就是杀死一部分,就启动一部分,在更新过程中,存在两个版本的Pod
      rollingUpdate:# 当type为RollingUpdate的时候生效,用于为rollingUpdate设置参数,支持两个属性:
        maxUnavailable:#用来指定在升级过程中不可用的Pod的最大数量,默认为25%。
        maxSurge: # 用来指定在升级过程中可以超过期望的Pod的最大数量,默认为25%。
    
    3.3.1、重建更新

    编辑pc-deployment.yaml文件,在spec节点下添加更新策略

    apiVersion: apps/v1  # 版本号
    kind: Deployment # 类型
    metadata:  # 元数据
      name: pc-deployment  # deploy的名称
      namespace: dev # 命名空间
    spec:
      replicas: 3 # 副本数量
      strategy: # 镜像更新策略
        type: Recreate # 在创建新的Pod之前,先杀掉所有存活的Pod
      selector: # 选择器,通过它指定该控制器可以管理哪些Pod
        matchLabels: # Labels匹配规则
          app: nginx-pod
      template: # 模板 当副本数据不足时候,会更具下面的模板创建Pod副本
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
            - name: nginx # 容器名称
              image: nginx:1.17.1 # 容器需要的镜像地址
              ports:
                - containerPort: 80 # 容器所监听的端口
    

    更新Deployment

    kubectl apply -f pc-deployment.yaml
    

    镜像升级

    kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev
    

    新开一个shell窗口,查看升级过程

    kubectl get pod -n dev -w
    
    NAME                             READY   STATUS    RESTARTS   AGE
    pc-deployment-7d7dd5499b-2hw4t   1/1     Running   0          78m
    pc-deployment-7d7dd5499b-9qtrc   1/1     Running   0          78m
    pc-deployment-7d7dd5499b-pt4p7   1/1     Running   0          78m
    
    pc-deployment-7d7dd5499b-2hw4t   1/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-9qtrc   1/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-pt4p7   1/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-pt4p7   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-2hw4t   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-9qtrc   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-pt4p7   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-pt4p7   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-9qtrc   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-9qtrc   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-2hw4t   0/1     Terminating   0          78m
    pc-deployment-7d7dd5499b-2hw4t   0/1     Terminating   0          78m
    
    pc-deployment-7bbbd589d5-qblm6   0/1     Pending       0          0s
    pc-deployment-7bbbd589d5-qblm6   0/1     Pending       0          0s
    pc-deployment-7bbbd589d5-94q2h   0/1     Pending       0          0s
    pc-deployment-7bbbd589d5-4jwmm   0/1     Pending       0          0s
    pc-deployment-7bbbd589d5-94q2h   0/1     Pending       0          1s
    pc-deployment-7bbbd589d5-4jwmm   0/1     Pending       0          1s
    
    pc-deployment-7bbbd589d5-qblm6   0/1     ContainerCreating   0          1s
    pc-deployment-7bbbd589d5-94q2h   0/1     ContainerCreating   0          1s
    pc-deployment-7bbbd589d5-4jwmm   0/1     ContainerCreating   0          1s
    
    pc-deployment-7bbbd589d5-94q2h   1/1     Running             0          29s
    pc-deployment-7bbbd589d5-qblm6   1/1     Running             0          31s
    pc-deployment-7bbbd589d5-4jwmm   1/1     Running             0          52s
    
    
    3.3.2、滚动更新

    编辑pc_deployment.yaml文件,在spec节点下添加更新策略

    apiVersion: apps/v1  # 版本号
    kind: Deployment # 类型
    metadata:  # 元数据
      name: pc-deployment  # deploy的名称
      namespace: dev # 命名空间
    spec:
      replicas: 3 # 副本数量
      strategy: # 镜像更新策略
        type: RollingUpdate # 滚动更新
        rollingUpdate:
          maxUnavailable: 25% # 升级中不可用的Pod最大数量
          maxSurge: 25%   # 可以超过期望的Pod的最大数量
      selector: # 选择器,通过它指定该控制器可以管理哪些Pod
        matchLabels: # Labels匹配规则
          app: nginx-pod
      template: # 模板 当副本数据不足时候,会更具下面的模板创建Pod副本
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
            - name: nginx # 容器名称
              image: nginx:1.17.1 # 容器需要的镜像地址
              ports:
                - containerPort: 80 # 容器所监听的端口
    
    

    镜像升级

    kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev
    

    新开shell窗口,查看升级过程

    NAME                             READY   STATUS    RESTARTS   AGE
    pc-deployment-7d7dd5499b-nsrrx   1/1     Running   0          2m45s
    pc-deployment-7d7dd5499b-q675w   1/1     Running   0          2m45s
    pc-deployment-7d7dd5499b-ttgft   1/1     Running   0          2m45s
    pc-deployment-866fdcbd54-zn2jj   0/1     Pending   0          0s
    pc-deployment-866fdcbd54-zn2jj   0/1     Pending   0          0s
    pc-deployment-866fdcbd54-zn2jj   0/1     ContainerCreating   0          0s
    pc-deployment-866fdcbd54-zn2jj   1/1     Running             0          31s
    pc-deployment-7d7dd5499b-ttgft   1/1     Terminating         0          3m37s
    pc-deployment-866fdcbd54-q6q7x   0/1     Pending             0          0s
    pc-deployment-866fdcbd54-q6q7x   0/1     Pending             0          0s
    pc-deployment-866fdcbd54-q6q7x   0/1     ContainerCreating   0          0s
    pc-deployment-7d7dd5499b-ttgft   0/1     Terminating         0          3m39s
    pc-deployment-7d7dd5499b-ttgft   0/1     Terminating         0          3m40s
    pc-deployment-7d7dd5499b-ttgft   0/1     Terminating         0          3m40s
    pc-deployment-866fdcbd54-q6q7x   1/1     Running             0          43s
    pc-deployment-7d7dd5499b-nsrrx   1/1     Terminating         0          4m20s
    pc-deployment-866fdcbd54-k9gqt   0/1     Pending             0          0s
    pc-deployment-866fdcbd54-k9gqt   0/1     Pending             0          0s
    pc-deployment-866fdcbd54-k9gqt   0/1     ContainerCreating   0          0s
    pc-deployment-866fdcbd54-k9gqt   1/1     Running             0          2s
    pc-deployment-7d7dd5499b-q675w   1/1     Terminating         0          4m22s
    pc-deployment-7d7dd5499b-nsrrx   0/1     Terminating         0          4m22s
    pc-deployment-7d7dd5499b-q675w   0/1     Terminating         0          4m23s
    pc-deployment-7d7dd5499b-nsrrx   0/1     Terminating         0          4m33s
    pc-deployment-7d7dd5499b-nsrrx   0/1     Terminating         0          4m33s
    pc-deployment-7d7dd5499b-q675w   0/1     Terminating         0          4m33s
    pc-deployment-7d7dd5499b-q675w   0/1     Terminating         0          4m33s
    
    

    滚动更新的图解过程:

    镜像更新中rs的变化:

    查看rs,发现原来的rs依旧存在,只是Pod的数量变为0,而后又产生了一个rs,pod的数量变为3.

    其实这就是deployment您能够进行版本回退的奥妙所在。

    kubectl get rs -n dev
    
    NAME                       DESIRED   CURRENT   READY   AGE
    pc-deployment-7d7dd5499b   0         0         0       5m7s
    pc-deployment-866fdcbd54   3         3         3       10s
    

    3.4、版本回退

    Deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能,下面具体来看。

    kubectl rollout:版本升级相关功能,支持下面的选项:

    • status 显示当前升级状态
    • history 显示升级历史记录
    • pause 暂停版本能升级过程
    • resume 继续版本升级过程
    • restart 重启版本升级过程
    • undo 回滚到上一级版本(可以使用--to-revision回滚到指定版本)

    1)、查看当前升级版本状态

    kubectl rollout status deployment pc-deployment -n dev
    
    > deployment "pc-deployment" successfully rolled out
    

    2)、查看升级历史记录

    kubectl rollout history deployment pc-deployment -n dev
    
    REVISION  CHANGE-CAUSE
    1         <none>
    2         <none>
    3         <none>
    

    3)、版本回退

    可以使用-to-revision=1回退到1版本,如果省略这个选项,就会回退到上一个版本

    # 进行版本回退
    kubectl rollout undo deploy pc-deployment --to-revision=1 -n dev
    
    # 查看rs
    kubectl get rs -n dev
    NAME                       DESIRED   CURRENT   READY   AGE
    pc-deployment-56f77b8695   0         0         0       2m42s
    pc-deployment-7d7dd5499b   5         5         5       19m
    pc-deployment-866fdcbd54   0         0         0       14m
    
    

    deployment之所以能实现版本的回退,就是通过记录下历史的ReplicaSet来实现的,一旦想要回退到哪个版本,只需将当前版本的Pod数量降为0,然后将回退版本的Pod提升为目标数量即可。

    3.5、金丝雀发布

    Deployment支持更新过程的控制,如暂停更新操作(pause)或继续更新操作(resume)。

    例如有一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后再筛选出一小部分的用户请求到新版本的Pod应用,继续观察能够稳定的按照期望方式运行,如果没有问题之后再继续完成余下的Pod资源的滚动更新,否则立即回滚操作。

    1)、更新deployment版本,并配置暂停Deployment:

    kubectl set image deployment pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment -n dev
    
    kubectl get rs -n dev
    
    NAME                       DESIRED   CURRENT   READY   AGE
    pc-deployment-56f77b8695   3         3         3       21m
    pc-deployment-7d7dd5499b   4         4         4       37m
    pc-deployment-866fdcbd54   0         0         0       32m
    
    

    2)、查看更新状态

    kubectl rollout status deployment pc-deployment -n dev
    
    Waiting for deployment "pc-deployment" rollout to finish: 3 out of 5 new replicas have been updated...
    

    3)、监控更细那过程

    kubectl get rs -n dev -o wide
    
    NAME                       DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES         SELECTOR
    pc-deployment-56f77b8695   3         3         3       26m   nginx        nginx:1.17.4   app=nginx-pod,pod-template-hash=56f77b8695
    pc-deployment-7d7dd5499b   4         4         4       43m   nginx        nginx:1.17.1   app=nginx-pod,pod-template-hash=7d7dd5499b
    pc-deployment-866fdcbd54   0         0         0       38m   nginx        nginx:1.17.3   app=nginx-pod,pod-template-hash=866fdcbd54
    
    
    # 我们可以看到新增了三个资源,但是没有按照预期的状态去删除三个玖资源
    # 因为这里使用了pause暂停命令
    

    4)、确保更新的Pod没问题后,继续更新

    kubectl get pod -n dev
    
    NAME                             READY   STATUS    RESTARTS   AGE
    pc-deployment-56f77b8695-8lc7l   1/1     Running   0          7m36s
    pc-deployment-56f77b8695-9mspz   1/1     Running   0          7m36s
    pc-deployment-56f77b8695-zpp56   1/1     Running   0          7m36s
    pc-deployment-7d7dd5499b-j887b   1/1     Running   0          26m
    pc-deployment-7d7dd5499b-pzmdz   1/1     Running   0          26m
    pc-deployment-7d7dd5499b-rdsqr   1/1     Running   0          26m
    pc-deployment-7d7dd5499b-trzct   1/1     Running   0          26m
    
    # 继续更新
    kubectl rollout resume deployment pc-deployment -n dev
    
    # 查看rs
    kubectl get rs -n dev
    NAME                       DESIRED   CURRENT   READY   AGE
    pc-deployment-56f77b8695   5         5         5       29m
    pc-deployment-7d7dd5499b   0         0         0       46m
    pc-deployment-866fdcbd54   0         0         0       41m
    
    # 查看pod
    kubectl get pods -n dev
    NAME                             READY   STATUS    RESTARTS   AGE
    pc-deployment-56f77b8695-6dl66   1/1     Running   0          48s
    pc-deployment-56f77b8695-8dzw6   1/1     Running   0          48s
    pc-deployment-56f77b8695-8lc7l   1/1     Running   0          8m57s
    pc-deployment-56f77b8695-9mspz   1/1     Running   0          8m57s
    pc-deployment-56f77b8695-zpp56   1/1     Running   0          8m57s
    

    4、Horizontal Pod Autoscaler(HPA)

    我们在前面已经通过手动执行kubeclt sacle命令实现Pod的扩缩容,但是这显然不符合Kubernetes的定位目标—自动化和智能化。Kubernetes期望可以通过监测Pod的使用情况,实现Pod数量的自动调整,于是就产生了HPA这种控制器。

    HPA可以获取每个Pod的利用率,然后和HPA中定义的指标进行对比,同时计算出需要伸缩的具体值,最后实现Pod的数量调整。其实HPA和之前的Deployment一样,也属于一种Kubernetes资源对象,它通过追踪分析目标Pod的负载变化情况,来确定是否需要针对性的调整目标Pod的副本数。

    4.1、安装metrice-server(v0.3.6)

    metrics-server可以用来收集集群中的资源还是用情况。

    1)、获取metrics-server,需要注意使用的版本

    git clone -b 0.3.6 https://github.com/kubernetes-sigs/metrics-server.git
    

    2)、修改metrics-server-deployment.yaml文件

    cd metrics-server-0.3.6/deploy/1.8+/
    
    vim metrics-server-deployment.yaml
    
    # 按图中添加下面选项
    hostNetwork: true
    image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6 
    args:
      - --kubelet-insecure-tls 
      - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
    

    3)、安装metrics-server

    kubectl apply -f ./
    

    4)、查看metrics-server生成的Pod

    kubectl get pod -n kube-system
    # 最后一条就是metrics-server生成的
    
    NAME                              READY   STATUS    RESTARTS   AGE
    coredns-7ff77c879f-4kmfg          1/1     Running   0          4h8m
    coredns-7ff77c879f-k7sxn          1/1     Running   0          4h8m
    etcd-master                       1/1     Running   0          4h8m
    kube-apiserver-master             1/1     Running   0          4h8m
    kube-controller-manager-master    1/1     Running   0          4h8m
    kube-proxy-g6dt5                  1/1     Running   0          4h8m
    kube-proxy-h6ql9                  1/1     Running   0          4h8m
    kube-proxy-pmrj2                  1/1     Running   0          4h8m
    kube-scheduler-master             1/1     Running   0          4h8m
    metrics-server-5f55b696bd-k4hjm   1/1     Running   0          3m8s
    

    5)、查看资源使用情况

    kubectl top node && kubectl top pod -n kube-system
    
    NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
    master   417m         5%     1210Mi          32%       
    node1    77m          0%     523Mi           15%       
    node2    104m         1%     558Mi           15%       
    NAME                              CPU(cores)   MEMORY(bytes)   
    coredns-7ff77c879f-4kmfg          9m           13Mi            
    coredns-7ff77c879f-k7sxn          8m           10Mi            
    etcd-master                       39m          70Mi            
    kube-apiserver-master             388m         293Mi           
    kube-controller-manager-master    56m          44Mi            
    kube-proxy-g6dt5                  2m           14Mi            
    kube-proxy-h6ql9                  1m           14Mi            
    kube-proxy-pmrj2                  1m           12Mi            
    kube-scheduler-master             10m          17Mi            
    metrics-server-5f55b696bd-k4hjm   3m           11Mi  
    

    4.2、准备Deployment和Service

    1)、创建Deployment

    创建nginx.yaml文件。

    apiVersion: apps/v1 # 版本号
    kind: Deployment # 类型
    metadata: # 元数据
      name: nginx # deployment的名称
      namespace: dev # 命名类型
    spec: # 详细描述
      selector: # 选择器,通过它指定该控制器可以管理哪些Pod
        matchLabels: # Labels匹配规则
          app: nginx-pod
      template: # 模块 当副本数据不足的时候,会根据下面的模板创建Pod副本
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
            - name: nginx # 容器名称
              image: nginx:1.17.1 # 容器需要的镜像地址
              ports:
                - containerPort: 80 # 容器所监听的端口
                  protocol: TCP
              resources: # 资源限制
                requests:
                  cpu: "100m" # 100m表示100millicpu,即0.1个CPU
    

    2)、创建Deployment以及查看Deployment和Pod

    # 创建
    kubectl create -f nginx.yaml
    
    # 查看Depolyment和Pod
    kubectl get pod,deploy -n dev
    
    NAME                         READY   STATUS    RESTARTS   AGE
    pod/nginx-587f44948f-c6vdq   1/1     Running   0          115s
    
    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/nginx   1/1     1            1           115s
    
    

    3)、创建Service

    # 创建
    kubectl expose deployment nginx --name=nginx --type=NodePort --port=80 --target-port=80 -n dev
    
    # 查看
    kubectl get svc -n dev
    
    NAME    TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
    nginx   NodePort   10.108.192.175   <none>        80:32362/TCP   5m5s
    

    4.3、部署HPA

    1)、创建pc-hpa.yaml文件

    apiVersion: autoscaling/v1 # 版本号
    kind: HorizontalPodAutoscaler # 类型
    metadata: # 元数据
      name: pc-hpa # deployment的名称
      namespace: dev # 命名类型
    spec:
      minReplicas: 1 # 最小Pod数量
      maxReplicas: 10 # 最大Pod数量
      targetCPUUtilizationPercentage: 3 # CPU使用率指标
      scaleTargetRef:  # 指定要控制的Nginx的信息
        apiVersion: apps/v1
        kind: Deployment
        name: nginx
    

    2)、创建以及查看

    # 创建
    kubectl create -f pc-hpa.yaml
    
    # 查看
    kubectl get hpa -n dev
    
    NAME     REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
    pc-hpa   Deployment/nginx   0%/3%     1         10        1          69s
    

    4.4、测试

    此处我们使用Go写一段脚本,并发访问

    package testing
    
    import (
    	"fmt"
    	"net/http"
    	"testing"
    )
    
    func Test_k8s(t *testing.T) {
    	for i := 0 ; i < 10000; i ++ {
    		go func(){
    			resp, err := http.Get("http://192.168.209.136:32362")
    			if err != nil {
    				fmt.Println(err)
    			} else {
    				fmt.Println(resp)
    			}
    		}()
    	}
    	select{}
    }
    

    1)、hpa的变化

    kubectl get hpa -n dev -w 
    
    NAME     REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
    pc-hpa   Deployment/nginx   0%/3%     1         10        1          20m
    pc-hpa   Deployment/nginx   438%/3%   1         10        1          26m
    pc-hpa   Deployment/nginx   438%/3%   1         10        4          27m
    pc-hpa   Deployment/nginx   438%/3%   1         10        8          27m
    pc-hpa   Deployment/nginx   438%/3%   1         10        10         27m
    pc-hpa   Deployment/nginx   0%/3%     1         10        10         27m
    

    2)、deployment的变化

    kubectl get deployment -n dev -w
    NAME    READY   UP-TO-DATE   AVAILABLE   AGE
    nginx   1/1     1            1           28m
    nginx   1/4     1            1           34m
    nginx   1/4     1            1           34m
    nginx   1/4     1            1           34m
    nginx   1/4     4            1           34m
    nginx   2/4     4            2           34m
    nginx   3/4     4            3           34m
    nginx   4/4     4            4           34m
    nginx   4/8     4            4           34m
    nginx   4/8     4            4           34m
    nginx   4/8     4            4           34m
    nginx   4/8     8            4           34m
    nginx   5/8     8            5           34m
    nginx   6/8     8            6           34m
    nginx   7/8     8            7           34m
    nginx   8/8     8            8           34m
    nginx   8/10    8            8           34m
    nginx   8/10    8            8           34m
    nginx   8/10    8            8           34m
    nginx   8/10    10           8           34m
    nginx   9/10    10           9           34m
    nginx   10/10   10           10          34m
    
    

    3)、Pod的变化

     kubectl get pod -n dev -w
    NAME                     READY   STATUS    RESTARTS   AGE
    nginx-587f44948f-clwwx   1/1     Running   0          28m
    nginx-587f44948f-vddtt   0/1     Pending   0          0s
    nginx-587f44948f-cdhwv   0/1     Pending   0          0s
    nginx-587f44948f-vhf57   0/1     Pending   0          0s
    nginx-587f44948f-vddtt   0/1     Pending   0          0s
    nginx-587f44948f-cdhwv   0/1     Pending   0          0s
    nginx-587f44948f-vhf57   0/1     Pending   0          0s
    nginx-587f44948f-cdhwv   0/1     ContainerCreating   0          0s
    nginx-587f44948f-vddtt   0/1     ContainerCreating   0          0s
    nginx-587f44948f-vhf57   0/1     ContainerCreating   0          0s
    nginx-587f44948f-cdhwv   1/1     Running             0          4s
    nginx-587f44948f-vhf57   1/1     Running             0          4s
    nginx-587f44948f-vddtt   1/1     Running             0          4s
    nginx-587f44948f-wfj5n   0/1     Pending             0          0s
    nginx-587f44948f-wfj5n   0/1     Pending             0          0s
    nginx-587f44948f-vf5cl   0/1     Pending             0          0s
    nginx-587f44948f-vmtv5   0/1     Pending             0          0s
    nginx-587f44948f-7bwbs   0/1     Pending             0          0s
    nginx-587f44948f-vf5cl   0/1     Pending             0          0s
    nginx-587f44948f-vmtv5   0/1     Pending             0          0s
    nginx-587f44948f-7bwbs   0/1     Pending             0          0s
    nginx-587f44948f-vf5cl   0/1     ContainerCreating   0          0s
    nginx-587f44948f-7bwbs   0/1     ContainerCreating   0          0s
    nginx-587f44948f-wfj5n   0/1     ContainerCreating   0          0s
    nginx-587f44948f-vmtv5   0/1     ContainerCreating   0          0s
    nginx-587f44948f-7bwbs   1/1     Running             0          4s
    nginx-587f44948f-vf5cl   1/1     Running             0          4s
    nginx-587f44948f-vmtv5   1/1     Running             0          4s
    nginx-587f44948f-wfj5n   1/1     Running             0          4s
    nginx-587f44948f-t77wd   0/1     Pending             0          0s
    nginx-587f44948f-t77wd   0/1     Pending             0          0s
    nginx-587f44948f-rt2rl   0/1     Pending             0          0s
    nginx-587f44948f-rt2rl   0/1     Pending             0          0s
    nginx-587f44948f-t77wd   0/1     ContainerCreating   0          0s
    nginx-587f44948f-rt2rl   0/1     ContainerCreating   0          0s
    nginx-587f44948f-t77wd   1/1     Running             0          2s
    nginx-587f44948f-rt2rl   1/1     Running             0          2s
    

    5、DaemonSet(DS)

    DaemonSet类型的控制器可以保证集群中的每一台(或指定)节点上都运行一个副本,一般适用于日志收集,节点监控等场景,也就是说,如果一个Pod提供的功能是节点级别的(每个节点都需要且只需要一个),那么这类Pod就适合使用DaemonSet类型的控制器创建。

    DaemonSet控制器的特点:

    • 每向集群中添加一个节点时候,指定的Pod副本也将添加到该节点上。
    • 当节点从集群中移除时,Pod也会被垃圾回收。

    DaemonSet的资源清单:

    apiVersion: apps/v1 # 版本号
    kind: DaemonSet # 类型
    metadata: # 元数据
      name: # 名称
      namespace: #命名空间
      labels: #标签
        controller: daemonset
    spec: # 详情描述
      revisionHistoryLimit: 3 # 保留历史版本
      updateStrategy: # 更新策略
        type: RollingUpdate # 滚动更新策略
        rollingUpdate: # 滚动更新
          maxUnavailable: 1 # 最大不可用状态的Pod的最大值,可用为百分比,也可以为整数
      selector: # 选择器,通过它指定该控制器管理那些Pod
        matchLabels: # Labels匹配规则
          app: nginx-pod
        matchExpressions: # Expressions匹配规则
          - key: app
            operator: In
            values:
              - nginx-pod
      template: # 模板,当副本数量不足时,会根据下面的模板创建Pod模板
         metadata:
           labels:
             app: nginx-pod
         spec:
           containers:
             - name: nginx
               image: nginx:1.17.1
               ports:
                 - containerPort: 80
    

    5.1、创建DaemonSet

    1)、创建pc-daemonset.yaml文件

    apiVersion: apps/v1 # 版本号
    kind: DaemonSet # 类型
    metadata: # 元数据
      name: pc-damonset # 名称
      namespace: dev #命名空间
    spec: # 详情描述
      selector: # 选择器,通过它指定该控制器管理那些Pod
        matchLabels: # Labels匹配规则
          app: nginx-pod
      template: # 模板,当副本数量不足时,会根据下面的模板创建Pod模板
         metadata:
           labels:
             app: nginx-pod
         spec:
           containers:
             - name: nginx
               image: nginx:1.17.1
               ports:
                 - containerPort: 80
    

    2)、创建DaemonSet

    kubectl create -f pc-daemonset.yaml
    

    5.2、查看以及删除

    1)、查看

    kubectl get ds -n dev -o wide
    
    NAME          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS   IMAGES         SELECTOR
    pc-damonset   2         2         2       2            2           <none>          66s   nginx        nginx:1.17.1   app=nginx-pod
    
    # 查看pod
    kubectl get pods -n dev -o wide
    
    # 发现新创建的两个pod一个在node1上,一个在node2
    NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
    nginx-587f44948f-clwwx   1/1     Running   0          56m   10.244.2.2   node1   <none>           <none>
    pc-damonset-szdnr        1/1     Running   0          94s   10.244.2.7   node1   <none>           <none>
    pc-damonset-zfwxr        1/1     Running   0          94s   10.244.1.9   node2   <none>           <none>
    
    

    2)、删除

    # 删除
    kubectl delete ds pc-damonset -n dev
    
    # 查看pod
    kubectl get pods -n dev -o wide
    # 创建的pod被销毁
    NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
    nginx-587f44948f-clwwx   1/1     Running   0          58m   10.244.2.2   node1   <none>           <none>
    

    6、Job

    Job主要用于负责批量(一次要处理指定数量任务)处理短暂的一次性(每个任务仅运行一次就结束)任务。

    Job的特点:

    • 当Job创建的Pod执行成功结束时,Job将记录成功结束的Pod数量。

    • 当成功结束的Pod达到指定的数量时,Job将完成执行。

    Job可以保证指定数量的Pod执行完成。

    Job的资源清单:

    apiVersion: batch/v1 # 版本号
    kind: Job # 类型
    metadata: # 元数据
      name:  # 名称
      namespace:  #命名空间
      labels: # 标签
        controller: job
    spec: # 详情描述
      completions: 1 # 指定Job需要成功运行Pod的总次数,默认为1
      parallelism: 1 # 指定Job在任一时刻应该并发运行Pod的数量,默认为1
      activeDeadlineSeconds: 30 # 指定Job可以运行的时间期限,超过时间还没结束,系统将会尝试进行终止
      backoffLimit: 6 # 指定Job失败后进行重试的次数,默认为6
      manualSelector: true # 是否可以使用selector选择器选择Pod,默认为false
      selector: # 选择器,通过它指定该控制器管理那些Pod
        matchLabels: # Labels匹配规则
          app: counter-pod
        matchExpressions: # Expressions匹配规则
          - key: app
            operator: In
            values:
              - counter-pod
      template: # 模板,当副本数量不足时,会根据下面的模板创建Pod模板
         metadata:
           labels:
             app: counter-pod
         spec:
           restartPolicy: Never # 重启策略只能设置为Never或OnFailure
           containers:
             - name: counter
               image: busybox:1.30
               command: ["/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 20;done"]
    

    关于模板中的重启策略的说明:

    • 如果设置为OnFailure,则Job会在Pod出现故障的时候重启容器,而不是创建Pod,failed次数不变。

    • 如果设置为Never,则Job会在Pod出现故障的时候创建新的Pod,并且故障Pod不会消失,也不会重启,failed次数+1。

    • 如果指定为Always的话,就意味着一直重启,意味着Pod任务会重复执行,这和Job的定义冲突,所以不能设置为Always。

    6.1、创建Job以及查看

    1、创建pc-job.yaml文件

    apiVersion: batch/v1 # 版本号
    kind: Job # 类型
    metadata: # 元数据
      name: pc-job # 名称
      namespace: dev #命名空间
    spec: # 详情描述
      manualSelector: true # 是否可以使用selector选择器选择Pod,默认为false
      selector: # 选择器,通过它指定该控制器管理那些Pod
        matchLabels: # Labels匹配规则
          app: counter-pod
      template: # 模板,当副本数量不足时,会根据下面的模板创建Pod模板
        metadata:
          labels:
            app: counter-pod
        spec:
          restartPolicy: Never # 重启策略只能设置为Never或OnFailure
          containers:
            - name: counter
              image: busybox:1.30
              command: [ "/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 3;done" ]
    

    2)、创建Job

    kubectl create -f pc-job.yaml
    

    3)、查看

    # 查看job
    kubectl get job -n dev -w
    
    # 查看pod
    kubectl get pod -n dev -w
    

    6.2、删除

    1)、删除Job

    kubectl delete -f pc-job.yaml
    

    7、CronJob(CJ)

    CronJob控制器以Job控制器为其管控对象,并借助它管理Pod资源对象,Job控制器定义的作业任务在其控制器资源创建之后便会立即执行,但CronJob可以以类似Linux操作系统的周期性任务作业计划的方式控制器运行时间点及重复运行的方式,换言之,CronJob可以在特定的时间点反复去执行Job任务。

    CronJob的资源清单

    apiVersion: batch/v1beta1 # 版本号
    kind: CronJob # 类型
    metadata: # 元数据
      name:  # 名称
      namespace:  #命名空间
      labels:
        controller: cronjob
    spec: # 详情描述
      schedule: # cron格式的作业调度运行时间点,用于控制任务任务时间执行
      concurrencyPolicy: # 并发执行策略
      failedJobsHistoryLimit: # 为失败的任务执行保留的历史记录数,默认为1
      successfulJobsHistoryLimit: # 为成功的任务执行保留的历史记录数,默认为3
      jobTemplate: # job控制器模板,用于为cronjob控制器生成job对象,下面其实就是job的定义
        metadata: {}
        spec:
          completions: 1 # 指定Job需要成功运行Pod的总次数,默认为1
          parallelism: 1 # 指定Job在任一时刻应该并发运行Pod的数量,默认为1
          activeDeadlineSeconds: 30 # 指定Job可以运行的时间期限,超过时间还没结束,系统将会尝试进行终止
          backoffLimit: 6 # 指定Job失败后进行重试的次数,默认为6
          template: # 模板,当副本数量不足时,会根据下面的模板创建Pod模板
            spec:
              restartPolicy: Never # 重启策略只能设置为Never或OnFailure
              containers:
                - name: counter
                  image: busybox:1.30
                  command: [ "/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 20;done" ]
    

    说明:

    schedule:cron表达式,用于指定任务的执行时间。
    */1  *  *  *  *:表示分钟  小时  日  月份  星期。
    分钟的值从0到59。
    小时的值从0到23。
    日的值从1到31。
    月的值从1到12。
    星期的值从0到6,0表示星期日。
    多个时间可以用逗号隔开,范围可以用连字符给出:* 可以作为通配符,/表示每...
    concurrencyPolicy:并发执行策略
    Allow:运行Job并发运行(默认)。
    Forbid:禁止并发运行,如果上一次运行尚未完成,则跳过下一次运行。
    Replace:替换,取消当前正在运行的作业并使用新作业替换它。
    

    7.1、创建CronJob

    创建pc-cronjob.yaml文件,内容如下

    apiVersion: batch/v1beta1 # 版本号
    kind: CronJob # 类型
    metadata: # 元数据
      name: pc-cronjob # 名称
      namespace: dev  #命名空间
    spec: # 详情描述
      schedule: "*/1 * * * * " # cron格式的作业调度运行时间点,用于控制任务任务时间执行
      jobTemplate: # job控制器模板,用于为cronjob控制器生成job对象,下面其实就是job的定义
        metadata: {}
        spec:
          template: # 模板,当副本数量不足时,会根据下面的模板创建Pod模板
            spec:
              restartPolicy: Never # 重启策略只能设置为Never或OnFailure
              containers:
                - name: counter
                  image: busybox:1.30
                  command: [ "/bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1;do echo $i;sleep 2;done" ]
    

    7.2、查看

    1)、查看CronJob

    get cj -n dev -w
    NAME         SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    pc-cronjob   */1 * * * *    False     1        5s              19s
    pc-cronjob   */1 * * * *    False     0        30s             44s
    pc-cronjob   */1 * * * *    False     1        0s              74s
    pc-cronjob   */1 * * * *    False     0        30s             104s
    pc-cronjob   */1 * * * *    False     1        0s              2m14s
    pc-cronjob   */1 * * * *    False     0        30s             2m44s
    pc-cronjob   */1 * * * *    False     1        0s              3m14s
    pc-cronjob   */1 * * * *    False     0        20s             3m34s
    pc-cronjob   */1 * * * *    False     1        0s              4m14s
    pc-cronjob   */1 * * * *    False     0        30s             4m44s
    pc-cronjob   */1 * * * *    False     1        0s              5m14s
    pc-cronjob   */1 * * * *    False     0        30s             5m44s
    
    

    2)、查看job

    kubectl get job -n dev -w
    NAME                    COMPLETIONS   DURATION   AGE
    pc-cronjob-1628532960   0/1           16s        16s
    pc-job                  1/1           30s        41m
    pc-cronjob-1628532960   1/1           20s        20s
    pc-cronjob-1628533020   0/1                      0s
    pc-cronjob-1628533020   0/1           0s         0s
    pc-cronjob-1628533020   1/1           20s        20s
    pc-cronjob-1628533080   0/1                      0s
    pc-cronjob-1628533080   0/1           0s         0s
    pc-cronjob-1628533080   1/1           20s        20s
    pc-cronjob-1628533140   0/1                      0s
    pc-cronjob-1628533140   0/1           0s         0s
    pc-cronjob-1628533140   1/1           20s        20s
    
    

    8、StatefulSet(有状态)

    无状态应用:

    • 认为Pod都是一样的。

    • 没有顺序要求。

    • 不用考虑在哪个Node节点上运行。

    • 随意进行伸缩和扩展。

    有状态应用:

    • 有顺序的要求。

    • 认为每个Pod都是不一样的。

    • 需要考虑在哪个Node节点上运行。

    • 需要按照顺序进行伸缩和扩展。

    • 让每个Pod都是独立的,保持Pod启动顺序和唯一性。

    StatefulSet是Kubernetes提供的管理有状态应用的负载管理控制器。

    StatefulSet部署需要HeadLinessService(无头服务)。

    为什么需要HeadLinessService(无头服务)?

    在用Deployment时,每一个Pod名称是没有顺序的,是随机字符串,因此是Pod名称是无序的,但是在StatefulSet中要求必须是有序 ,每一个Pod不能被随意取代,Pod重建后pod名称还是一样的。

    而Pod IP是变化的,所以是以Pod名称来识别。Pod名称是Pod唯一性的标识符,必须持久稳定有效。这时候要用到无头服务,它可以给每个Pod一个唯一的名称 。

    StatefulSet常用来部署RabbitMQ集群、Zookeeper集群、MySQL集群、Eureka集群等。

    8.1、创建StatefulSet

    1)、创建pc-stateful.yaml文件

    apiVersion: v1
    kind: Service
    metadata:
      name: service-headliness
      namespace: dev
    spec:
      selector:
        app: nginx-pod
      clusterIP: None # 将clusterIP设置为None,即可创建headliness Service
      type: ClusterIP
      ports:
        - port: 80 # Service的端口
          targetPort: 80 # Pod的端口
    ---
    
    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: pc-statefulset
      namespace: dev
    spec:
      replicas: 3
      serviceName: service-headliness
      selector:
        matchLabels:
          app: nginx-pod
      template:
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
            - name: nginx
              image: nginx:1.17.1
              ports:
                - containerPort: 80
    

    2)、创建StatefulSet

    kubectl create -f pc-stateful.yaml
    

    8.2、查看

    1)、查看StatefulSet

    kubectl get statefulset pc-statefulset -n dev -o wide
    
    NAME             READY   AGE   CONTAINERS   IMAGES
    pc-statefulset   3/3     11s   nginx        nginx:1.17.1
    

    2)、查看pod

    kubectl get pod -n dev -o wide
    
    NAME                     READY   STATUS      RESTARTS   AGE    IP            NODE    NOMINATED NODE   READINESS GATES
    nginx-587f44948f-clwwx   1/1     Running     0          172m   10.244.2.2    node1   <none>           <none>
    pc-job-gx96m             0/1     Completed   0          60m    10.244.2.8    node1   <none>           <none>
    pc-statefulset-0         1/1     Running     0          22s    10.244.1.10   node2   <none>           <none>
    pc-statefulset-1         1/1     Running     0          20s    10.244.2.22   node1   <none>           <none>
    pc-statefulset-2         1/1     Running     0          18s    10.244.1.11   node2   <none>           <none>
    
    

    8.3、Deployment和StatefulSet的区别

    • Deployment没有唯一标识而StatefulSet有唯一标识。

    • StatefulSet的唯一标识是根据主机名+一定规则生成的。

      StatefulSet的唯一标识是主机名.无头Service名称.命名空间.svc.cluster.local

    8.4、StatefulSet的金丝雀发布

    StatefulSet支持两种更新策略:OnDelete和RollingUpdate(默认),其中OnDelete表示删除之后才更新,RollingUpdate表示滚动更新。

    updateStrategy:
      rollingUpdate: # 如果更新的策略是OnDelete,那么rollingUpdate就失效
        partition: 2 # 表示从第2个分区开始更新,默认是0
      type: RollingUpdate /OnDelete # 滚动更新/删除之后更新
    

    1)、创建pc-statefulset.yaml

    apiVersion: v1
    kind: Service
    metadata:
      name: service-headliness
      namespace: dev
    spec:
      selector:
        app: nginx-pod
      clusterIP: None # 将clusterIP设置为None,即可创建headliness Service
      type: ClusterIP
      ports:
        - port: 80 # Service的端口
          targetPort: 80 # Pod的端口
    ---
    
    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: pc-statefulset
      namespace: dev
    spec:
      replicas: 3
      serviceName: service-headliness
      selector:
        matchLabels:
          app: nginx-pod
      template:
        metadata:
          labels:
            app: nginx-pod
        spec:
          containers:
            - name: nginx
              image: nginx:1.17.1
              ports:
                - containerPort: 80
    			
      updateStrategy:
        rollingUpdate:
          partition: 0
        type: RollingUpdate  			
    
  • 相关阅读:
    Java IO 流 一些散乱的笔记
    Java IO 流
    Java 枚举
    Java 内部类种类及使用解析
    Java 事件适配器 Adapter
    Java 异常基础 Exception
    Java中内置的观察者模式
    Java 代理模式(一) 静态代理
    Java 可变参数
    Java中的反射机制(二) 一个利用反射进行对象拷贝的例子
  • 原文地址:https://www.cnblogs.com/huiyichanmian/p/15120053.html
Copyright © 2020-2023  润新知