概念

Kubernetes v1.16 文档不再得到积极维护。您当前正在查看的版本是静态快照。有关最新文档,请参见 最新版本。

编辑这个页面

部署方式s

A 部署方式 提供声明性更新 豆荚副本集.

你描述一个 理想状态 in a 部署方式, 和 the 部署方式 控制者一个控制环,它通过apiserver监视群集的共享状态,并进行更改以尝试将当前状态移向所需状态。 以受控速率将实际状态更改为所需状态。您可以定义部署以创建新的副本集,或删除现有的部署并在新的部署中采用其所有资源。

注意: 不要管理部署拥有的副本集。如果您的用例未在下面介绍,请考虑在Kubernetes主存储库中打开问题。

用例

The following are typical use cases for 部署方式s:

Creating a 部署方式

The following is an example of a 部署方式. It creates a 复制集 to bring up three nginx 豆荚:

controllers/nginx-deployment.yaml
apiVersion: apps/v1
kind: 部署方式
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  复制品: 3
  选择器:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

在此示例中:

  • 部署 named nginx-deployment is created, indicated by the .metadata.name field.
  • The 部署方式 creates three replicated 豆荚, indicated by the 复制品 field.
  • The 选择器 field defines how the 部署方式 finds which 豆荚 to manage. In this case, you simply select a label that is defined in the 吊舱模板 (app: nginx)。 但是,可能会有更复杂的选择规则, 只要Pod模板本身满足规则。

    注意: The matchLabels field is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose 键 field is “key” the operator is “In”, 并且values数组仅包含“value”. All of the requirements, from both matchLabelsmatchExpressions, must be satisfied in 要么der to match.

  • The template field contains the following sub-fields:

    • The 豆荚 are labeled app: nginxusing the labels field.
    • 荚模板’s specification, 要么 .template.spec field, indicates that the 豆荚 run one container, nginx, which runs the nginx Docker中心 图像版本为1.7.9。
    • Create one container 和 name it nginx using the name field.

Follow the steps given below to create the above 部署方式:

在开始之前,请确保您的Kubernetes集群已启动并正在运行。

  1. Create the 部署方式 by running the following command:

    注意: You may specify the –record flag to write the command executed in the resource annotation kubernetes.io/change-cause. It is useful for future introspection. 例如,查看在每个Deployment版本中执行的命令。

    kubectl apply -f //k8s.io/examples/controllers/nginx-deployment.yaml
  2. Run kubectl get deployments to check if the 部署方式 was created. If the 部署方式 is still being created, the output is similar to the following:

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   0/3     0            0           1s

    当您检查群集中的部署时,将显示以下字段:

    • NAME lists the names of the 部署方式s in the cluster.
    • DESIRED 显示所需的数量 复制品 在创建展开时定义的应用程序的名称。这是 理想状态.
    • CURRENT 显示当前正在运行多少个副本。
    • UP-TO-DATE 显示已更新以达到所需状态的副本数。
    • AVAILABLE 显示您的用户可以使用多少个应用程序副本。
    • AGE 显示应用程序已运行的时间。

    没有 tice how the number of desired 复制品 is 3 according to .spec.replicas field.

  3. To see the 部署方式 rollout status, run kubectl rollout status deployment.v1.apps/nginx-deployment. 输出类似于以下内容:

    Waiting for rollout to finish: 2 out of 3 new 复制品 have been updated...
    deployment.apps/nginx-deployment successfully rolled out
  4. Run the kubectl get deployments again a few seconds later. 输出类似于以下内容:

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           18s

    请注意,Deployment已创建了所有三个副本,并且所有副本都是最新的(它们包含最新的Pod模板)并且可用。

  5. To see the 复制集 (rs) created by the 部署方式, run kubectl get rs. 输出类似于以下内容:

    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-75675f5897   3         3         3       18s

    没有 tice that the name of the 复制集 is always formatted as [DEPLOYMENT-NAME]-[RANDOM-STRING]. The random string is 随机生成,并使用pod-template-hash作为种子。

  6. To see the labels automatically generated for each 荚, run kubectl get pods --show-labels. The following output is returned:

    NAME                                READY     STATUS    RESTARTS   AGE       LABELS
    nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
    nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
    nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453

    The created 复制集 ensures that there are three nginx 豆荚.

