基于Replication Controller执行滚动升级

ERROR

You must define a overview

This template requires that you provide text that states, in one or two sentences, the purpose of this document. The text in this block will be displayed under the heading . To get rid of this message and take advantage of this template, capture the overview variable and populate it with content.

ERROR

You must define a body

This template requires that you provide text that supplies the body of the page content.. The text in this block will be displayed under the heading . To get rid of this message and take advantage of this template, capture the body variable and populate it with content.

概述

注: 创建副本应用的首选方法是使用Deployment，Deployment使用ReplicaSet来进行副本控制。 更多信息, 查看使用Deployment运行一个无状态应用。

为了在更新服务的同时不中断业务， kubectl 支持‘滚动更新’，它一次更新一个pod，而不是同时停止整个服务。 有关更多信息，请参阅 滚动更新设计文档 和 滚动更新示例。

请注意， kubectl rolling-update 仅支持Replication Controllers。 但是，如果使用Replication Controllers部署应用，请考虑将其切换到Deployments. Deployment是一种被推荐使用的更高级别的控制器，它可以对应用进行声明性的自动滚动更新。 如果您仍然希望保留您的Replication Controllers并使用 kubectl rolling-update进行滚动更新， 请继续往下阅读：

滚动更新可以对replication controller所管理的Pod的配置进行变更，变更可以通过一个新的配置文件来进行，或者，如果只更新镜像，则可以直接指定新的容器镜像。

滚动更新的工作流程：

  1. 通过新的配置创建一个replication controller
  2. 在新的控制器上增加副本数，在旧的上面减少副本数，直到副本数达到期望值
  3. 删除之前的replication controller

使用kubectl rolling-update命令来进行滚动更新：

  1. $ kubectl rolling-update NAME \
  2.     ([NEW_NAME] --image=IMAGE | -f FILE)

通过配置文件更新

通过配置文件来进行滚动更新，需要在kubectl rolling-update命令后面带上新的配置文件：

  1. $ kubectl rolling-update NAME -f FILE

这个配置文件必须满足以下条件：

  • 指定不同的metadata.name值

  • 至少要修改spec.selector中的一个标签值

  • metadata.namespace字段必须相同

Replication Controllers的配置文件详细介绍见创建Replication Controllers.

示例

  1. // 通过新的配置文件frontend-v2.json来更新frontend-v1的pods
  2. $ kubectl rolling-update frontend-v1 -f frontend-v2.json
  4. // 将frontend-v2.json数据传到标准输入来更新frontend-v1的pods
  5. $ cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -

更新容器镜像

仅更新容器镜像的话，可通过如下命令，该命令可以指定一个新的控制器名称（可选），通过--image参数来指定新的镜像名称和标签。

  1. $ kubectl rolling-update NAME [NEW_NAME] --image=IMAGE:TAG

--image参数仅支持单容器pod，多容器pod使用--image参数会返回错误。

如果没有指定 NEW_NAME ，新的replication controller创建后会使用一个临时名称，当更新完成，旧的controller被删除后，新的controller名称会被更新成旧的controller名称。

如果IMAGE:TAG 和当前值相同，更新就会失败。 因此，我们建议使用版本号来作为标签，而不是使用 :latest。从一个 image:latest镜像升级到一个新的 image:latest 镜像将会失败，即使这两个镜像不是相同的。 所以，我们不建议使用 :latest 来作为标签，详细信息见最佳配置实践 。

示例

  1. // 更新frontend-v1的pod到frontend-v2
  2. $ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2
  4. // 更新frontend的pods，不更改replication controller的名称
  5. $ kubectl rolling-update frontend --image=image:v2

必选和可选字段

必选字段：

  • NAME: 需要进行滚动更新的replication controller名称

下面两个字段选其一：

  • -f FILE: 新的replication controller的配置文件，JSON或者YAML格式均可。配置文件必须指定一个新的顶层id值，且至少包含一个现有spec.selector中的键值对。 详细信息见通过Replication Controller运行无状态应用。

    或者：

  • --image IMAGE:TAG: 更新后的镜像的名称和标签。必须和当前的image:tag不同。

可选字段包括：

  • NEW_NAME: 只和 --image 一起使用，不和 -f FILE 一起使用。标识新的replication controller的名称。
  • --poll-interval DURATION: 在更新后轮询控制器状态的间隔时间。有效单位有 ns （纳秒），us 或 µs（微秒），ms（毫秒），s（秒），m（分钟）或 h（小时）。 单位可以自由组合（例如 1m30s）。 默认值为 3s。
  • --timeout DURATION: 退出更新之前，等待控制器更新一个pod的最大时间。默认是5m0s。有效单位如--poll-interval所述。
  • --update-period DURATION: 更新两个pod之间等待的时间，默认值是1m0s。有效单位如--poll-interval所述。

有关kubectl rolling-update命令的更多信息见kubectl参考.

实践

