• Kubernetes控制器之Deployment


      官方参考:https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/

           https://www.kubernetes.org.cn/deployment

      Deployments

      Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括:

    • 定义Deployment来创建Pod和ReplicaSet
    • 滚动升级和回滚应用
    • 扩容和缩容
    • 暂停和继续Deployment

      你只需要在Deployment中描述你想要的目标状态是什么,Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment,也可以创建一个新的替换旧的Deployment。

      一个典型的用例如下

    • 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态,看它是成功还是失败。
    • 然后,通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet,Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
    • 如果当前状态不稳定,回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
    • 扩容Deployment以满足更高的负载。
    • 暂停Deployment来应用PodTemplateSpec的多个修复,然后恢复上线。
    • 根据Deployment 的状态判断上线是否hang住了。
    • 清除旧的不必要的ReplicaSet。

      创建Deployment

      下面是 Deployment 示例。创建一个 ReplicaSet 展开三个 nginx Pods:

      该示例为官方示例下载地址是

    https://raw.githubusercontent.com/kubernetes/website/master/content/zh/examples/controllers/nginx-deployment.yaml
    

       

    # cat nginx-deployment.yaml 
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: nginx
      name: nginx-deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx:1.15.4
            name: nginx
            ports:
            - containerPort: 80
    

       也可以通过以下命令生成该yaml文档然后修改

    # kubectl create deployment nginx-deployment --image=nginx:1.15.4 --dry-run -o yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deployment
      name: nginx-deployment
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx-deployment
      strategy: {}
      template:
        metadata:
          creationTimestamp: null
          labels:
            app: nginx-deployment
        spec:
          containers:
          - image: nginx:1.15.4
            name: nginx
            resources: {}
    status: {}
    

       在该例中

    • 创建名为nginx-deployment的Deployment,由metadata.name字段指示
    • Deployment创建3个复制的Pods,由spec.replicas字段指示,该字段可以没有默认即为1
    • selector字段定义Deployment如何查找要管理的Pods。在这种情况下只需要在Pod模板(app:nginx)中定义的标签。
    注意:`matchLabels` 字段是 {key,value} 的映射。单个 {key,value}在 `matchLabels` 映射中的值等效于 `matchExpressions` 的元素,其键字段是“key”,运算符为“In”,值数组仅包含“value”。所有要求,从 `matchLabels` 和 `matchExpressions`,必须满足才能匹配。
    
    •  template字段包含以下子字段
    • Pod使用labels字段标记为app:nginx
    • template.spec字段指示Pod运行一个容器nginx
    • 创建一个容器并使用name字段将其命名为nginx

      通过运行以下命令创建Deployment

    kubectl apply -f nginx-deployment.yaml
    
    注意:将kubectl的 —record 的flag设置为 true可以在annotation中记录当前命令创建或者升级了该资源。这在未来会很有用,例如,查看在每个Deployment revision中执行了哪些命令。
    

       --record示例如下

       运行kubectl get deployments 以检查 Deployment 是否已创建。输出以下内容:

    # kubectl get deployment
    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment         3/3     3            3           48s
    

       显示以下字段

    `READY` 3/3左边3是真正运行的副本数右边3是期望的副本数即replicas定义的副本数。
    `UP-TO-DATE`显示已更新以实现期望状态的副本数。
    `AVAILABLE`显示应用程序可供用户使用的副本数。
    `AGE` 显示应用程序运行的时间量。
    

       要查看Deployment创建的ReplicaSet(rs),运行kubectl get rs输出

    # kubectl get rs
    NAME                                DESIRED   CURRENT   READY   AGE
    nginx-deployment-67656986d9         3         3         3       108s
    

       

    请注意, ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子
    

       要查看每个Pod自动生成的标签,运行kubectl get pods --show-labels输出

    # kubectl get pods --show-labels
    NAME                                      READY   STATUS    RESTARTS   AGE     LABELS
    nginx-deployment-67656986d9-996kk         1/1     Running   0          3m35s   app=nginx,pod-template-hash=67656986d9
    nginx-deployment-67656986d9-fgdwz         1/1     Running   0          3m35s   app=nginx,pod-template-hash=67656986d9
    nginx-deployment-67656986d9-j8jt8         1/1     Running   0          3m35s   app=nginx,pod-template-hash=67656986d9
    

       刚创建的Replica Set将保证总是有3个nginx的pod存在。并且创建的Pod名为[DEPLOYMENT-NAME]-[pod-template-hash]-[RANDOM-STRING]

    注意: 你必须在Deployment中的selector指定正确pod template label(在该示例中是 app = nginx),不要跟其他的controller搞混了(包括Deployment、Replica Set、Replication Controller等)。Kubernetes本身不会阻止你这么做,如果你真的这么做了,这些controller之间会相互打架,并可能导致不正确的行为。
    

       Pod-template-hash 标签

    注意:不要更改此标签
    

       Deployment 控制器将 pod-template-hash 标签添加到 Deployment 创建或使用的每个 ReplicaSet 。

      此标签可确保 Deployment 的子 ReplicaSets 不重叠。它通过对 ReplicaSet 的 PodTemplate 进行哈希处理,并使用生成的哈希值添加到 ReplicaSet 选择器、Pod 模板标签,并在 ReplicaSet 可能具有的任何现有 Pod 中。

      更新Deployment

    注意: Deployment的rollout当且仅当Deployment的pod template(例如.spec.template)中的label更新或者镜像更改时被触发。其他更新,例如扩容Deployment不会触发rollout。
    

       安装以下步骤更新Deployment

      首先修改yaml把nginx版本修改成1.7.9

      应用一下各项nginx Pods,使用nginx:1.9.1镜像,而不是nginx:1.7.9

    # kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
    deployment.apps/nginx-deployment image updated
    

       说明:设置更新Deployment名为nginx-deployment镜像的镜像为nginx:1.9.1

      也可以使用edit命令来编辑Deployment,修改 .spec.template.spec.containers[0].image ,将nginx:1.7.9 改写成nginx:1.9.1

    kubectl edit deployment/nginx-deployment
    

     

       修改完输出

    deployment.apps/nginx-deployment edited
    

       查看rollout的状态,只要执行:

    # kubectl rollout status deployment/nginx-deployment
    deployment "nginx-deployment" successfully rolled out
    

       rollout成功后查看deployment

    # kubectl get deployment
    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment         3/3     3            3           9m37s
    

       UP-TO-DATE的replica的数目已经达到了配置中要求的数目。

      CURRENT的replica数表示Deployment管理的replica数量,AVAILABLE的replica数是当前可用的replica数量。

      我们通过执行kubectl get rs可以看到Deployment更新了Pod,通过创建一个新的Replica Set并扩容了3个replica,同时将原来的Replica Set缩容到了0个replica。

    # kubectl get rs
    NAME                                DESIRED   CURRENT   READY   AGE
    nginx-deployment-54f57cf6bf         0         0         0       12m
    nginx-deployment-56f8998dbc         3         3         3       9m6s
    

       执行 get pods只会看到当前的新的pod:

    # kubectl get pod
    NAME                                      READY   STATUS    RESTARTS   AGE
    nginx-deployment-56f8998dbc-8j49x         1/1     Running   0          5m25s
    nginx-deployment-56f8998dbc-fpzwt         1/1     Running   0          5m26s
    nginx-deployment-56f8998dbc-r2wvp         1/1     Running   0          5m28s
    

       下次更新这些Pod的时候,只需要更新Deployment中pod的template即可

      Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下,它确保至少 75%所需 Pods 运行(25%最大不可用)。

      Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下,它可确保最多增加 25% 期望 Pods 数(25%最大增量)。

      例如,如果仔细查看上述 Deployment ,将看到它首先创建了一个新的 Pod,然后删除了一些旧的 Pods,并创建了新的 Pods。它不会杀死老 Pods,直到有足够的数量新的 Pods 已经出现,并没有创造新的 Pods,直到足够数量的旧 Pods 被杀死。它确保至少 2 个 Pods 可用,并且总共最多 4 个 Pods 可用。

      获取Deployment更多信息

    # kubectl describe deployments nginx-deployment
    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Fri, 20 Mar 2020 16:01:54 +0800
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision: 2
                            kubectl.kubernetes.io/last-applied-configuration:
                              {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"d...
    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
    Pod Template:
      Labels:  app=nginx
      Containers:
       nginx:
        Image:        nginx:1.9.1
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   nginx-deployment-56f8998dbc (3/3 replicas created)
    Events:
      Type    Reason             Age   From                   Message
      ----    ------             ----  ----                   -------
      Normal  ScalingReplicaSet  53s   deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 3
      Normal  ScalingReplicaSet  8s    deployment-controller  Scaled up replica set nginx-deployment-56f8998dbc to 1
      Normal  ScalingReplicaSet  6s    deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 2
      Normal  ScalingReplicaSet  6s    deployment-controller  Scaled up replica set nginx-deployment-56f8998dbc to 2
      Normal  ScalingReplicaSet  5s    deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 1
      Normal  ScalingReplicaSet  5s    deployment-controller  Scaled up replica set nginx-deployment-56f8998dbc to 3
      Normal  ScalingReplicaSet  3s    deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 0
    

       可以看到,当第一次创建 Deployment 时,它创建了一个 ReplicaSet (nginx-deployment-54f57cf6bf)并将其直接扩展至 3 个副本。更新 Deployment 时,它创建了一个新的 ReplicaSet (nginx-deployment-56f8998dbc),并将其扩展为 1,然后将旧 ReplicaSet 缩小到 2,以便至少有 2 个 Pod 可用,并且最多创建 4 个 Pod。然后,它继续向上和向下扩展新的和旧的 ReplicaSet ,具有相同的滚动更新策略。最后,将有 3 个可用的副本在新的 ReplicaSet 中,旧 ReplicaSet 将缩小到 0。

      Rollover(多个rollout并行)  

      每当Deployment controller观测到有新的Deployment被创建时,如果没有已存在的ReplicaSet来创建期望个数的Pod的话,就会创建一个新的ReplicaSet来做这件事。如果更新了Deployment,则控制其标签的Pods的现有ReplicaSet匹配.spec.selector但是template跟.spec.tmplate不匹配的Pod缩容。最终,新的ReplicaSet将会扩容出.spec.replicas指定数目的Pod,旧的Replica Set会缩容到0。

      如果你更新了一个的已存在并正在进行中的Deployment,每次更新Deployment都会创建一个新的Replica Set并扩容它,同时回滚之前扩容的Replica Set——将它添加到旧的Replica Set列表,开始缩容。

      例如,假设创建一个 Deployment 以创建 nginx:1.7.9 的 5 个副本,然后更新 Deployment 以创建 5 个 nginx:1.9.1 的副本,而此时只有 3 个nginx:1.7.9 的副本已创建。在这种情况下, Deployment 会立即开始杀死3个 nginx:1.7.9 Pods,并开始创建 nginx:1.9.1 Pods。它不等待 nginx:1.7.9 的 5 个副本创建完毕再更新新的副本。

      使用标签选择器进行更新

      通常不鼓励更新标签选择器,建议提前规划选择器。在任何情况下,如果需要执行标签选择器更新,请格外小心,并确保已掌握所有的含义。

    注意:
    在 API 版本 apps/v1 中, Deployment 标签选择器在创建后是不可变的。
    
    • 选择器添加还需要使用新标签更新 Deployment 规范中的 Pod 模板标签,否则将返回验证错误。此更改是非重叠的,这意味着新的选择器不选择使用旧选择器创建的 ReplicaSets 和 Pod,从而导致弃用所有旧 ReplicaSets 和创建新的 ReplicaSet 。
    • 选择器更新更改选择器键中的现有值 – 导致发生与添加相同的行为。
    • 选择器删除从 Deployment 选择器中删除现有密钥 – 不需要在Pod 模板标签做任意更改。现有 ReplicaSets 不会孤立,并且不会创建新的 ReplicaSet ,但请注意,已删除的标签仍然存在于任何现有的 Pods 和 ReplicaSets 中。

      回滚Deployment

      有时,可能需要回滚 Deployment ;例如,当 Deployment 不稳定时,例如循环崩溃。

      默认情况下,kubernetes会在系统中保存前两次的Deployment的rollout历史记录,以便你可以随时会退(你可以修改revision history limit来更改保存的revision数)

    注意: 只要Deployment的rollout被触发就会创建一个revision。也就是说当且仅当Deployment的Pod template(如.spec.template)被更改,例如更新template中的label和容器镜像时,就会创建出一个新的revision。
    

       其他的更新,比如扩容Deployment不会创建revision——因此我们可以很方便的手动或者自动扩容。

      例如修改副本数由3修改成5再查看revision是没有新的revision的

    # kubectl rollout history deployment/nginx-deployment --record
    deployment.apps/nginx-deployment 
    REVISION  CHANGE-CAUSE
    1         <none>
    

       假设我们在更新Deployment的时候犯了一个拼写错误,将镜像的名字写成了nginx:1.91,而正确的名字应该是nginx:1.9.1

    # kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record
    deployment.apps/nginx-deployment image updated
    

       Rollout将会卡住

    # kubectl rollout status deployment nginx-deployment 
    Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
    

       按住Ctrl-C停止上面的rollout状态监控。

      查看ReplicaSet

    # kubectl get rs
    NAME                                DESIRED   CURRENT   READY   AGE
    nginx-deployment-54f57cf6bf         3         3         3       5m20s
    nginx-deployment-84fdd4f88c         1         1         0       2m
    

       查看创建的 Pod,看到由新 ReplicaSet 创建的 1 个 Pod 卡在镜像拉取循环中。

    # kubectl get pod
    NAME                                      READY   STATUS             RESTARTS   AGE
    nginx-deployment-54f57cf6bf-67bhs         1/1     Running            0          6m1s
    nginx-deployment-54f57cf6bf-dgrw7         1/1     Running            0          6m43s
    nginx-deployment-54f57cf6bf-n5mjc         1/1     Running            0          6m43s
    nginx-deployment-84fdd4f88c-cmzw6         0/1     ImagePullBackOff   0          3m23s
    

       注意,Deployment controller会自动停止坏的rollout,并停止扩容新的Replica Set。

      获取deploym描述信息

    # kubectl describe deployment nginx-deployment
    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Fri, 20 Mar 2020 16:51:44 +0800
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision: 2
                            kubectl.kubernetes.io/last-applied-configuration:
                              {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"d...
    Selector:               app=nginx
    Replicas:               3 desired | 1 updated | 4 total | 3 available | 1 unavailable
    StrategyType:           RollingUpdate
    MinReadySeconds:        0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
      Labels:  app=nginx
      Containers:
       nginx:
        Image:        nginx:1.91
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    ReplicaSetUpdated
    OldReplicaSets:  nginx-deployment-54f57cf6bf (3/3 replicas created)
    NewReplicaSet:   nginx-deployment-84fdd4f88c (1/1 replicas created)
    Events:
      Type    Reason             Age    From                   Message
      ----    ------             ----   ----                   -------
      Normal  ScalingReplicaSet  9m34s  deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 3
      Normal  ScalingReplicaSet  8m52s  deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 5
      Normal  ScalingReplicaSet  6m45s  deployment-controller  Scaled down replica set nginx-deployment-54f57cf6bf to 3
      Normal  ScalingReplicaSet  6m14s  deployment-controller  Scaled up replica set nginx-deployment-84fdd4f88c to 1
    

       为了修复这个问题,我们需要回退到稳定的Deployment revision。

      检查升级历史记录

    注意:检查历史记录需要在创建的Deployment的时候加了参数--record否则历史记录只记录version号,记录历史命令为none
    

       

    # kubectl rollout history deployment/nginx-deployment
    deployment.apps/nginx-deployment 
    REVISION  CHANGE-CAUSE
    1         kubectl apply --filename=nginx-deployment.yaml --record=true
    2         kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true
    

       查看修改历史的详细信息,查看version为2的详细信息

    # kubectl rollout history deployment/nginx-deployment --revision=2
    deployment.apps/nginx-deployment with revision #2
    Pod Template:
      Labels:	app=nginx
    	pod-template-hash=84fdd4f88c
      Annotations:	kubernetes.io/change-cause: kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true
      Containers:
       nginx:
        Image:	nginx:1.91
        Port:	80/TCP
        Host Port:	0/TCP
        Environment:	<none>
        Mounts:	<none>
      Volumes:	<none>
    

       回滚到上一次的修改

    # kubectl rollout undo deployment/nginx-deployment
    deployment.apps/nginx-deployment rolled back
    

       或者,可以通过使用 `--to-revision` 来回滚到特定修改版本:

    # kubectl rollout undo deployment/nginx-deployment  --to-revision=2
    deployment.apps/nginx-deployment rolled back
    

       检查回滚是否成功Deployment是否正常运行

    # kubectl get deployment nginx-deployment
    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           8m19s
    

       获取Deployment描述信息

    # kubectl describe deployment nginx-deployment
    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Fri, 20 Mar 2020 17:07:51 +0800
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision: 5
                            kubectl.kubernetes.io/last-applied-configuration:
                              {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=nginx-deploy...
                            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
    Pod Template:
      Labels:  app=nginx
      Containers:
       nginx:
        Image:        nginx:1.7.9
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   nginx-deployment-54f57cf6bf (3/3 replicas created)
    Events:
      Type    Reason             Age                    From                   Message
      ----    ------             ----                   ----                   -------
      Normal  ScalingReplicaSet  9m25s                  deployment-controller  Scaled up replica set nginx-deployment-54f57cf6bf to 3
      Normal  ScalingReplicaSet  3m49s (x2 over 9m17s)  deployment-controller  Scaled up replica set nginx-deployment-84fdd4f88c to 1
      Normal  ScalingReplicaSet  2m35s (x2 over 5m54s)  deployment-controller  Scaled down replica set nginx-deployment-84fdd4f88c to 0
    

       你可以通过设置.spec.revisonHistoryLimit项来指定deployment最多保留多少revison历史记录。默认的保留2次revision;如果将该项设置为0,Deployment就不允许回退了。

      缩放Deployment

      可以使用如下指令缩放 Deployment

    # kubectl scale deployment/nginx-deployment --replicas=10
    deployment.apps/nginx-deployment scaled
    

       假设你的集群中启用了horizontal pod autoscaling,你可以给Deployment设置一个autoscaler,基于当前Pod的CPU利用率选择最少和最多的Pod数。

    kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
    

       比例缩放

      RollingUpdate Deployment支持同时运行一个应用的多个版本。当你活着autoscaler扩容RollingUpdate Deployment的时候,正在中途的rollout(进行中或者已经暂停的),为了降低风险,Deployment controller将会平衡已存在的活动中的ReplicaSets(有Pod的ReplicaSets)和新加入的replicas。这被称为比例扩容。

      例如,你真在运行的10个ReplicaSet的Deployment 。maxSurge=3,maxUnavailable=2即最多增加为3 最大不可用为2

      maxSurge和maxUnavailable默认百分百为25% 可以编辑修改如此例副本数为10则maxSurge修改为30% maxUnavailable修改为20%

       查看Deployment包含10个ReplicaSet修改参数以后maxSurge=3,maxUnavailable=2。

    # kubectl get deploy
    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment         10/10   10           10          17m
    

       更新了一个镜像,而在集群内部无法解析

    # kubectl set image deploy/nginx-deployment nginx=ngina:sametag
    deployment.apps/nginx-deployment image updated
    

       镜像更新启动了一个包含ReplicaSet 名称为nginx-deployment-55866c9bf7的rollout,但是它被阻塞了,因为前面提到的maxUnavailable最大不可用为2最大增加maxSurge为3所以新的ReplicaSet有5个Pod阻塞了

    # kubectl get rs
    NAME                                DESIRED   CURRENT   READY   AGE
    nginx-deployment-54f57cf6bf         8         8         8       18m
    nginx-deployment-55866c9bf7         5         5         0       14m
    

       查看Pod

       然后发起了一个新的Deployment扩容请求。autoscaler将Deployment的repllica数目增加到了15个。Deployment controller需要判断在哪里增加这5个新的replica。如果我们没有用比例扩容,所有的5个replica都会加到一个新的ReplicaSet中。如果使用比例扩容,新添加的replica将传播到所有的ReplicaSet中。大的部分加入replica数最多的ReplicaSet中,小的部分加入到replica数少的ReplciaSet中。0个replica的ReplicaSet不会被扩容。

    # kubectl scale --replicas=15 deploy/nginx-deployment
    deployment.apps/nginx-deployment scaled
    

       在该例中有4个replica加入到旧ReplicaSet中新的ReplicaSet有3个

    # kubectl get deploy
    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment         12/15   8            12          29m
    [root@localhost deployment]# kubectl get rs
    NAME                                DESIRED   CURRENT   READY   AGE
    nginx-deployment-54f57cf6bf         12        12        12      29m
    nginx-deployment-55866c9bf7         8         8         0       25m
    

       通过Pod的运行时间可以区分加入新旧ReplicaSet的副本数

       暂停和恢复Deployment

      可以在触发一个或多个更新之前暂停 Deployment ,然后继续它。这允许在暂停和恢复之间应用多个修补程序,而不会触发不必要的rollout。

      例如对于一个刚刚创建的Deployment获取Deployment信息

    # kubectl get deploy
    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment         3/3     3            3           3s
    

       获取rs

    # kubectl get rs
    NAME                                DESIRED   CURRENT   READY   AGE
    nginx-deployment-54f57cf6bf         3         3         3       35s
    

       使用以下命令暂停Deployment

    # kubectl rollout pause deploy/nginx-deployment
    deployment.apps/nginx-deployment paused
    

       更新镜像

    # kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
    deployment.apps/nginx-deployment image updated
    

       查看rollout没有记录

    # kubectl rollout history deploy/nginx-deployment
    deployment.apps/nginx-deployment 
    REVISION  CHANGE-CAUSE
    1         <none>
    

       恢复Deployment

    # kubectl rollout resume deploy/nginx-deployment
    deployment.apps/nginx-deployment resumed
    
    注意:
    暂停的 Deployment 不可以回滚,除非恢复它以后。
    暂停的Deployment管理的Pod功能正常运行

       Deployment状态

      Deployment在生命周期中有多种状态。在创建一个新的ReplicaSet的时候它可以是 progressing 状态, complete 状态,或者fail to progress状态。

      Progressing Deployment

      Kubernetes将执行过下列任务之一的Deployment标记为progressing状态:

    • Deployment正在创建新的ReplicaSet过程中。
    • Deployment正在扩容一个已有的ReplicaSet。
    • Deployment正在缩容一个已有的ReplicaSet。
    • 有新的可用的pod出现。

      你可以使用kubectl roullout status命令监控Deployment的进度。

      Complete Deployment

      Kubernetes将包括以下特性的Deployment标记为complete状态:

    • Deployment最小可用。最小可用意味着Deployment的可用replica个数等于或者超过Deployment策略中的期望个数。
    • 所有与该Deployment相关的replica都被更新到了你指定版本,也就说更新完成。
    • 该Deployment中没有旧的Pod存在。

      你可以用kubectl rollout status命令查看Deployment是否完成。如果rollout成功完成,kubectl rollout status将返回一个0值的Exit Code。

    # kubectl rollout status deploy/nginx-deployment
    deployment "nginx-deployment" successfully rolled out
    [root@localhost deployment]# echo $?
    0
    

       Failed Deployment

    • 无效的引用
    • 不可读的probe failure
    • 镜像拉取错误
    • 权限不够
    • 范围限制
    • 程序运行时配置错误

      探测这种情况的一种方式是,在你的Deployment spec中指定spec.progressDeadlineSecondsspec.progressDeadlineSeconds表示Deployment controller等待多少秒才能确定(通过Deployment status)Deployment进程是卡住的。

      下面的kubectl命令设置progressDeadlineSeconds 使controller在Deployment在进度卡住10分钟后报告:

    # kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
    

       PS:默认的参数值就是600秒,可以使用以下命令查看

    kubectl edit deploy/nginx-deployment
    

       超过截止时间后, Deployment 控制器将添加具有以下属性到 Deployment 的 .status.conditions :

    • Type=Progressing
    • Status=False
    • Reason=ProgressDeadlineExceeded
      注意: kubernetes除了报告Reason=ProgressDeadlineExceeded状态信息外不会对卡住的Deployment做任何操作。更高层次的协调器可以利用它并采取相应行动,例如,回滚Deployment到之前的版本。
      
      注意: 如果你暂停了一个Deployment,在暂停的这段时间内kubernetnes不会检查你指定的deadline。你可以在Deployment的rollout途中安全的暂停它,然后再恢复它,这不会触发超过deadline的状态。
      

      清理策略

      可以在 Deployment 中设置 .spec.revisionHistoryLimit ,以指定保留多少此 Deployment 的 ReplicaSets。其余的将在后台进行垃圾回收。默认情况下,是10。

    注意: 将该值设置为0,将导致所有的Deployment历史记录都会被清除,该Deploynent就无法再回退了。
    

       编写Deployment脚本

      在所有的Kubernetes配置中,Deployment也需要apiVersionkindmetadata这些配置项。

      Pod Template

      .spec仅需要.spec.template和.spec.selector.

      .spec.template是 pod template. 它跟 Pod有一模一样的schema,除了它是嵌套的并且不需要apiVersion 和 kind字段。

      另外为了划分Pod的范围,Deployment中的pod template必须指定适当的label(不要跟其他controller重复了)和适当的重启策略。

      .spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。

      Replicas

      .spec.replicas是可选字段,指定期望的副本即Pod数量,默认是1。

      Selector

      .spec.selector是可选字段,用来指定 label selector ,圈定Deployment管理的pod范围。

      如果被指定, .spec.selector 必须匹配 .spec.template.metadata.labels,否则它将被API拒绝。

      在 API apps/v1版本中,.spec.selector 和 .metadata.labels 不会被默认设置为 .spec.template.metadata.labels,如果没有设置的话。所以需要明确进行设置。同时在 apps/v1版本中, Deployment 创建后 .spec.selector 是可变的

      如下所示需要匹配

       在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下,Deployment会杀掉label跟selector不同的Pod。

    注意:
    不应创建其标签与此选择器匹配的 Pods,或者直接创建另一个 Deployment ,或通过创建其他控制器(如 ReplicaSet 或复制控制器)。如果这样做,第一个 Deployment 认为它创建了这些其他 Pods。Kubernetes 不会阻止你这么做。
    

       如果有多个具有重叠选择器的控制器,则控制器之间会因冲突而故障。

      策略

      .spec.strategy 指定新的Pod替换旧的Pod的策略。 .spec.strategy.type 可以是”Recreate”或者是 “RollingUpdate”。”RollingUpdate”是默认值。

      Recreate Deployment

      .spec.strategy.type==Recreate时,在创建出新的Pod之前会先杀掉所有已存在的Pod。

      Rolling Update Deployment

      .spec.strategy.type==RollingUpdate时,Deployment使用rolling update 的方式更新Pod 。你可以指定maxUnavailable 和maxSurge 来控制 rolling update 进程。

      Max Unavailable

      .spec.strategy.rollingUpdate.maxUnavailable 是可选配置项,用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值(例如5),也可以是期望Pod数量的百分比(例如10%)。通过计算百分比的绝对值向下取整。如果.spec.strategy.rollingUpdate.maxSurge 为0时,这个值不可以为0。默认值是1。

      例如,该值设置成30%,启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的70%。新的Pod ready后,随着新的ReplicaSet的扩容,旧的ReplicaSet会进一步缩容,确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。

      Max Surge

      .spec.strategy.rollingUpdate.maxSurge 是可选配置项,用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值(例如5)或者是期望的Pod数量的百分比(例如10%)。当MaxUnavailable为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。

    例如,该值设置成30%,启动rolling update后新的ReplicatSet将会立即扩容,新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后,新的ReplicaSet将继续扩容,旧的ReplicaSet会进一步缩容,确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。

      Progress Deadline Seconds

      .spec.progressDeadlineSeconds 是可选配置项,用来指定在系统报告Deployment的failed progressing ——表现为resource的状态中type=ProgressingStatus=False、 Reason=ProgressDeadlineExceeded前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来,在实现了自动回滚后, deployment controller在观察到这种状态时就会自动回滚。

    如果设置该参数,该值必须大于 .spec.minReadySeconds

      Min Ready Seconds

      .spec.minReadySeconds是一个可选配置项,用来指定没有任何容器crash的Pod并被认为是可用状态的最小秒数。默认是0(Pod在ready后就会被认为是可用状态)。进一步了解什么什么后Pod会被认为是ready状态。

      Rollback To

      .spec.rollbackTo 是一个可以选配置项,用来配置Deployment回退的配置。设置该参数将触发回退操作,每次回退完成后,该值就会被清除。
      Revision

      .spec.rollbackTo.revision是一个可选配置项,用来指定回退到的revision。默认是0,意味着回退到历史中最老的revision。

      Revision History Limit

      Deployment revision history存储在它控制的ReplicaSets中。

      .spec.revisionHistoryLimit 是一个可选配置项,用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话,默认所有旧的Replicaset或会被保留,将资源存储在etcd中,是用kubectl get rs查看输出。每个Deployment的该配置都保存在ReplicaSet中,然而,一旦你删除的旧的RepelicaSet,你的Deployment就无法再回退到那个revison了。

    如果你将该值设置为0,所有具有0个replica的ReplicaSet都会被删除。在这种情况下,新的Deployment rollout无法撤销,因为revision history都被清理掉了。

      Paused

      .spec.paused是可以可选配置项,boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是,所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。

      Deployment的替代方案

      Kubectl rolling update 虽然使用类似的方式更新Pod和ReplicationController。但是我们推荐使用Deployment,因为它是声明式的,客户端侧,具有附加特性,例如即使滚动升级结束后也可以回滚到任何历史版本。

      

        

  • 相关阅读:
    Windows 2003/2008更改远程桌面端口脚本
    如何修改远程桌面连接3389端口
    关于百度地图(离线)使用过程报“Cannot read property 'jb' of undefined ”错误的解决办法
    IIS 错误:处理程序“PageHandlerFactory-Integrated”在其模块列表中有一个错误模块“ManagedPipelineHandler”
    IIS 错误:由于扩展配置问题而无法提供您请求的页面。如果该页面是脚本,请添加处理程序。如果应下载文件,请添加 MIME 映射。
    IIS7错误:不能在此路径中使用此配置节。如果在父级别上锁定了该节,便会出现这种情况。锁定是默认设置的(overrideModeDefault="Deny")......
    Jqgrid pager 关于“local” dataType 动态加载数据分页的研究(没好用的研究结果)
    JQGrid导出Excel文件
    Oracle以15分钟为界,统计一天内各时间段的数据笔数
    ORA-01438: 值大于为此列指定的允许精度
  • 原文地址:https://www.cnblogs.com/minseo/p/12532336.html
Copyright © 2020-2023  润新知