注意: 您必须在Deployment中指定适当的选择器和Pod模板标签(在这种情况下, app: nginx)。不要将标签或选择器与其他控制器(包括其他Deployment和StatefulSet)重叠。 Kubernetes不’t阻止您重叠,并且如果多个控制器具有重叠的选择器,则这些控制器可能会发生冲突并出现异常情况。

荚模板哈希标签

注意: 请勿更改此标签。

The pod-template-hash label is added by the 部署方式 controller to every 复制集 that a 部署方式 creates 要么 adopts.

This label ensures that child 副本集 of a 部署方式 do not overlap. It is generated by hashing the 荚Template of the 复制集 和 using the resulting hash as the label 值 that is added to the 复制集 选择器, 吊舱模板 labels, 以及ReplicaSet可能具有的任何现有Pod中。

Updating a 部署方式

注意: 部署’仅当Deployment触发s推出’s 吊舱模板 (that is, .spec.template) 更改,例如,如果模板的标签或容器图像已更新。其他更新(例如扩展Deployment)不会触发部署。

Follow the steps given below to update your 部署方式:

  1. 让 ’s update the nginx 豆荚 to use the nginx:1.9.1 image instead of the nginx:1.7.9 image.

    kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

    或简单地使用以下命令:

    kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 --record

    输出类似于以下内容:

    deployment.apps/nginx-deployment image updated
    

    Alternatively, you can edit the 部署方式 和 change .spec.template.spec.containers[0].image from nginx:1.7.9 to nginx:1.9.1:

    kubectl edit deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    deployment.apps/nginx-deployment edited
    
  2. 要查看部署状态,请运行:

    kubectl rollout status deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    Waiting for rollout to finish: 2 out of 3 new 复制品 have been updated...
    

    要么

    deployment.apps/nginx-deployment successfully rolled out
    

Get more details on your updated 部署方式:

  • After the rollout succeeds, you can view the 部署方式 by running kubectl get deployments. 输出类似于以下内容:

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           36s
    
  • Run kubectl get rs to see that the 部署方式 updated the 豆荚 by creating a new 复制集 和 scaling it 最多3个副本,以及将旧的ReplicaSet缩小为0个副本。

    kubectl get rs

    输出类似于以下内容:

    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-1564180365   3         3         3       6s
    nginx-deployment-2035384211   0         0         0       36s
    
  • Running get pods should now show only the new 豆荚:

    kubectl get pods

    输出类似于以下内容:

    NAME                                READY     STATUS    RESTARTS   AGE
    nginx-deployment-1564180365-khku8   1/1       Running   0          14s
    nginx-deployment-1564180365-nacti   1/1       Running   0          14s
    nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
    

    下次您要更新这些Pod时,只需更新部署’的Pod模板再次出现。

    部署可确保仅在更新某些Pod时将它们关闭。默认, 这样可以确保至少有75%的所需Pod可用(最大不超过25%)。

    部署还可以确保仅在所需数量的Pod之上创建一定数量的Pod。 默认情况下,它可以确保最多容纳期望数量的Pod的125%(最大浪涌为25%)。

    例如,如果您仔细查看上述部署,您将看到它首先创建了一个新的Pod, 然后删除一些旧的Pod,然后创建新的Pod。直到足够数量的 新的Pod出现了,并且直到足够数量的Old 荚被杀死后才创建新的Pod。 确保至少有2个Pod可用,最多总共有4个Pod可用。

  • Get details of your 部署方式:

    kubectl describe deployments

    输出类似于以下内容:

    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Thu, 30 没有 v 2017 10:56:25 +0000
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision=2
    Selector:               app=nginx
    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
    StrategyType:           滚动更新
    MinReadySeconds:        0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
    Labels:  app=nginx
     货柜:
      nginx:
        Image:        nginx:1.9.1
        Port:         80/TCP
        Environment:  <none>
        Mounts:       <none>
      卷数:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   nginx-deployment-1564180365 (3/3 复制品 created)
    Events:
      Type    Reason             Age   From                   Message
      ----    ------             ----  ----                   -------
      没有 rmal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
      没有 rmal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
      没有 rmal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
      没有 rmal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
      没有 rmal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
      没有 rmal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
      没有 rmal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0
    

    在这里您会看到,首次创建展开时,它创建了一个ReplicaSet(nginx-deployment-2035384211) 并将其直接扩展到3个副本。更新部署时,它创建了一个新的副本集。 (nginx-deployment-1564180365)并将其缩放至1,然后将旧的ReplicaSet缩放至2,因此 至少有2个Pod可用,并且在任何时候最多创建4个Pod。然后,它继续向上和向下扩展 新的和旧的ReplicaSet,具有相同的滚动更新策略。最后,你’会有3个可用副本 在新的ReplicaSet中,而旧的ReplicaSet则缩小为0。