现在你运行了一个1.7.9版本的nginx应用：

  1. apiVersion: v1
  2. kind: ReplicationController
  3. metadata:
  4.   name: my-nginx
  5. spec:
  6.   replicas: 5
  7.   template:
  8.     metadata:
  9.       labels:
  10.         app: nginx
  11.     spec:
  12.       containers:
  13.       - name: nginx
  14.         image: nginx:1.7.9
  15.         ports:
  16.         - containerPort: 80

要更新到1.9.1版本，你可以使用kubectl rolling-update --image来指定一个新的镜像：

  1. $ kubectl rolling-update my-nginx --image=nginx:1.9.1
  2. Created my-nginx-ccba8fbd8cc8160970f63f9a2696fc46

在终端上打开另一个窗口 ，你可以看到kubectl 给每个pod都增加了一个值为配置文件哈希值的 deployment 标签，用来区分新旧pod：

  1. $ kubectl get pods -l app=nginx -L deployment
  2. NAME                                              READY     STATUS    RESTARTS   AGE       DEPLOYMENT
  3. my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-k156z   1/1       Running   0          1m        ccba8fbd8cc8160970f63f9a2696fc46
  4. my-nginx-ccba8fbd8cc8160970f63f9a2696fc46-v95yh   1/1       Running   0          35s       ccba8fbd8cc8160970f63f9a2696fc46
  5. my-nginx-divi2                                    1/1       Running   0          2h        2d1d7a8f682934a254002b56404b813e
  6. my-nginx-o0ef1                                    1/1       Running   0          2h        2d1d7a8f682934a254002b56404b813e
  7. my-nginx-q6all                                    1/1       Running   0          8m        2d1d7a8f682934a254002b56404b813e

使用kubectl rolling-update可以实时看到更新的进度：

  1. Scaling up my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 0 to 3, scaling down my-nginx from 3 to 0 (keep 3 pods available, don't exceed 4 pods)
  2. Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 1
  3. Scaling my-nginx down to 2
  4. Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 2
  5. Scaling my-nginx down to 1
  6. Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 up to 3
  7. Scaling my-nginx down to 0
  8. Update succeeded. Deleting old controller: my-nginx
  9. Renaming my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 to my-nginx
  10. replicationcontroller "my-nginx" rolling updated

如果遇到问题，你可以中途停止滚动更新，并且使用 --rollback 来回滚到以前的版本:

  1. $ kubectl rolling-update my-nginx --rollback
  2. Setting "my-nginx" replicas to 1
  3. Continuing update with existing controller my-nginx.
  4. Scaling up nginx from 1 to 1, scaling down my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 from 1 to 0 (keep 1 pods available, don't exceed 2 pods)
  5. Scaling my-nginx-ccba8fbd8cc8160970f63f9a2696fc46 down to 0
  6. Update succeeded. Deleting my-nginx-ccba8fbd8cc8160970f63f9a2696fc46
  7. replicationcontroller "my-nginx" rolling updated

这个例子说明容器的不变性是个巨大的优点。

如果你不仅仅是需要更新镜像，(例如，更新命令参数，环境变量等)，你可以创建一个新的replication controller配置文件，包含一个新的名称和不同的标签值，例如：

  1. apiVersion: v1
  2. kind: ReplicationController
  3. metadata:
  4.   name: my-nginx-v4
  5. spec:
  6.   replicas: 5
  7.   selector:
  8.     app: nginx
  9.     deployment: v4
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: nginx
  14.         deployment: v4
  15.     spec:
  16.       containers:
  17.       - name: nginx
  18.         image: nginx:1.9.2
  19.         args: ["nginx", "-T"]
  20.         ports:
  21.         - containerPort: 80

然后使用它来进行更新：

  1. $ kubectl rolling-update my-nginx -f ./nginx-rc.yaml
  2. Created my-nginx-v4
  3. Scaling up my-nginx-v4 from 0 to 5, scaling down my-nginx from 4 to 0 (keep 4 pods available, don't exceed 5 pods)
  4. Scaling my-nginx-v4 up to 1
  5. Scaling my-nginx down to 3
  6. Scaling my-nginx-v4 up to 2
  7. Scaling my-nginx down to 2
  8. Scaling my-nginx-v4 up to 3
  9. Scaling my-nginx down to 1
  10. Scaling my-nginx-v4 up to 4
  11. Scaling my-nginx down to 0
  12. Scaling my-nginx-v4 up to 5
  13. Update succeeded. Deleting old controller: my-nginx
  14. replicationcontroller "my-nginx-v4" rolling updated

故障分析

如果更新过程中，达到超时时长timeout后还没更新完成，则更新会失败。这时，一些pod会属于新的replication controller，一些会属于旧的。

如果更新失败，可以尝试使用同样的命令来继续更新过程。

在尝试更新之前如果需要回滚到之前的状态，可在之前的命令后面添加--rollback=true参数，这将回退所有的更改。