Kubernetes 实战——升级应用（Deployment）

摘要

将导致应用程序在一定时间内不可用需要同时运行两倍的 Pod应用程序需支持两个版本同时对外提供服务

一、更新运行在 Pod 内的应用程序

1. 修改 Pod 模板

将导致应用程序在一定时间内不可用

2. 修改 Service 的 Pod 选择器

需要同时运行两倍的 Pod

3. 滚动升级

应用程序需支持两个版本同时对外提供服务

旧版本 ReplicationController 缩容，同时新版本扩容

通过新旧 ReplicationController 副本数的改变，逐渐将所有 Pod 替换成新版本，结束后删除原有的 ReplicationController

二、使用 Deployment

用于部署应用程序，并以声明的方式升级应用

创建 Deployment 时自动创建 ReplicaSet，Pod 由 ReplicaSet 创建和管理

1. 创建 Deployment

定义类似于 ReplicationController。但能指定部署策略：在修改 Deployment 资源时如何执行更新

apiVersion: apps/v1 kind: Deployment metadata:   name: kubia spec:   replicas: 3   selector:     matchLabels:       app: kubia   template:     metadata:       name: kubia       labels:         app: kubia     spec:       containers:       - image: luksa/kubia:v1         name: nodejs 

# --record：记录历史版本号 $ kubectl create -f kubia-deployment-v1.yaml --record # 查看部署状态 $ kubectl rollout status deployment kubia deployment "kubia" successfully rolled out # 查看部署的资源 $ kubectl get all NAME                    READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/kubia   3/3     3            3           3m34s  NAME                               DESIRED   CURRENT   READY   AGE replicaset.apps/kubia-59d857b444   3         3         3       3m34s  NAME                         READY   STATUS    RESTARTS   AGE pod/kubia-59d857b444-4c7v8   1/1     Running   0          3m34s pod/kubia-59d857b444-7r76k   1/1     Running   0          3m34s pod/kubia-59d857b444-lrjtp   1/1     Running   0          3m34s 

• ReplicaSet 创建的 Pod 名称是由 ReplicaSet 名称加上运行时生成的随机字符串组成的
• Deployment 创建的 ReplicaSet 包含 Pod 模板的哈希值

2. 升级 Deployment

只需修改 Deployment 资源中定义的 Pod 模板，K8s 会自动将系统状态收敛到定义的状态

升级策略：

• RollingUpdate：滚动更新。默认策略
  • 渐进删除旧 Pod，同时创建新 Pod
  • Pod 数量会浮动，其上下限可配置
• Recreate：一次性删除所有旧 Pod，之后创建新 Pod
  • 适用：系统不支持多个版本同时对外提供服务。但会出现短暂不可用

演示 RollingUpdate

# 1. 减慢滚动升级速度 # kubectl patch 常用于修改单个或少量资源属性，无需编辑器编辑 $ kubectl patch deployment kubia -p '{"spec": {"minReadySeconds": 10}}' # 因为 Pod 模板没变，故不会触发滚动升级  # 2. 触发滚动升级 # 指定新的镜像（可设置任何包含容器的资源） $ kubectl set image deployment kubia nodejs=luksa/kubia:v2  # 3. 查看滚动升级 $ while true; do curl 10.109.157.15; done # 可以看到刚开始请求 v1，后来慢慢全部切换到 v2 

升级过程由 Deployment 控制器完成。流程为：创建新的 ReplicaSet 然后扩容，同时之前的 ReplicaSet 会缩容至 0。旧的 ReplicaSet 仍被保留

若 Deployment 的 Pod 模板引用了 ConfigMap/Secret，更改 ConfigMap/Secret 资源本身不会触发升级操作

若想触发更新可创建新的 ConfigMap/Secret 并修改模板引用

3. 回滚 Deployment

使用新镜像

# v3 版本请求 5 次后会出错 $ kubectl set image deployment kubia nodejs=luksa/kubia:v3 # 查看整个升级过程 $ kubectl rollout status deployment kubia # 模拟应用出错 $ while true; do curl 10.109.157.15; done 

回滚

