概述

我将它们简单的分类为以下几种资源对象：

类别 名称
资源对象 Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition
存储对象 Volume、PersistentVolume、Secret、ConfigMap
策略对象 SecurityContext、ResourceQuota、LimitRange
身份对象 ServiceAccount、Role、ClusterRole

必需字段

在想要创建的 Kubernetes 对象对应的 .yaml 文件中，需要配置如下的字段：

  • apiVersion - 创建该对象所使用的 Kubernetes API 的版本
  • kind - 想要创建的对象的类型
  • metadata - 帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace

也需要提供对象的 spec 字段。对象 spec 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。Kubernetes API 参考能够帮助我们找到任何我们想创建的对象的 spec 格式。

ReplicaSet

Kubernetes 中的 ReplicaSet 主要的作用是维持一组 Pod 副本的运行，它的主要作用就是保证一定数量的 Pod 能够在集群中正常运行，它会持续监听这些 Pod 的运行状态，在 Pod 发生故障重启数量减少时重新运行新的 Pod 副本。

这篇文章会介绍 ReplicaSet 的工作原理，其中包括在 Kubernetes 中是如何被创建的、如何创建并持有 Pod 并在出现问题时重启它们。

在具体介绍 ReplicaSet 的实现原理之前，我们还是会先简单介绍它的使用，与其他的 Kubernetes 对象一样，我们会在 Kubernetes 集群中使用 YAML 文件创建新的 ReplicaSet 对象，一个常见的 ReplicaSet 的定义其实是这样的：

apiVersion: apps/v1

kind: ReplicaSet

metadata:

  name: frontend

  labels:

    app: guestbook

    tier: frontend

spec:

  replicas: 3

  selector:

    matchLabels:

      tier: frontend

  template:

    metadata:

      labels:

        tier: frontend

    spec:

      containers:

      - name: php-redis

        image: gcr.io/google_samples/gb-frontend:v3

这里的 YAML 文件除了常见的 apiVersion、kind 和 metadata 属性之外，规格中总共包含三部分重要内容，也就是 Pod 副本数目 replicas、选择器 selector 和 Pod 模板 template，这三个部分共同定义了 ReplicaSet 的规格：

同一个 ReplicaSet 会使用选择器 selector 中的定义查找集群中自己持有的 Pod 对象，它们会根据标签的匹配获取能够获得的 Pod，下面就是持有三个 Pod 对象的 Replica 拓扑图：

被 ReplicaSet 持有的 Pod 有一个 metadata.ownerReferences 指针指向当前的 ReplicaSet，表示当前 Pod 的所有者，这个引用主要会被集群中的 垃圾收集器 使用以清理失去所有者的 Pod 对象。

实现原理

所有 ReplicaSet 对象的增删改查都是由 ReplicaSetController 控制器完成的，该控制器会通过 Informer 监听 ReplicaSet 和 Pod 的变更事件并将其加入持有的待处理队列:

ReplicaSetController 中的 queue 其实就是一个存储待处理 ReplicaSet 的『对象池』，它运行的几个 Goroutine 会从队列中取出最新的数据进行处理，上图展示了事件从发生到被处理的流向，我们接下来将分别介绍 ReplicaSet 中常见的同步过程。

Deployment

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

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

比如一个简单的nginx应用可以定义为

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

扩容：

kubectl scale deployment nginx-deployment --replicas 10

如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展：

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

更新镜像也比较简单:

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

回滚：

kubectl rollout undo deployment/nginx-deployment

更新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数量。

我们通过执行kubectl get rs可以看到 Deployment 更新了Pod，通过创建一个新的 ReplicaSet 并扩容了3个 replica，同时将原来的 ReplicaSet 缩容到了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数量少一个是up状态（最多一个不可用）。

Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）。

在未来的 Kuberentes 版本中，将从1-1变成25%-25%。

例如，如果您自己看下上面的 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 的时候，创建了一个 ReplicaSet（nginx-deployment-2035384211），并直接扩容到了3个 replica。

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

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

回退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 状态监控。

您会看到旧的 replica（nginx-deployment-1564180365 和 nginx-deployment-2035384211）和新的 replica （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，您会看到有两个新的 ReplicaSet 创建的 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，并停止扩容新的 ReplicaSet。

$ 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 https://kubernetes.io/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 的时候使用了--record参数可以记录命令，我们可以很方便的查看每次 revision 的变化。

查看单个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

该 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

您可以通过设置.spec.revisonHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为0，Deployment就不允许回退了。

Deployment 扩容

您可以使用以下命令扩容 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 将会平衡已存在的活动中的 ReplicaSet（有 Pod 的 ReplicaSet）和新加入的 replica。这被称为比例扩容。

例如，您正在运行中含有10个 replica 的 Deployment。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状态。

进行中的 Deployment

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

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

您可以使用kubectl rollout status命令监控 Deployment 的进度。

完成的 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

失败的 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，在暂停的这段时间内kubernetnes不会检查您指定的 deadline。您可以在 Deployment 的 rollout 途中安全的暂停它，然后再恢复它，这不会触发超过deadline的状态。

您可能在使用 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，kubernetes 会更新状态和导致 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 历史记录都会被清除，该 Deployment 就无法再回退了。

