kubernetes对象之deployment

时间  2019-11-11
标签 kubernetes 对象 deployment 繁體版
原文   原文链接

系列目录html

简述

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

  • 定义Deployment来建立Pod和ReplicaSetapi

  • 滚动升级和回滚应用bash

  • 扩容和缩容app

  • 暂停和继续Deploymentide

好比一个简单的nginx应用能够定义为:oop

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

扩容:ui

kubectl scale deployment nginx-deployment --replicas 10

若是集群支持 horizontal pod autoscaling 的话，还能够为Deployment设置自动扩展：spa

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

回滚:.net

kubectl rollout undo deployment/nginx-deployment

Deployment是什么

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。

你只须要在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示例，它建立了一个Replica Set来启动3个nginx pod。

执行deployment

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
deployment "nginx-deployment" created

注意,kubectl create -f后面跟一个文件名,实际工做中要以你的实际文件名和路径为准

将kubectl的 —record 的flag设置为 true能够在annotation中记录当前命令建立或者升级了该资源。这在将来会颇有用，例如，查看在每一个Deployment revision中执行了哪些命令。

而后当即执行getí将得到以下结果：

$ kubectl get deployments
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         0         0            0           1s

输出结果代表咱们但愿的repalica数是3（根据deployment中的.spec.replicas配置）当前replica数（ .status.replicas）是0, 最新的replica数（.status.updatedReplicas）是0，可用的replica数（.status.availableReplicas）是0。

过几秒后再执行get命令，将得到以下输出：

$ kubectl get deployments
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           18s

咱们能够看到Deployment已经建立了3个replica，全部的replica都已是最新的了（包含最新的pod template），可用的（根据Deployment中的.spec.minReadySeconds声明，处于已就绪状态的pod的最少个数）。执行kubectl get rs和kubectl get pods会显示Replica Set（RS）和Pod已建立。

$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-2035384211   3         3         0       18s

你可能会注意到Replica Set的名字老是 - 。 

$ kubectl get pods --show-labels
NAME                                READY     STATUS    RESTARTS   AGE       LABELS
nginx-deployment-2035384211-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=2035384211

刚建立的Replica Set将保证老是有3个nginx的pod存在。

注意： 你必须在Deployment中的selector指定正确pod template label（在该示例中是 app = nginx），不要跟其余的controller搞混了（包括Deployment、Replica Set、Replication Controller等）。Kubernetes自己不会阻止你这么作，若是你真的这么作了，可能致使不正确的行为。

更新Deployment

注意： Deployment的rollout当且仅当Deployment的pod template（例如.spec.template）中的label更新或者镜像更改时被触发。其余更新，例如扩容Deployment不会触发rollout。

假如咱们如今想要让nginx pod使用nginx:1.9.1的镜像来代替原来的nginx:1.7.9的镜像。

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated

咱们可使用edit命令来编辑Deployment，修改 .spec.template.spec.containers[0].image ，将nginx:1.7.9 改写成nginx:1.9.1。

$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited

查看rollout的状态，只要执行：

$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

Rollout成功后，get Deployment：

$ kubectl get deployments
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           36s

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

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

We can run kubectl get rs to see that the Deployment updated the Pods by creating a new Replica Set and scaling it up to 3 replicas, as well as scaling down the old Replica Set to 0 replicas.

咱们经过执行kubectl get rs能够看到Deployment更新了Pod，经过建立一个新的Replica Set并扩容了3个replica，同时将原来的Replica Set缩容到了0个replica。

$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   3         3         0       6s
nginx-deployment-2035384211   0         0         0       36s

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

$ 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的时候，只须要更新Deployment中的pod的template便可。

Deployment能够保证在升级时只有必定数量的Pod是down的。默认的，它会确保至少有比指望的Pod数量少一个的Pod是up状态（最多一个不可用）。

Deployment同时也能够确保只建立出超过时望数量的必定数量的Pod。默认的，它会确保最多比指望的Pod数量多一个的Pod是up的（最多1个surge）。

在将来的Kuberentes版本中，将从1-1变成25%-25%） 注笔者使用的是1.13版本,已是这样的了.