# 回滚到先前版本 $ kubectl rollout undo deployment kubia # 显示升级的版本（历史版本号会被保存到 ReplicaSet 中） $ kubectl rollout history deployment kubia deployment.apps/kubia  REVISION  CHANGE-CAUSE  # 若不指定 --record，CHANGE-CAUSE 会为空 1         kubectl create --filename=kubia-deployment-v1.yaml --record=true 3         kubectl create --filename=kubia-deployment-v1.yaml --record=true 4         kubectl create --filename=kubia-deployment-v1.yaml --record=true # 回滚到指定版本 $ kubectl rollout undo deployment kubia --to-revision=1 

undo 也可以在滚动升级过程中运行：停止升级并删除已创建 pod

可通过指定 Deployment 的 revisionHistoryLimit 来限制历史版本数量，默认 10

4. 控制滚动升级速率

spec:   strategy:     rollingUpdate:       maxSurge: 1       maxUnavailable: 1     type: RollingUpdate 

• maxSurge：决定 Deployment 配置中期望的副本数之外，最多允许超出的 Pod 实例数量。默认值为 25%（四舍五入）
• maxUnavailable：决定在滚动升级期间，相对于期望副本数能够允许多少 Pod 实例处于不可用状态。默认值为 25%（四舍五入）

本例中，replicas=3，因此 Pod 数最多可达到 4 且必须有 2 个 Pod 可用

5. 暂停滚动升级

只升级部分，方便用户验证新版本 Pod

kubectl set image deployment kubia nodejs=luksa/kubia:v4 kubectl rollout pause deployment kubia # 这样会创建一个（数量不可控）新的 Pod # 若部署被暂停，在恢复部署之前，撤销命令不会撤销它 

恢复滚动升级

kubectl rollout resume deployment kubia 

暂停功能还可用于阻止更新 Deployment 后的自动升级行为。可更改多次，完成更改后再升级

6. 滚动升级前检查

minReadySeconds 属性主要是避免部署出错版本的应用，而不是单单减缓部署的速度。它指定新创建的 Pod 至少要成功运行多久之后，才能将其视为可用。在 Pod 可用前，滚动升级的过程不会继续

当容器的所有就绪探针都返回成功时，Pod 被标记为就绪状态。Pod 就绪后等待 minReadySeconds 后才可用，才继续滚动升级

apiVersion: apps/v1 kind: Deployment metadata:   name: kubia spec:   # 更新可以不用加 replicas   selector:     matchLabels:       app: kubia   minReadySeconds: 10   strategy:     rollingUpdate:       maxSurge: 1       maxUnavailable: 0  # 挨个替换     type: RollingUpdate   template:     metadata:       name: kubia       labels:         app: kubia     spec:       containers:       - image: luksa/kubia:v3         name: nodejs         readinessProbe:           periodSeconds: 1  # 1s 执行一次就绪探针           httpGet:  # 探针发送的请求             path: /             port: 8080 

kubectl apply -f kubia-deployment-v3.yaml 

默认 10min（spec.progressDeadlineSeconds）内不能完成滚动升级就视为失败，滚动升级会自动取消

可通过 rollout undo 取消滚动升级

---

---

修改资源的不同方式

方法	作用	例子
kubectl edit	使用默认编辑器打开资源配置	kubectl edit pod test
kubectl patch	修改单个资源属性	kubectl patch pod test -p '{"spec": {"replicas": 4}}'
kubectl apply	通过 YAML/JSON 文件修改或创建资源	kubectl apply -f test.yaml
kubectl replace	通过 YAML/JSON 文件修改资源（资源需存在）	kubectl replace -f test.yaml
kubectl set image	修改包含容器资源的镜像	kubectl set image pod test nodejs=kubia:v2

镜像拉取策略

• 若更改后的镜像推到相同的 tag，会导致镜像不被重新拉取。可设置容器的 imagePullPolicy 为 Always
• 若容器使用 latest 的 tag，则 imagePullPolicy 默认为 Always，否则为 IfNotPresent

命令

kubectl delete pod --all kubectl set selector ... # 提高日志级别，输出所有 kubectl 发起的 API 服务器请求 kubectl ... --v 6