参考：

资源对象与基本概念解析

深入解析 kubernetes 资源管理，容器云牛人有话说

Kubernetes学习之路（十）之资源清单定义

详解 Kubernetes ReplicaSet 的实现原理

Deployment

Kubernetes 资源对象的更多相关文章

  1. [置顶] kubernetes资源对象--Label

    概念 Label机制是K8S中一个重要设计,通过Label进行对象弱关联,灵活地分类和选择不同服务或业务,让用户根据自己特定的组织结构以松耦合方式进行服务部署. Label是一对KV,对用户而言非常有 ...

  2. [置顶] kubernetes资源对象--ResourceQuotas

    概念 Resource Quotas(资源配额,简称quota)是对namespace进行资源配额,限制资源使用的一种策略. K8S是一个多用户架构,当多用户或者团队共享一个K8S系统时,SA使用qu ...

  3. [置顶] kubernetes资源对象--ConfigMap

    原理 很多生产环境中的应用程序配置较为复杂,可能需要多个config文件.命令行参数和环境变量的组合.使用容器部署时,把配置应该从应用程序镜像中解耦出来,以保证镜像的可移植性.尽管Secret允许类似 ...

  4. [置顶] kubernetes资源对象--limitranges

    概念 LimitRange(简称limits)基于namespace的资源管理,包括pod和container的最小.最大和default.defaultrequests等. 一旦创建limits,以 ...

  5. [置顶] kubernetes资源对象--Horizontal Pod Autoscaling（HPA）

    概念 HPA全称Horizontal Pod Autoscaling,即pod的水平自动扩展.自动扩展主要分为两种,其一为水平扩展,针对于实例数目的增减:其二为垂直扩展,即单个实例可以使用的资源的增减 ...

  6. kubernetes 基本概念和资源对象汇总

    kubernetes 基本概念和知识点脑图 基本概念 kubernetes 中的绝大部分概念都抽象成kubernets管理的资源对象,主要有以下类别: Master : Master节点是kubern ...

  7. Kubernetes资源与对象简述

    资料 k8s基本对象概念 背景 资源和对象   Kubernetes 中的所有内容都被抽象为"资源",如 Pod.Service.Node 等都是资源."对象" ...

  8. kubernetes之常用核心资源对象

    部门产品线本身是做DEVOPS平台,最近部署架构也在往K8S上靠了,不得不学一下K8S.自己搭建了K8S集群与harbor仓库来学习. 1.kubernetes之常用核心资源对象 1.1.K8s服务部 ...

  9. kubernetes系列06—kubernetes资源清单定义入门

    本文收录在容器技术学习系列文章总目录 1.认识kubernetes资源 1.1 常用资源/对象 workload工作负载型资源:pod,ReplicaSet,Deployment,StatefulSe ...

随机推荐

  1. 从GopherChina 2019看当前的go语言

    GopherChina 2019大会4月底刚刚结束,大会上使用的PPT也放了出来(大会情况及PPT在https://mp.weixin.qq.com/s/_oVpIcBMVIKVzQn6YrkAJw) ...

  2. PostMan测试REST接口时候，如何绕过登录的验证

    原文地址:https://blog.csdn.net/qq_34178998/article/details/80361315 之前测试的时候,需要页面进行登录之后,才能让访问后台程序,但是在进行接口 ...

  3. Leetcode 344：Reverse String 反转字符串（python、java）

    Leetcode 344:Reverse String 反转字符串 公众号:爱写bug Write a function that reverses a string. The input strin ...

  4. Oracle体系结构学习笔记

    Oracle体系结构由实例和一组数据文件组成,实例由SGA内存区,SGA意思是共享内存区,由share pool(共享池).data buffer(数据缓冲区).log buffer(日志缓冲区)组成 ...

  5. mybatis使用associaton进行分步查询

    Employee类 public class Employee { private Integer id; private String lastName; private String email; ...

  6. luogu P1533 可怜的狗狗 |莫队+二分

    题目背景 小卡由于公务需要出差,将新家中的狗狗们托付给朋友嘉嘉,但是嘉嘉是一个很懒的人,他才没那么多时间帮小卡喂狗狗. 题目描述 小卡家有N只狗,由于品种.年龄不同,每一只狗都有一个不同的漂亮值.漂亮 ...

  7. 【排错】springboot项目，启动报An attempt was made to call the method com.google.gson.GsonBuilder.setLenient()Lcom/google/gson/GsonBuilder; but it does not exist.

    pom文件新引入:     <dependency>         <groupId>com.google.code.gson</groupId>         ...

  8. Scala中sortBy和Spark中sortBy区别

    Scala中sortBy是以方法的形式存在的,并且是作用在Array或List集合排序上,并且这个sortBy默认只能升序,除非实现隐式转换或调用reverse方法才能实现降序,Spark中sortB ...

  9. golang --os系统包

    环境变量 Environ 获取所有环境变量, 返回变量列表 func Environ() []string package main import ( "fmt" "os ...

  10. goang学习笔记---struct

    什么是结构体 结构体(struct)是用户自定义的类型,它代表若干字段的集合,可以用于描述一个实体对象,类似java中的class,是golang面向对象编程的基础类型. 如何定义一个结构体 type ...