过渡(又名进行中的多个更新)

每次部署控制器观察到新的部署时,都会创建一个ReplicaSet来启动 所需的豆荚。如果部署已更新,则控制其标签的Pod的现有ReplicaSet match .spec.selector but whose template does not match .spec.template are scaled down. Eventually, the new ReplicaSet is scaled to .spec.replicas 和 all old 副本集 is scaled to 0.

如果在进行现有部署时更新部署,则部署将创建一个新的副本集。 按照更新并开始扩大规模,然后将其扩展到以前扩大的ReplicaSet –它将添加到其旧的副本集列表中,并开始按比例缩小比例。

For example, suppose you create a 部署方式 to create 5 复制品 of nginx:1.7.9, but then update the 部署方式 to create 5 复制品 of nginx:1.9.1, when only 3 replicas of nginx:1.7.9 had been created. In that case, the 部署方式 immediately starts killing the 3 nginx:1.7.9 豆荚 that it had created, 和 starts creating nginx:1.9.1 豆荚. It does not wait for the 5 复制品 of nginx:1.7.9 to be created 在改变路线之前。

标签选择器更新

通常不建议更新标签选择器,建议您预先计划选择器。 无论如何,如果您需要执行标签选择器更新,请格外小心,并确保已掌握 所有的含义。

注意: In API version apps/v1, a 部署方式’标签选择器创建后是不可变的。
  • 选择器的添加也需要在Deployment规范中的Pod模板标签也使用新标签进行更新, 否则返回验证错误。此更改是非重叠的,这意味着新选择器会执行 不选择使用旧选择器创建的ReplicaSets和Pod,导致孤立所有旧ReplicaSets和 创建一个新的ReplicaSet。
  • 选择器更新会更改选择器键中的现有值–产生与添加相同的行为。
  • 选择器删除从“部署”选择器中删除现有密钥–不需要任何更改 Pod模板标签。现有的副本集不会被孤立,也不会创建新的副本集,但是请注意, 任何现有的Pod和ReplicaSets中仍然存在删除的标签。

Rolling Back a 部署方式

有时,您可能需要回滚部署;例如,当部署不稳定时(例如崩溃循环)。 默认情况下,所有部署’s的推出历史记录保留在系统中,以便您可以随时回滚 (您可以通过修改修订历史记录限制来更改此设置)。

注意: 部署’的修订是在部署时创建的’s的部署被触发。这意味着 当且仅当部署时,才会创建新修订’s 吊舱模板 (.spec.template) is changed, 例如,如果您更新模板的标签或容器图像。其他更新,例如扩展部署, 不要创建Deployment版本,以便您可以同时进行手动或自动扩展。 这意味着,当您回滚到较早的版本时,仅部署’Pod模板的一部分是 rolled back.
  • Suppose that you made a typo 而 updating the 部署方式, by putting the image name as nginx:1.91 instead of nginx:1.9.1:

    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true

    输出类似于以下内容:

    deployment.apps/nginx-deployment image updated
    
  • 推出卡住了。您可以通过检查展示状态来验证它:

    kubectl rollout status deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    Waiting for rollout to finish: 1 out of 3 new 复制品 have been updated...
    
  • 按Ctrl-C停止上述推出状态监视。有关卡住的推广的更多信息, 在这里阅读更多.

  • You see that the number of old 复制品 (nginx-deployment-1564180365nginx-deployment-2035384211) is 2, 和 new 复制品 (nginx-deployment-3066724191) is 1.

    kubectl get rs

    输出类似于以下内容:

    NAME                          DESIRED   CURRENT   READY   AGE
    nginx-deployment-1564180365   3         3         3       25s
    nginx-deployment-2035384211   0         0         0       36s
    nginx-deployment-3066724191   1         1         0       6s
    
  • 查看创建的Pod,您会看到1个由新ReplicaSet创建的Pod卡在了图像提取循环中。

    kubectl get pods

    输出类似于以下内容:

    NAME                                READY     STATUS             RESTARTS   AGE
    nginx-deployment-1564180365-70iae   1/1       Running            0          25s
    nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
    nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
    nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
    
    注意: 部署控制器自动停止错误的推出,并停止扩大新的规模 ReplicaSet. This depends on the rollingUpdate parameters (maxUnavailable specifically) that you have specified. Kubernetes默认将值设置为25%。
  • Get the description of the 部署方式:

    kubectl describe deployment

    输出类似于以下内容:

    Name:           nginx-deployment
    Namespace:      default
    CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
    Labels:         app=nginx
    Selector:       app=nginx
    Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
    StrategyType:       滚动更新
    MinReadySeconds:    0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
      Labels:  app=nginx
      货柜:
       nginx:
        Image:        nginx:1.91
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      卷数:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    复制集Updated
    OldReplicaSets:     nginx-deployment-1564180365 (3/3 复制品 created)
    NewReplicaSet:      nginx-deployment-3066724191 (1/1 复制品 created)
    Events:
      FirstSeen LastSeen    Count   From                    SubObjectPath   Type        Reason              Message
      --------- --------    -----   ----                    -------------   --------    ------              -------
      1m        1m          1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
      22s       22s         1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
      22s       22s         1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
      22s       22s         1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
      21s       21s         1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
      21s       21s         1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
      13s       13s         1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
      13s       13s         1       {deployment-controller }                没有 rmal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
    

