Kubernetes Pod升级与回滚

当集群中的某个服务需要升级时，我们需要停止目前与该服务相关的所有Pod，然后下载新版本镜像并创建新的Pod。如果集群规模比较大，则这个工作变成了一个挑战，而且先全部停止然后逐步升级的方式会导致较长时间的服务不可用。Kubernetes提供了滚动升级功能来解决上述问题。如果在更新过程中发生了错误，则还可以通过回滚操作恢复Pod的版本。

Deployment升级

现有如下deployment定义（nginx-deployment.yml）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      name: nginx
  replicas: 3
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

创建该deployment：

通过kubectl命令将nginx的版本更新到1.9.1：

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

查看滚动升级的过程：

查看Pod，会发现名称已经改变了：

上述滚动升级的过程可以用下图表示：

查看Deployment nginx-deployment的详细事件信息可以证明这一点：

1	kubectl describe deployments/nginx-deployment

查看rs：

默认的升级策略为RollingUpdate（滚动更新），Kubernetes还支持Recreate（重建）策略：

Recreate：先杀掉所有正在运行的Pod，然后创建新的Pod。
RollingUpdate：以滚动更新的方式来逐个更新Pod。同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程。

RollingUpdate的两个参数含义如下：

maxUnavailable：用于指定Deployment在更新过程中不可用状态的Pod数量的上限。该maxUnavailable的数值可以是绝对值（例如1）或Pod期望的副本数的百分比（例如10%）。
maxSurge：用于指定在Deployment更新Pod的过程中Pod总数超过Pod期望副本数部分的最大值。该maxSurge的数值可以是绝对值（例如5）或Pod期望副本数的百分比（例如10%）。

此外，除了使用kubectl命令升级外，我们也可以直接通过修改deployment.yml的方式来完成。

Deployment回滚

如果升级后效果不满意的话，我们也可以将Deployment回滚到升级之前，使用下面这条命令查看滚动升级的历史：

1	kubectl rollout history deployment/nginx-deployment

REVISION为升级的历史版本，我们只完成了nginx从1.7.9升级到1.9.1的过程，所以REVISION 1表示nginx为1.7.9的版本，REVISION 2表示nginx为1.9.1的版本。因为我们在创建deployment的时候没有加上--record=true参数，所以CHANGE-CACSE列是空的。

需要查看特定版本的详细信息，则可以加上–revision=参数：