例如，若是你本身看下上面的Deployment，你会发现，开始建立一个新的Pod，而后删除一些旧的Pod再建立一个新的。当新的Pod建立出来以前不会杀掉旧的Pod。这样可以确保可用的Pod数量至少有2个，Pod的总数最多4个。

$ kubectl describe deployments
Name:           nginx-deployment
Namespace:      default
CreationTimestamp:  Tue, 15 Mar 2016 12:01:06 -0700
Labels:         app=nginx
Selector:       app=nginx
Replicas:       3 updated | 3 total | 3 available | 0 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
OldReplicaSets:     <none>
NewReplicaSet:      nginx-deployment-1564180365 (3/3 replicas created)
Events:
  FirstSeen LastSeen    Count   From                     SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                     -------------   --------    ------              -------
  36s       36s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  23s       23s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  21s       21s         1       {deployment-controller }                 Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3

咱们能够看到当咱们刚开始建立这个Deployment的时候，建立了一个Replica Set（nginx-deployment-2035384211），并直接扩容到了3个replica。

当咱们更新这个Deployment的时候，它会建立一个新的Replica Set（nginx-deployment-1564180365），将它扩容到1个replica，而后缩容原先的Replica Set到2个replica，此时知足至少2个Pod是可用状态，同一时刻最多有4个Pod处于建立的状态。

接着继续使用相同的rolling update策略扩容新的Replica Set和缩容旧的Replica Set。最终，将会在新的Replica Set中有3个可用的replica，旧的Replica Set的replica数目变成0。

Rollover（多个rollout并行）

每当Deployment controller观测到有新的deployment被建立时，若是没有已存在的Replica Set来建立指望个数的Pod的话，就会建立出一个新的Replica Set来作这件事。已存在的Replica Set控制label匹配.spec.selector可是template跟.spec.template不匹配的Pod缩容。最终，新的Replica Set将会扩容出.spec.replicas指定数目的Pod，旧的Replica Set会缩容到0。

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

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

回退Deployment

有时候你可能想回退一个Deployment，例如，当Deployment不稳定时，好比一直crash looping。

默认状况下，kubernetes会在系统中保存前两次的Deployment的rollout历史记录，以便你能够随时会退（你能够修改revision history limit来更改保存的revision数）

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

其余的更新，好比扩容Deployment不会建立revision——所以咱们能够很方便的手动或者自动扩容。这意味着当你回退到历史revision是，只有Deployment中的Pod template部分才会回退。

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

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
deployment "nginx-deployment" image updated

Rollout将会卡住。

$ kubectl rollout status deployments nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

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

你会看到旧的replicas（nginx-deployment-1564180365 和 nginx-deployment-2035384211）和新的replicas （nginx-deployment-3066724191）数目都是2个。

$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   2         2         0       25s
nginx-deployment-2035384211   0         0         0       36s
nginx-deployment-3066724191   2         2         2       6s

看下建立Pod，你会看到有两个新的Replica Set建立的Pod处于ImagePullBackOff状态，循环拉取镜像。

$ 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-3066724191-08mng   0/1       ImagePullBackOff   0          6s
nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s

注意，Deployment controller会自动中止坏的rollout，并中止扩容新的Replica Set

$ kubectl describe deployment
Name:           nginx-deployment
Namespace:      default
CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
Labels:         app=nginx
Selector:       app=nginx
Replicas:       2 updated | 3 total | 2 available | 2 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
OldReplicaSets:     nginx-deployment-1564180365 (2/2 replicas created)
NewReplicaSet:      nginx-deployment-3066724191 (2/2 replicas created)
Events:
  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                    -------------   --------    ------              -------
  1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
  13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2

为了修复这个问题，咱们须要回退到稳定的Deployment revision。

检查Deployment升级的历史记录

首先，检查下Deployment的revision：

$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION    CHANGE-CAUSE
1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91

由于咱们建立Deployment的时候使用了—recored参数能够记录命令，咱们能够很方便的查看每次revison的变化。

查看单个revision的详细信息：

$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
  Labels:       app=nginx
          pod-template-hash=1159050644
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      <none>
  No volumes.

回退到历史版本

如今，咱们能够决定回退当前的rollout到以前的版本：

$ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back

也可使用 --revision参数指定某个历史版本：

$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back