要解决此问题,您需要回滚到稳定的Deployment的先前版本。

Checking Rollout History of a 部署方式

请按照以下步骤检查发布历史记录:

  1. First, check the revisions of this 部署方式:

    kubectl rollout history deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    deployments "nginx-deployment"
    REVISION    CHANGE-CAUSE
    1           kubectl apply --filename=//k8s.io/examples/controllers/nginx-deployment.yaml --record=true
    2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
    3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
    

    CHANGE-CAUSE is copied from the 部署方式 annotation kubernetes.io/change-cause to its revisions upon creation. You can specify theCHANGE-CAUSE message by:

    • Annotating the 部署方式 with kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.9.1"
    • Append the --record flag to save the kubectl command that is making changes to the resource.
    • 手动编辑资源清单。
  2. 要查看每个修订的详细信息,请运行:

    kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2

    输出类似于以下内容:

    deployments "nginx-deployment" revision 2
      Labels:       app=nginx
              pod-template-hash=1159050644
      注解:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
      货柜:
       nginx:
        Image:      nginx:1.9.1
        Port:       80/TCP
         QoS Tier:
            cpu:      BestEffort
            memory:   BestEffort
        Environment Variables:      <none>
      没有  volumes.
    

回滚到以前的修订

请按照下面给出的步骤将部署从当前版本回滚到以前的版本2。

  1. 轮到你了’ve决定撤消当前推出并回滚到以前的版本:

    kubectl rollout undo deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    deployment.apps/nginx-deployment
    

    Alternatively, you can rollback to a specific revision by specifying it with --to-revision:

    kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2

    输出类似于以下内容:

    deployment.apps/nginx-deployment
    

    有关与推出相关命令的更多详细信息,请阅读 kubectl rollout.

    The 部署方式 is now rolled back to a previous stable revision. As you can see, a 部署方式Rollback event 从Deployment 控制者生成用于回滚到修订版2的文件。

  2. 检查回滚是否成功并且Deployment是否按预期运行,请运行:

    kubectl get deployment nginx-deployment

    输出类似于以下内容:

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment   3/3     3            3           30m
    
  3. Get the description of the 部署方式:

    kubectl describe deployment nginx-deployment

    输出类似于以下内容:

    Name:                   nginx-deployment
    Namespace:              default
    CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision=4
                            kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true
    Selector:               app=nginx
    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
    StrategyType:           滚动更新
    MinReadySeconds:        0
    RollingUpdateStrategy:  25% max unavailable, 25% max surge
    Pod Template:
      Labels:  app=nginx
      货柜:
       nginx:
        Image:        nginx:1.9.1
        Port:         80/TCP
        Host Port:    0/TCP
        Environment:  <none>
        Mounts:       <none>
      卷数:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   nginx-deployment-c4747d96c (3/3 复制品 created)
    Events:
      Type    Reason              Age   From                   Message
      ----    ------              ----  ----                   -------
      没有 rmal  ScalingReplicaSet   12m   deployment-controller  Scaled up replica set nginx-deployment-75675f5897 to 3
      没有 rmal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 1
      没有 rmal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 2
      没有 rmal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 2
      没有 rmal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 1
      没有 rmal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-c4747d96c to 3
      没有 rmal  ScalingReplicaSet   11m   deployment-controller  Scaled down replica set nginx-deployment-75675f5897 to 0
      没有 rmal  ScalingReplicaSet   11m   deployment-controller  Scaled up replica set nginx-deployment-595696685f to 1
      没有 rmal  部署方式Rollback  15s   deployment-controller  Rolled back deployment "nginx-deployment" to revision 2
      没有 rmal  ScalingReplicaSet   15s   deployment-controller  Scaled down replica set nginx-deployment-595696685f to 0
    

