当集群中的某个服务需要升级时，我们需要停止目前与该服务相关的所有Pod,然后重新拉取镜像并启动。如果集群规模比较大，则这个工作就变成了一个挑战，而且先全部停止然后逐步升级的方式会导致长时间的服务不可用。Kubernetes提供了rolling-update滚动升级功能来解决上述问题
滚动升级通过执行kubectl rolling-update命令一键完成，该命令创建了一个新的RC，然后自动控制旧的RC中的Pod副本数量逐渐减少到0，同时新的RC中的Pod副本的数量从0逐步增加到目标值，最终实现了Pod的升级。系统会要求新的RC和旧的RC在相同的命名空间下
image_1dnmokndp1bokahk12k2of66nfp.png-116.5kB
创建演示文件
cat >>abcdocker-test.yaml <<EOF apiVersion: apps/v1beta2 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.13.0-alpine imagePullPolicy: IfNotPresent ports: - containerPort: 80 EOF
创建
[root@abcdocker ~]# kubectl apply -f abcdocker-test.yaml --record
已运行的Pod副本数量有3个
[root@abcdocker ~]# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-859fff59fb-488zc 1/1 Running 0 75s nginx-deployment-859fff59fb-b8vwq 1/1 Running 0 75s nginx-deployment-859fff59fb-mzbwt 1/1 Running 0 75s
Kubernetes 更新
更新实际上就是替换镜像版本，有以下几种方式进行更新
① 修改deployment文件进行更新
sed -i 's#1.13.0-alpine#1.10.0-alpine#g' abcdocker-test.yaml kubectl apply -f abcdocker-test.yaml --record
image_1dnnj163ptqm1r24113p12bb1e6q16.png-107.4kB
我们可以看到pod执行过程是等待新的pod启动完成，在进行销毁旧的pod，这样就完成了集群的更新工作
--record的作用是将当前命令记录到 revision 记录中，这样我们就可以知道每个 revison 对应的是哪个配置文件。
② 直接修改deployment进行更新镜像
deployment文件支持动态更新，我们使用edit参数可以直接更新deployment文件
[root@abcdocker ~]# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 14m [root@abcdocker ~]# kubectl edit deployments nginx-deployment deployment.extensions/nginx-deployment edited #再次查看pod的时候已经被更新 [root@abcdocker ~]# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-5fc7b9784f-dq56f 0/1 Pending 0 1s nginx-deployment-5fc7b9784f-r6v9w 1/1 Running 0 45s nginx-deployment-66c45bd65-4f8zn 1/1 Terminating 0 6m47s nginx-deployment-66c45bd65-64zsl 1/1 Running 0 7m22s nginx-deployment-66c45bd65-ktjcd 1/1 Running 0 6m56s
不太推荐使用edit进行编辑，退出即保存，同时也会在我们的rollout里面产生一个版本号
③ 接下来是使用kubectl set命令进行替换镜像
命令格式如下
kubectl set image deployment/SVC_NAME -n namespace_name container_name=images:v1 #注意后面是容器名称，并不是svc名称
本次环境演示
[root@abcdocker ~]# kubectl set image deployment/nginx-deployment nginx=nginx:1.10.1 deployment.extensions/nginx-deployment image updated
回滚
我们使用上面的更新应用时Kubernetes都会记录下当前的配置文件，保存为一个revision (版本)，这样就可以通过这个版本回滚到特定的时间
我们可以通过rollout参数查看当前版本号
#查看revison历史记录 [root@abcdocker ~]# kubectl rollout history deployment nginx-deployment deployment.extensions/nginx-deployment REVISION CHANGE-CAUSE 1 kubectl apply --filename=abcdocker-test.yaml --record=true 2 kubectl apply --filename=abcdocker-test.yaml --record=true 3 kubectl apply --filename=abcdocker-test.yaml --record=true 4 kubectl apply --filename=abcdocker-test.yaml --record=true #nginx-deployment为deployment名称，可以通过kubectl get deployment查看到
我们可以通过kubectl rollout undo 将deployment回滚到指定的版本，这里模拟回滚到第一个版本
默认情况下，如果不加--to-revision=版本号，默认回退到上一个版本
[root@yzsjhl82-135 tmp]# kubectl rollout undo deployment nginx-deployment --to-revision=1 deployment.extensions/nginx-deployment rolled back [root@yzsjhl82-135 tmp]# [root@yzsjhl82-135 tmp]# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-589c48ccfb-c74dk 1/1 Running 0 5m36s nginx-deployment-589c48ccfb-r6nmr 1/1 Running 0 7m7s nginx-deployment-589c48ccfb-wl8x9 1/1 Running 0 6m17s nginx-deployment-859fff59fb-cswks 0/1 ContainerCreating 0 4s
如果我们使用kubectl apply -f xx.yaml不加任何参数，那么在rollout将不会记录任何描述
image_1dnnkcqrapv4fu71rgm1abd1n2l1j.png-120.5kB
如果我们想让rollout里面记录的文件带有版本号，只需要将文件修改一个名称更新时加上--record参数就可以，下面就会显示版本号
[root@abcdocker ~]# cp abcdocker-test.yaml abcdocker-v1.yaml [root@abcdocker ~]# kubectl apply -f abcdocker-v1.yaml --record deployment.apps/nginx-deployment configured [root@abcdocker ~]# kubectl rollout history deployment nginx-deployment deployment.extensions/nginx-deployment REVISION CHANGE-CAUSE 3 kubectl apply --filename=abcdocker-test.yaml --record=true 4 kubectl apply --filename=abcdocker-test.yaml --record=true 5 kubectl apply --filename=abcdocker-test.yaml --record=true 6 kubectl apply --filename=abcdocker-test.yaml --record=true 7 kubectl apply --filename=abcdocker-v1.yaml --record=true
rollout命令参数如下
[root@yzsjhl82-135 tmp]# kubectl rollout -h Manage the rollout of a resource. Valid resource types include: #支持的资源格式 * deployments * daemonsets * statefulsets Examples: # Rollback to the previous deployment kubectl rollout undo deployment/abc # Check the rollout status of a daemonset kubectl rollout status daemonset/foo Available Commands: history 显示 rollout 历史 pause 标记提供的 resource 为中止状态 resume 继续一个停止的 resource status 显示 rollout 的状态 undo 撤销上一次的 rollout 参数使用格式kubectl rollout [XXXX] deployment nginx-deployment
默认配置下，Kubernetes 只会保留最近的几个 revision，可以在 Deployment 配置文件中通过 revisionHistoryLimit 属性增加 revision 数量。
revisionHistoryLimit（历史版本记录）： Deployment revision history存储在它控制的ReplicaSets中。默认保存记录5个 .spec.revisionHistoryLimit 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话，默认所有旧的Replicaset或会被保留，将资源存储在etcd中，是用kubectl get rs查看输出。每个Deployment的该配置都保存在ReplicaSet中，然而，一旦删除的旧的RepelicaSet，Deployment就无法再回退到那个revison了。 如果将该值设置为0，所有具有0个replica的ReplicaSet都会被删除。在这种情况下，新的Deployment rollout无法撤销，因为revision history都被清理掉了。 PS：为了保存版本升级的历史，需要再创建Deployment对象时，在命令中使用"--record"选项
一般配合revisionHistoryLimit使用的strategy (更新策略)
strategy（更新策略）： .spec.strategy 指定新的Pod替换旧的Pod的策略。 .spec.strategy.type 可以是"Recreate"或者是 "RollingUpdate"。"RollingUpdate"是默认值。 Recreate： 重建式更新，就是删一个建一个。类似于ReplicaSet的更新方式，即首先删除现有的Pod对象，然后由控制器基于新模板重新创建新版本资源对象。 rollingUpdate：滚动更新，简单定义 更新期间pod最多有几个等。可以指定maxUnavailable 和 maxSurge 来控制 rolling update 进程。 maxSurge：.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%。 maxUnavailable：.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%。 PS：maxSurge和maxUnavailable的属性值不可同时为0，否则Pod对象的副本数量在符合用户期望的数量后无法做出合理变动以进行更新操作。 在配置时，用户还可以使用Deployment控制器的spec.minReadySeconds属性来控制应用升级的速度。新旧更替过程中，新创建的Pod对象一旦成功响应就绪探测即被认为是可用状态，然后进行下一轮的替换。而spec.minReadySeconds能够定义在新的Pod对象创建后至少需要等待多长的时间才能会被认为其就绪，在该段时间内，更新操作会被阻塞。
这里我提供revisionHistoryLimit和rollingUpdate的yaml文件 (完整yaml如下)
[root@abcdocker ~]# cat abcdocker-test.yaml apiVersion: apps/v1beta2 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 revisionHistoryLimit: 10 selector: matchLabels: app: nginx strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.13.0 imagePullPolicy: IfNotPresent ports: - containerPort: 80
具体参数可以查看上面解释！