与rollout相关的命令详细文档见kubectl rollout。

该Deployment如今已经回退到了先前的稳定版本。如你所见，Deployment controller产生了一个回退到revison 2的DeploymentRollback的event。

$ kubectl get deployment
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           30m

$ 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 updated | 3 total | 3 available | 0 unavailable
StrategyType:       RollingUpdate
MinReadySeconds:    0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
OldReplicaSets:     <none>
NewReplicaSet:      nginx-deployment-1564180365 (3/3 replicas created)
Events:
  FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
  --------- --------    -----   ----                    -------------   --------    ------              -------
  30m       30m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 2
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
  29m       29m         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-1564180365 to 2
  2m        2m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-3066724191 to 0
  2m        2m          1       {deployment-controller }                Normal      DeploymentRollback  Rolled back deployment "nginx-deployment" to revision 2
  29m       2m          2       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3

清理Policy

你可使用如下命令扩容Deployment：

$ kubectl scale deployment nginx-deployment --replicas 10
deployment "nginx-deployment" scaled

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

$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
deployment "nginx-deployment" autoscaled

比例扩容

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

例如，正在运行中的Deployment含有10个replica,maxSurge=3，maxUnavailable=2。

$ kubectl get deploy
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment     10        10        10           10          50s

你更新了一个镜像，而在集群内部没法解析

$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
deployment "nginx-deployment" image updated

镜像更新启动了一个包含ReplicaSet nginx-deployment-1989198191的新的rollout，可是它被阻塞了，由于咱们上面提到的maxUnavailable。

$ kubectl get rs
NAME                          DESIRED   CURRENT   READY     AGE
nginx-deployment-1989198191   5         5         0         9s
nginx-deployment-618515232    8         8         8         1m

而后发起了一个新的Deployment扩容请求。autoscaler将Deployment的repllica数目增长到了15个。Deployment controller须要判断在哪里增长这5个新的replica。若是咱们没有谁用比例扩容，全部的5个replica都会加到一个新的ReplicaSet中。若是使用比例扩容，新添加的replica将传播到全部的ReplicaSet中。大的部分加入replica数最多的ReplicaSet中，小的部分加入到replica数少的ReplciaSet中。0个replica的ReplicaSet不会被扩容。

在咱们上面的例子中，3个replica将添加到旧的ReplicaSet中，2个replica将添加到新的ReplicaSet中。rollout进程最终会将全部的replica移动到新的ReplicaSet中，假设新的replica成为健康状态。

$ 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

暂停和恢复Deployment

你能够在触发一次或屡次更新前暂停一个Deployment，而后再恢复它。这样你就能屡次暂停和恢复Deployment，在此期间进行一些修复工做，而不会出发没必要要的rollout。

例如使用刚刚建立Deployment：

$ kubectl get deploy
NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     3         3         3            3           1m
[mkargaki@dhcp129-211 kubernetes]$ kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         1m

使用如下命令暂停Deployment：

$ kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" paused

而后更新Deplyment中的镜像：

$ kubectl set image deploy/nginx nginx=nginx:1.9.1
deployment "nginx-deployment" image updated

注意新的rollout启动了：

$ kubectl rollout history deploy/nginx
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 nginx -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx" resource requirements updated

Deployment暂停前的初始状态将继续它的功能，而不会对Deployment的更新产生任何影响，只要Deployment是暂停的。

最后，恢复这个Deployment，观察完成更新的ReplicaSet已经建立出来了：

$ kubectl rollout resume deploy nginx
deployment "nginx" resumed
$ 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
^C
$ KUBECTL get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         28s

注意： 在恢复Deployment以前你没法回退一个暂停了个Deployment。

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
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0

Failed Deployment

你的Deployment在尝试部署新的ReplicaSet的时候可能卡住,这多是由于如下几个因素引发的：

  • 无效的引用

  • 不可读的probe failure

  • 镜像拉取错误

  • 权限不够

  • 范围限制

  • 程序运行时配置错误

探测这种状况的一种方式是，在你的Deployment spec中指定spec.progressDeadlineSeconds。spec.progressDeadlineSeconds表示Deployment controller等待多少秒才能肯定（经过Deployment status）Deployment进程是卡住的。

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

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