Scaling a 部署方式

You can scale a 部署方式 by using the following command:

kubectl scale deployment.v1.apps/nginx-deployment --replicas=10

输出类似于以下内容:

deployment.apps/nginx-deployment scaled

假设 水平Pod自动缩放 已启用 在您的集群中,您可以为您的部署设置自动缩放器,并选择最小和最大数量 您要基于现有Pod的CPU利用率运行的Pod。

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

输出类似于以下内容:

deployment.apps/nginx-deployment scaled

比例缩放

滚动更新部署支持同时运行一个应用程序的多个版本。当你 或自动缩放器缩放在推出期间(正在进行中)的RollingUpdate部署 或已暂停),Deployment控制器会平衡现有活动数据库中的其他副本 ReplicaSets(带有Pod的ReplicaSets)以减轻风险。这就是所谓的 比例缩放.

For example, you are running a 部署方式 with 10 复制品, maxSurge= 3,并且 maxUnavailable=2.

  • Ensure that the 10 复制品 in your 部署方式 are running.

    kubectl get deploy

    输出类似于以下内容:

    NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    nginx-deployment     10        10        10           10          50s
    
  • 您将更新到一个刚从群集内部无法解析的新映像。

    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag

    输出类似于以下内容:

    deployment.apps/nginx-deployment image updated
    
  • 映像更新使用ReplicaSet nginx-deployment-1989198191开始新的部署,但是它’s blocked due to the maxUnavailable 您上面提到的要求。查看推出状态:

    kubectl get rs

    输出类似于以下内容:

    NAME                          DESIRED   CURRENT   READY     AGE
    nginx-deployment-1989198191   5         5         0         9s
    nginx-deployment-618515232    8         8         8         1m
    
  • 然后出现了一个新的扩展请求。自动缩放器会递增Deployment副本 到15.部署控制器需要决定将这5个新副本添加到何处。如果你曾经’t using 按比例缩放,所有5个都将添加到新的ReplicaSet中。通过比例缩放,您可以 将其他副本分布在所有副本集上。更大的比例转到带有 大多数副本和比例较低的副本将转到副本较少的副本集。任何剩余的都将添加到 具有最多副本的ReplicaSet。副本数为零的副本集不会按比例放大。

在上面的示例中,将3个副本添加到旧的ReplicaSet中,将2个副本添加到旧的ReplicaSet中。 新的ReplicaSet。部署过程最终应将所有副本移至新的ReplicaSet,假设 新副本变得健康。要确认这一点,请运行:

kubectl get deploy

输出类似于以下内容:

NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     15        18        7            8           7m

推出状态确认副本如何添加到每个副本集。

kubectl get rs

输出类似于以下内容:

NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   7         7         0         7m
nginx-deployment-618515232    11        11        11        7m

Pausing 和 Resuming a 部署方式

