河北邢台wap网站建设,郑州网络推广专员,做兼职写小说网站,亚马逊入驻费用及条件本篇主要讨论如何实现滚动更新和回滚#xff0c;任意更换版本并且回滚以前的版本(版本更新)#xff0c;而下一章会讨论到 Pod 缩放#xff0c;根据机器资源自动拓展和收缩应用(自动扩容实例)。本文为作者的 Kubernetes 系列电子书的一部分#xff0c;电子书已经开源#x… 本篇主要讨论如何实现滚动更新和回滚任意更换版本并且回滚以前的版本(版本更新)而下一章会讨论到 Pod 缩放根据机器资源自动拓展和收缩应用(自动扩容实例)。本文为作者的 Kubernetes 系列电子书的一部分电子书已经开源欢迎关注电子书浏览地址https://k8s.whuanle.cn【适合国内访问】https://ek8s.whuanle.cn 【gitbook】滚动更新和回滚部署应用首先我们来部署 nginx使用 nginx 作为练习的镜像。打开 https://hub.docker.com/_/nginx 可以查询 nginx 的镜像版本笔者这里选择三个版本1.19.10、1.20.0、latest后续我们更新和回滚时会在这几个版本之间选择。[Info] 提示需要读者明确选择nginx 的三个不同版本我们后面的升级回滚练习会在这三个版本中来回切换。1.19.10 - 1.20.0 - latest首先我们创建一个 Nginx 的 Deployment副本数量为 3首次部署的时候跟之前的操作一致不需要什么特殊的命令。这里我们使用旧一些的版本笔者使用的是 1.19.0。kubectl create deployment nginx --imagenginx:1.19.0 --replicas3
# 或者
# kubectl create deployment nginx --imagenginx:1.19.0 --replicas3 --record注 我们也可以加上 --record 标志将所执行的命令写入资源注解 kubernetes.io/change-cause 中。这对于以后的检查是有用的。例如要查看针对每个 Deployment 修订版本所执行过的命令对于这个参数的作用我们后面再解释。执行 kubectl get pods、kubectl describe pods可以观察到有有三个 Pod每个 Pod 的 nginx 镜像版本都是 1.19.0。NAME READY STATUS RESTARTS AGE
nginx-85b45874d9-7jlrv 1/1 Running 0 5s
nginx-85b45874d9-h22xv 1/1 Running 0 5s
nginx-85b45874d9-vthfb 1/1 Running 0 5sEvents:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 119s default-scheduler Successfully assigned default/nginx-85b45874d9-vthfb to instance-2Normal Pulled 117s kubelet Container image nginx:1.19.0 already present on machineNormal Created 117s kubelet Created container nginxNormal Started 117s kubelet Started container nginx更新版本其实更新 Pod 是非常简单的我们不需要控制每个 Pod 的更新也不需要担心会不会对业务产生影响K8S 会自动控制这些过程。我们只需要触发镜像版本更新事件K8S 会自动为我们更新所有 Pod 的。kubectl set image 可以更新现有资源对象的容器镜像对象包括 Pod、Deployment、DaemonSet、Job、ReplicaSet。在更新版本中单个容器的 Pod对于多个容器的 Pod 行为是差不多的所以我们使用单容器 Pod 练习即可。更新 Deployment 中的镜像版本触发 Podkubectl set image deployment nginx nginxnginx:1.20.0格式为kubectl set image deployment {deployment名称} {镜像名称}:{镜像名称}:{版本}此命令可以任意修改 Pod 中的其中一个容器的版本只要某个容器的镜像版本变化整个 Pod 都会重新部署。如果镜像版本没有变化即使是执行了 kubectl set image 也不会产生影响。我们可以查看 Pod 的详细信息kubectl describe pods找到 Events 描述... ...
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 66s default-scheduler Successfully assigned default/nginx-7b87485749-rlmcx to instance-2Normal Pulled 66s kubelet Container image nginx:1.20.0 already present on machineNormal Created 66s kubelet Created container nginxNormal Started 65s kubelet Started container nginx可以看到现在现在创建的 Pod 实例为 1.20.0 版本。更新过程中会创建新版本的 Pod旧的 Pod 会被逐渐移除。我们在创建 Deployment 时生成了三个 Pod 而当我们触发镜像版本更新时Pod 不会一次性更新而是按照一定规则每次只重新部署一部分 PodPod 更新替换过程类似下图所示(实际上 Pod 数量可能大于 3个)另外我们还可以通过 kubectl edit yaml 的方式方式更新 Pod。执行kubectl edit deployment nginx然后会弹出编辑 YAML 的界面将 .spec.template.spec.containers[0].image 从 nginx:1.19.0 更改至 nginx:1.20.0然后保存即可。为了记录版本更新信息我们需要在 kubectl create deployment、kubectl set image 命令后面加上 --record。别忘记了 kubectl scale 命令也可以更改副本数量。上线仅当 Deployment Pod 模板即 .spec.template发生改变时例如模板的标签或容器镜像被更新 才会触发 Deployment 上线。其他更新如对 Deployment 执行扩缩容的操作不会触发上线动作Deployment 的上线动作可以为我们更新 Pod 的版本(Pod 中的容器版本)。这里提到的 上线/更新版本 是因为容器版本会发生变化而更新一般指修改了 YAML 等不一定会对容器产生影响。当我们更新 Pod 版本时K8S 会自动负载均衡而不是把所有 pod 删除再重新创建新版本 Pod它会以稳健的方式逐渐替换 Pod 副本所以叫滚动更新。我们可以通过 kubectl rollout status 命令查看 Pod 的上线状态即 Pod 副本集的更替状态kubectl rollout status deployment nginx输出结果一般有两种# 已经完成时
deployment nginx-deployment successfully rolled out
# 还在更新时
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...我们也可以通过获取 Deployment 信息时查看已更新的 pod 数量kubectl get deploymentNAME READY UP-TO-DATE AVAILABLE AGE
nginx 3/3 3 3 18mUP-TO-DATE 字段可以看到成功更新的 pod 数量。还可以查看 ReplicaSet 和 Podkubectl get replicaset
kubectl get pods输出类型NAME DESIRED CURRENT READY AGE
nginx-7b87485749 0 0 0 20m
nginx-85b45874d9 3 3 3 21mNAME READY STATUS RESTARTS AGE
nginx-85b45874d9-nrbg8 1/1 Running 0 12m
nginx-85b45874d9-qc7f2 1/1 Running 0 12m
nginx-85b45874d9-t48vw 1/1 Running 0 12m可以看到有两个 ReplicaSetnginx-7b87485749 是 1.19.0 版本已经被全部更新到 1.20.0 版本 了所以前者的数量为 0我们也可以看到 Pod 中所有 Pod 都是以 nginx-85b45874d9 作为前缀的。这几个关键信息我们可以截图后面再次对照。如何滚动更新我们更新 镜像版本时旧的 Pod 版本会被替换但是 ReplicaSet 副本记录是不会被删除的。实际上滚动更新就是控制副本数量原本 1.19.0 的副本数量为 3现在变成 01.20.0 的副本数量变成 3 。如果我们的项目上线了我们更新软件版本如果一次性更新所有容器或者 pod那么我们的软件会有一段时间处于不可用状态直到所有 Pod 都完成更新。Deployment 可确保在更新时仅关闭一定数量的 Pod默认情况下它确保至少所需 Pods 75% 处于运行状态也就是说正在被更新的 Pod 比例不超过 25%。当然只有两三个 pod 的 Deployment 不会按照这个比例限定。也就是说Deployment 等处于滚动更新状态时其始终可以保证有可用的 Pod 提供服务。如果我们的 Pod 数量足够大或者在更新 Deployment 时迅速输出上线状态可以看到新旧的 Pod 数量加起来不一定就是 3 个因为它不会杀死老 Pods直到有足够的数量新的 Pods 已经出现。在足够数量的旧 Pods 被杀死前并没有创建新 Pods。当副本数量为3个时它确保至少 2 个 Pod 可用同时 最多总共 4 个 Pod 存在(不同版本)。滚动更新过程如下图所示Deployment 确保仅所创建 Pod 数量只可能比期望 Pods 数高一点点。默认情况下它可确保启动的 Pod 个数比期望个数最多多出 25%最大峰值 25%所以在自动更新 Deployment 时观察到的 pod 可能为 4个这是由 Deployment 的缩放配置决定的(下一章讲解)。另外在 Deployment 更新时除了可以更改镜像的版本也可以更改 ReplicaSet 的数量。执行 kubectl describe deployment nginx 查看 Deployment 详细信息我们查看 Event 字段也可以观察到新旧 Pod 的更替过程。但是这些原理等知识我们都不需要记也不需要深入我们记得有这回事就行有需要的时候也可以直接查看文档的后面的章节还会详细介绍 ReplicaSet 的规则。查看上线记录默认情况下 Deployment 的上线记录都会保留在系统中以便可以随时回滚前面我们也提到了查看 kubectl get replicasets 时出现的副本记录。我们查看 Deployment 的上线历史记录kubectl rollout history deployment nginxREVISION CHANGE-CAUSE
1 none
2 none# 带 --record 的话输出是
REVISION CHANGE-CAUSE
2 kubectl set image deployment nginx nginxnginx:1.20.0 --recordtrue可以看到有两个版本但是CHANGE-CAUSE 为 none 呢这是因为笔者没有使用 --record 参数记录信息如果没带上 --record 的话我们看着这个历史记录完全分不出到底是什么版本。现在我们查看 版本2 的详细信息kubectl rollout history deployment nginx --revision2deployment.apps/nginx with revision #2
Pod Template:Labels: appnginxpod-template-hash85b45874d9Containers:nginx:Image: nginx:1.20.0Port: noneHost Port: noneEnvironment: noneMounts: noneVolumes: none回滚当部署的新版本程序发现严重 bug 影响平台稳定性时你可能需要将项目切换为上一个版本。目前介绍了几个查看 Deployment 上线的历史记录的命令下面介绍如果将 Pod 换到旧的版本。回滚到上一个版本的命令rootmaster:~# kubectl rollout undo deployment nginx
deployment.apps/nginx rolled back例如当前是 版本2那么会回滚到 版本1。再执行 kubectl rollout history deployment nginx 会发现 revision 变成 3 了。rootmaster:~# kubectl rollout history deployment nginx
deployment.apps/nginx
REVISION CHANGE-CAUSE
2 none
3 nonerevision 记录的是部署记录与 Pod 的镜像版本无关每次更新版本或进行回滚等操作时 revision 会自动递增 1。如果版本数量多了我们还可以指定回滚到特点的版本。kubectl rollout undo deployment nginx --to-revision2这里提一下 --record在前面我们创建和更新 Deployment 时都没有使用到这个参数其实这个参数很有用的接下来我们每次执行滚动更新时都要带上这个参数才行。更新镜像到指定版本kubectl set image deployment nginx nginxnginx:1.19.0 --recordkubectl rollout history deployment nginx输出REVISION CHANGE-CAUSE
5 none
6 kubectl set image deployment nginx nginxnginx:1.19.0 --recordtrue但是我们这里目前来说只有两个记录我们明明提交了多次虽然 revision 会变化但是这里查询的只有两条记录这时因为我们操作的时候只用到了 1.19.0、1.20.0 两个版本所以也就只有这两个版本的提交记录。多用几个版本输出结果REVISION CHANGE-CAUSE
7 kubectl set image deployment nginx nginxnginx:1.19.0 --recordtrue
8 kubectl set image deployment nginx nginxnginx:1.20.0 --recordtrue
9 kubectl set image deployment nginx nginxnginx:latest --recordtrueREVISION 字段的数字是会递增的当我们触发上线动作(容器标签、版本等)时会产生新的上线记录。暂停上线本小节需要水平缩放、比例缩放等知识请先阅读 3.6 章关于缩放的内容。如果在上线过程中发现机器不够用了或者需要调整一些配置等可以暂停上线过程。kubectl rollout pause 命令可以让我们在 Deployment 的 Pod 版本时暂停滚动更新。命令kubectl rollout pause deployment nginx在滚动更新过程中会有一些现象需要我们留意。先创建一个 Deployment 或者更新 Deployment 的 Pod 为 10 个副本。kubectl create deployment --imagenginx:1.19.0 --replicas10我们执行 kubectl edit deployment nginx 修改缩放个数strategy:rollingUpdate:maxSurge: 3maxUnavailable: 2type: RollingUpdate设置了这个 maxSurge 和 maxUnavailable可以让 Deployment 替换 Pod 时慢一些。之前我们已经使用了 1.19.0、1.20.0 两个版本进行演示这里我们使用 latest 版本进行实践。复制以下两条命令快速执行可以快速卡住上线过程。我们暂停上线后查看一些状态信息。kubectl set image deployment nginx nginxnginx:latest
kubectl rollout pause deployment nginx执行 kubectl get replicaset 查看这些版本的数量。NAME DESIRED CURRENT READY AGE
nginx-7b87485749 8 8 8 109m
nginx-85b45874d9 0 0 0 109m
nginx-bb957bbb5 5 5 5 52m可以看到所有的 Pod 加起来数量大于 10旧容器以每次 2 个的数量减少新容器以每次 3 个的数量创建暂停上线后多次执行 kubectl get replicaset 会发现副本数量不会变化。前面我们已经暂停了上线如果我们执行上线命令换成别的版本kubectl set image deployment nginx nginxnginx:1.19.0会发现虽然提示更新了但是实际上没有变化。执行 kubectl rollout history deployment nginx 也查不到我们提交的 1.19.0 的请求。这是因为在已经暂停上线的控制器对象中执行新的上线动作是无效的。暂停的时候我们可以更新一些配置例如限制 Pod 中的 nginx 容器使用的 CPU 和 资源kubectl set resources deployment nginx -cnginx --limitscpu200m,memory512Mi再恢复 Deployment 上线kubectl rollout resume deployment nginx