当超过截止时间后，Deployment controller会在Deployment的 status.conditions中增长一条DeploymentCondition，它包括以下属性：

  • Type=Progressing
  • Status=False
  • Reason=ProgressDeadlineExceeded

注意： kubernetes除了报告Reason=ProgressDeadlineExceeded状态信息外不会对卡住的Deployment作任何操做。更高层次的协调器能够利用它并采起相应行动，例如，回滚Deployment到以前的版本。

你可能在使用Deployment的时候遇到一些短暂的错误，这些多是因为你设置了过短的timeout，也有多是由于各类其余错误致使的短暂错误。例如，假设你使用了无效的引用。当你Describe Deployment的时候可能会注意到以下信息：

$ kubectl describe deployment nginx-deployment
<...>
Conditions:
  Type            Status  Reason
  ----            ------  ------
  Available       True    MinimumReplicasAvailable
  Progressing     True    ReplicaSetUpdated
  ReplicaFailure  True    FailedCreate
<...>

执行 kubectl get deployment nginx-deployment -o yaml，Deployement 的状态可能看起来像这个样子：

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:39Z
    lastUpdateTime: 2016-10-04T12:25:39Z
    message: Replica set "nginx-deployment-4262182780" is progressing.
    reason: ReplicaSetUpdated
    status: "True"
    type: Progressing
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: Deployment 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
  replicas: 2
  unavailableReplicas: 2

最终，一旦超过Deployment进程的deadline，kuberentes会更新状态和致使Progressing状态的缘由：

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

你能够经过缩容Deployment的方式解决配额不足的问题，或者增长你的namespace的配额。若是你知足了配额条件后，Deployment controller就会完成你的Deployment rollout，你将看到Deployment的状态更新为成功状态（Status=True而且Reason=NewReplicaSetAvailable）。

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

Type=Available、 Status=True 意味着你的Deployment有最小可用性。 最小可用性是在Deployment策略中指定的参数。Type=Progressing 、 Status=True意味着你的Deployment 或者在部署过程当中，或者已经成功部署，达到了指望的最少的可用replica数量（查看特定状态的Reason——在咱们的例子中Reason=NewReplicaSetAvailable 意味着Deployment已经完成）。

你可使用kubectl rollout status命令查看Deployment进程是否失败。当Deployment过程超过了deadline，kubectl rollout status将返回非0的exit code。

$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
$ echo $?
1

操做失败的Deployment

全部对完成的Deployment的操做都适用于失败的Deployment。你能够对它扩／缩容，回退到历史版本，你甚至能够屡次暂停它来应用Deployment pod template。

清理Policy

你能够设置Deployment中的 .spec.revisionHistoryLimit 项来指定保留多少旧的ReplicaSet。 余下的将在后台被看成垃圾收集。默认的，全部的revision历史就都会被保留。在将来的版本中，将会更改成2。

注意： 将该值设置为0，将致使全部的Deployment历史记录都会被清除，该Deploynent就没法再回退了。

编写Deployment Spec指南

在全部的Kubernetes配置中，Deployment也须要apiVersion，kind和metadata这些配置项。配置文件的通用使用说明查看部署应用，配置容器，和使用kubeclt管理资源文档。

Deployment也须要 .spec section.

Pod Template

.spec.template 是 .spec中惟一要求的字段。

.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拒绝。若是 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是 .spec.template.metadata.labels。

在Pod的template跟.spec.template不一样或者数量超过了.spec.replicas规定的数量的状况下，Deployment会杀掉label跟selector不一样的Pod。

注意： 你不该该再建立其余label跟这个selector匹配的pod，或者经过其余Deployment，或者经过其余Controller，例如ReplicaSet和ReplicationController。不然该Deployment会被把它们当成都是本身建立的。Kubernetes不会阻止你这么作。

若是你有多个controller使用了重复的selector，controller们就会互相冲突并致使不正确的行为。

策略

.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=Progressing、Status=False、 Reason=ProgressDeadlineExceeded前能够等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。将来，在实现了自动回滚后， deployment controller在观察到这种状态时就会自动回滚。

若是设置该参数，该值必须大于 .spec.minReadySeconds。

  • Min Ready Seconds

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

  • 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。

原文连接

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程