您可以在触发一个或多个更新之前暂停部署,然后再恢复它。这使您能够 在暂停和恢复之间应用多个修复程序,而不会触发不必要的部署。

  • For example, with a 部署方式 that was just created: Get the 部署方式 details:

    kubectl get deploy

    输出类似于以下内容:

    NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    nginx     3         3         3            3           1m
    

    获取推广状态:

    kubectl get rs

    输出类似于以下内容:

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   3         3         3         1m
    
  • 通过运行以下命令来暂停:

    kubectl rollout pause deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    deployment.apps/nginx-deployment paused
    
  • Then update the image of the 部署方式:

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

    输出类似于以下内容:

    deployment.apps/nginx-deployment image updated
    
  • 请注意,没有新的部署开始:

    kubectl rollout history deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    deployments "nginx"
    REVISION  CHANGE-CAUSE
    1   <none>
    
  • 获取部署状态,以确保部署已成功更新:

    kubectl get rs

    输出类似于以下内容:

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   3         3         3         2m
    
  • 您可以根据需要进行任意数量的更新,例如,更新将使用的资源:

    kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi

    输出类似于以下内容:

    deployment.apps/nginx-deployment resource requirements updated
    

    部署在暂停之前的初始状态将继续其功能,但是对 只要暂停部署,部署将不会有任何效果。

  • 最终,恢复部署并观察新的ReplicaSet以及所有新的更新:

    kubectl rollout resume deployment.v1.apps/nginx-deployment

    输出类似于以下内容:

    deployment.apps/nginx-deployment resumed
    
  • 观察部署的状态,直到完成为止’s done.

    kubectl get rs -w

    输出类似于以下内容:

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   2         2         2         2m
    nginx-3926361531   2         2         0         6s
    nginx-3926361531   2         2         1         18s
    nginx-2142116321   1         2         2         2m
    nginx-2142116321   1         2         2         2m
    nginx-3926361531   3         2         1         18s
    nginx-3926361531   3         2         1         18s
    nginx-2142116321   1         1         1         2m
    nginx-3926361531   3         3         1         18s
    nginx-3926361531   3         3         2         19s
    nginx-2142116321   0         1         1         2m
    nginx-2142116321   0         1         1         2m
    nginx-2142116321   0         0         0         2m
    nginx-3926361531   3         3         3         20s
    
  • 获取最新发布的状态:

    kubectl get rs

    输出类似于以下内容:

    NAME               DESIRED   CURRENT   READY     AGE
    nginx-2142116321   0         0         0         2m
    nginx-3926361531   3         3         3         28s
    
    注意: You cannot rollback a paused 部署方式 until you resume it.

部署方式 status

部署 enters various states during its lifecycle. It 可进步的 而 rolling out a new 复制集, it 可完成,或者可以 未能进步.

Progressing 部署方式

Kubernetes marks a 部署方式 as 进步的 当执行以下任务之一时:

  • The 部署方式 creates a new 复制集.
  • The 部署方式 is scaling up its newest 复制集.
  • The 部署方式 is scaling down its older 复制集(s).
  • 新Pod已准备就绪或可用(至少准备就绪) MinReadySeconds)。

You can monitor the progress for a 部署方式 by using kubectl rollout status.

Complete 部署方式

Kubernetes marks a 部署方式 as 完成 具有以下特征时:

  • 与Deployment关联的所有副本已更新为您的最新版本’ve指定,表示任何 updates you’ve请求已完成。
  • 与部署关联的所有副本均可用。
  • 没有 old 复制品 for the 部署方式 are running.

You can check if a 部署方式 has 完成d by using kubectl rollout status. If the rollout 完成d successfully, kubectl rollout status returns a zero exit code.

kubectl rollout status deployment.v1.apps/nginx-deployment

输出类似于以下内容:

Waiting for rollout to finish: 2 of 3 updated 复制品 are available...
deployment.apps/nginx-deployment successfully rolled out
$ echo $?
0

Failed 部署方式

尝试部署其最新的ReplicaSet可能会遇到麻烦,而没有完成。这可能发生 由于以下某些因素:

  • 配额不足
  • 准备就绪探针故障
  • 图像拉出错误
  • 权限不足
  • 极限范围
  • 应用程序运行时配置错误

检测这种情况的一种方法是在“部署”规范中指定一个截止日期参数: (.spec.progressDeadlineSeconds)。 .spec.progressDeadlineSeconds denotes the 部署控制器在指示(处于“部署”状态)之前等待的秒数 部署进度已停止。

The following kubectl command sets the spec with progressDeadlineSeconds to make the controller report lack of progress for a 部署方式 after 10 minutes:

kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

输出类似于以下内容:

deployment.apps/nginx-deployment patched

一旦超过了最后期限,Deployment控制器将添加一个DeploymentCondition并包含以下内容: attributes to the 部署方式’s .status.conditions:

  • 类型=进行中
  • 状态=假
  • 原因=超过进度截止期限

Kubernetes API约定 有关状态条件的更多信息。

注意: Kubernetes对停滞的部署不采取任何措施,只能通过以下方式报告状态情况: 原因=超过进度截止期限。较高级别的编排者可以利用它并相应地采取行动, example, rollback the 部署方式 to its previous version.
注意: 如果暂停部署,Kubernetes不会在指定的期限内检查进度。您可以 在部署过程中安全地暂停部署并恢复,而不会触发超出 deadline.

由于您设置的超时时间短或 由于任何其他类型的错误都可以视为暂时错误。例如,让’s suppose you have 配额不足。如果描述部署,您将注意到以下部分:

kubectl describe deployment nginx-deployment

输出类似于以下内容:

<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    复制集Updated
  ReplicaFailure  True    FailedCreate
<...>

If you run kubectl get deployment nginx-deployment -o yaml, the 部署方式 status is similar to this:

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: Replica set "nginx-deployment-4262182780" is 进步的.
    reason: 复制集Updated
    status: "True"
    type: Progressing
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: 部署方式 has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
      object-counts, requested: pods=1, used: pods=3, limited: pods=2'
    reason: FailedCreate
    status: "True"
    type: ReplicaFailure
  observedGeneration: 3
  复制品: 2
  unavailableReplicas: 2

最终,一旦超过了部署进度的最后期限,Kubernetes便会更新状态并更新 病情进展的原因:

Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     False   ProgressDeadlineExceeded
  ReplicaFailure  True    FailedCreate

您可以通过缩减部署,缩减其他部署来解决配额不足的问题 您可能正在运行的控制器,或者通过增加名称空间中的配额。如果您满足配额 条件,然后部署控制器完成“部署”部署,您’ll see the Deployment’s status update with a successful condition (Status=TrueReason=NewReplicaSetAvailable)。

Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable

Type=Available with Status=True means that your 部署方式 has minimum availability. Minimum availability is dictated by the parameters specified in the deployment strategy. 类型=进行中 with Status=True means that your 部署方式 处于发布过程中并且正在进行中,或者它已成功完成其进度和最低要求 所需的新副本可用(请参见特殊条件的原因-在我们的情况下 Reason=NewReplicaSetAvailable means that the 部署方式 is 完成).

You can check if a 部署方式 has failed to progress by using kubectl rollout status. kubectl rollout status 如果部署已超过进度期限,则返回非零退出代码。

kubectl rollout status deployment.v1.apps/nginx-deployment

输出类似于以下内容:

Waiting for rollout to finish: 2 out of 3 new 复制品 have been updated...
error: deployment "nginx" exceeded its progress deadline
$ echo $?
1

对失败的部署进行操作

适用于完整部署的所有操作也适用于失败的部署。您可以放大/缩小,回滚 到以前的版本,或者如果您需要在Deployment 荚模板中应用多个调整,甚至暂停它。

清理政策

You can set .spec.revisionHistoryLimit field in a 部署方式 to specify how many old 副本集 for 您想要保留的部署。其余的将在后台进行垃圾收集。默认, it is 10.

注意: 将此字段明确设置为0,将清除所有Deployment的历史记录 thus that 部署方式 will not be able to roll back.

Canary 部署方式

如果要使用“部署”将发行版发布到一部分用户或服务器,则可以 可以按照以下内容中描述的canary模式创建多个Deployment,每个版本一个。 管理资源.

Writing a 部署方式 Spec

As with all other Kubernetes configs, a 部署方式 needs apiVersion, kind, 和 metadata fields. 有关使用配置文件的一般信息,请参见 部署应用, 配置容器,以及 使用kubectl管理资源 文件。

部署 also needs a .spec 部分.

吊舱模板

The .spec.template.spec.selector are the only required field of the .spec.

The .spec.template is a 吊舱模板。它的架构与 ,但它是嵌套的并且没有 apiVersion 要么 kind.

除了Pod的必填字段外,部署中的Pod模板还必须指定适当的字段 标签和适当的重启策略。对于标签,请确保不要与其他控制器重叠。看到 选择器)。

只有一个 .spec.template.spec.restartPolicy equal to Always is 允许,如果未指定,则为默认值。

复制品

.spec.replicas 是一个可选字段,用于指定所需Pod的数量。默认为1。

选择器

.spec.selector 是必填字段,用于指定 标签选择器 for the 豆荚 targeted by this 部署方式.

.spec.selector must match .spec.template.metadata.labels, 要么 it will be rejected by the API.

In API version apps/v1, .spec.selector.metadata.labels do not default to .spec.template.metadata.labels if not set. So they must be set explicitly. Also note that .spec.selector is immutable after creation of the 部署方式 in apps/v1.

部署 may terminate 豆荚 whose labels match the 选择器 if their template is different from .spec.template 要么 if the total number of such 豆荚 exceeds .spec.replicas. It brings up new Pods with .spec.template if the number of 豆荚 is less than the desired number.

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

如果您有多个具有重叠选择器的控制器,则这些控制器将与每个 other 和 won’t behave correctly.

战略

.spec.strategy 指定用于用新Pod替换旧Pod的策略。 .spec.strategy.type 可“Recreate” 要么 “RollingUpdate”. “RollingUpdate” is the default 值.

重新建立 部署方式

All existing 豆荚 are killed before new ones are created when .spec.strategy.type==Recreate.

Rolling Update 部署方式

The 部署方式 updates 豆荚 in a 滚动更新 fashion when .spec.strategy.type==RollingUpdate. You can specify maxUnavailablemaxSurge to control 滚动更新过程。

最大值不可用

.spec.strategy.rollingUpdate.maxUnavailable 是一个可选字段,用于指定最大数量 在更新过程中可能无法使用的Pod数量。该值可以是绝对数字(例如5) 或所需Pod的百分比(例如10%)。绝对数由百分比计算得出 rounding down. The 值 cannot be 0 if .spec.strategy.rollingUpdate.maxSurge is 0. The default 值 is 25%.

例如,当此值设置为30%时,旧的ReplicaSet可以按比例缩小到所需的70% 滚动更新开始时立即放置。一旦准备好新的Pod,就可以缩放旧的ReplicaSet 进一步降低,然后扩展新的ReplicaSet,确保可用的Pod总数 在更新过程中,始终至少需要所需Pod的70%。

最大浪涌

.spec.strategy.rollingUpdate.maxSurge 是一个可选字段,用于指定Pod的最大数量 可以在所需数量的Pod上创建。该值可以是绝对数字(例如5),也可以是 percentage of desired 豆荚 (for example, 10%). The 值 cannot be 0 if MaxUnavailable is 0. The absolute number 由四舍五入的百分比计算得出。默认值为25%。

例如,当该值设置为30%时,新的ReplicaSet可以在 开始滚动更新,以使旧的和新的Pod总数不超过所需的130% 豆荚。旧的Pod被杀死后,新的ReplicaSet可以进一步扩大规模,从而确保 更新期间随时运行的Pod总数最多为所需Pod的130%。

进度截止秒

.spec.progressDeadlineSeconds 是一个可选字段,用于指定所需的秒数 在系统报告部署已完成之前等待部署继续进行 进度失败 - surfaced as a condition with 类型=进行中, 状态=假. and 原因=超过进度截止期限 in the status of the resource. The 部署方式 controller will keep 重试部署。将来,一旦实施自动回滚,部署 一旦发现这种情况,控制器将回退部署。

If specified, this field needs to be greater than .spec.minReadySeconds.

最小准备秒

.spec.minReadySeconds 是一个可选字段,用于指定新 创建的Pod应该已经准备就绪,不会发生任何容器崩溃的情况,才能被视为可用。 默认为0(准备就绪后,该Pod将被视为可用)。进一步了解何时 Pod已准备就绪,请参阅 容器探针.

回滚到

Field .spec.rollbackTo has been deprecated in API versions extensions/v1beta1apps/v1beta1, 和 is no longer supported in API versions starting apps/v1beta2. Instead, kubectl rollout undo as introduced in 回滚到以前的修订 应该使用。

修订历史记录限制

部署’的修订历史记录存储在它控制的ReplicaSets中。

.spec.revisionHistoryLimit 是一个可选字段,用于指定要保留的旧副本集的数量 to allow rollback. These old 副本集 consume resources in etcd 和 crowd the output of kubectl get rs. The configuration of each 部署方式 revision is stored in its 副本集; therefore, once an old 复制集 is deleted, you lose the ability to rollback to that revision of 部署方式. By default, 10 old 副本集 will be kept, however its ideal 值 depends on the frequency 和 stability of new 部署方式s.

更具体地说,将此字段设置为零意味着将清除所有具有0个副本的旧ReplicaSet。 在这种情况下,由于已清除其修订历史记录,因此无法撤消新的“部署”部署。

已暂停

.spec.paused 是一个可选的布尔字段,用于暂停和恢复部署。之间的唯一区别 暂停的部署和不暂停的部署是对暂停的PodTemplateSpec的任何更改 只要暂停部署,部署就不会触发新的部署。默认情况下,部署不会暂停 it is created.

Alternative to 部署方式s

Kubectl滚动更新

Kubectl滚动更新 更新Pods和复制控制器s 以类似的方式。但是建议部署,因为它们是声明性的,服务器端的,并且具有 其他功能,例如即使在完成滚动更新后也可以回滚到任何以前的版本。

反馈