经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Linux/Shell » 查看文章
Kubernetes 实战——升级应用(Deployment)
来源:cnblogs  作者:LB477  时间:2021/6/21 10:00:30  对本文有异议

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

1. 修改 Pod 模板

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

2. 修改 Service 的 Pod 选择器

需要同时运行两倍的 Pod

3. 滚动升级

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

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

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

二、使用 Deployment

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

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

1. 创建 Deployment

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

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: kubia
  5. spec:
  6. replicas: 3
  7. selector:
  8. matchLabels:
  9. app: kubia
  10. template:
  11. metadata:
  12. name: kubia
  13. labels:
  14. app: kubia
  15. spec:
  16. containers:
  17. - image: luksa/kubia:v1
  18. name: nodejs
  1. # --record:记录历史版本号
  2. $ kubectl create -f kubia-deployment-v1.yaml --record
  3. # 查看部署状态
  4. $ kubectl rollout status deployment kubia
  5. deployment "kubia" successfully rolled out
  6. # 查看部署的资源
  7. $ kubectl get all
  8. NAME READY UP-TO-DATE AVAILABLE AGE
  9. deployment.apps/kubia 3/3 3 3 3m34s
  10. NAME DESIRED CURRENT READY AGE
  11. replicaset.apps/kubia-59d857b444 3 3 3 3m34s
  12. NAME READY STATUS RESTARTS AGE
  13. pod/kubia-59d857b444-4c7v8 1/1 Running 0 3m34s
  14. pod/kubia-59d857b444-7r76k 1/1 Running 0 3m34s
  15. 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. # 1. 减慢滚动升级速度
  2. # kubectl patch 常用于修改单个或少量资源属性,无需编辑器编辑
  3. $ kubectl patch deployment kubia -p '{"spec": {"minReadySeconds": 10}}'
  4. # 因为 Pod 模板没变,故不会触发滚动升级
  5. # 2. 触发滚动升级
  6. # 指定新的镜像(可设置任何包含容器的资源)
  7. $ kubectl set image deployment kubia nodejs=luksa/kubia:v2
  8. # 3. 查看滚动升级
  9. $ while true; do curl 10.109.157.15; done
  10. # 可以看到刚开始请求 v1,后来慢慢全部切换到 v2

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

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

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

3. 回滚 Deployment

使用新镜像

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

回滚

  1. # 回滚到先前版本
  2. $ kubectl rollout undo deployment kubia
  3. # 显示升级的版本(历史版本号会被保存到 ReplicaSet 中)
  4. $ kubectl rollout history deployment kubia
  5. deployment.apps/kubia
  6. REVISION CHANGE-CAUSE # 若不指定 --record,CHANGE-CAUSE 会为空
  7. 1 kubectl create --filename=kubia-deployment-v1.yaml --record=true
  8. 3 kubectl create --filename=kubia-deployment-v1.yaml --record=true
  9. 4 kubectl create --filename=kubia-deployment-v1.yaml --record=true
  10. # 回滚到指定版本
  11. $ kubectl rollout undo deployment kubia --to-revision=1

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

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

4. 控制滚动升级速率

  1. spec:
  2. strategy:
  3. rollingUpdate:
  4. maxSurge: 1
  5. maxUnavailable: 1
  6. type: RollingUpdate
  • maxSurge:决定 Deployment 配置中期望的副本数之外,最多允许超出的 Pod 实例数量。默认值为 25%(四舍五入)
  • maxUnavailable:决定在滚动升级期间,相对于期望副本数能够允许多少 Pod 实例处于不可用状态。默认值为 25%(四舍五入)

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

5. 暂停滚动升级

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

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

恢复滚动升级

  1. kubectl rollout resume deployment kubia

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

6. 滚动升级前检查

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

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

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4. name: kubia
  5. spec:
  6. # 更新可以不用加 replicas
  7. selector:
  8. matchLabels:
  9. app: kubia
  10. minReadySeconds: 10
  11. strategy:
  12. rollingUpdate:
  13. maxSurge: 1
  14. maxUnavailable: 0 # 挨个替换
  15. type: RollingUpdate
  16. template:
  17. metadata:
  18. name: kubia
  19. labels:
  20. app: kubia
  21. spec:
  22. containers:
  23. - image: luksa/kubia:v3
  24. name: nodejs
  25. readinessProbe:
  26. periodSeconds: 1 # 1s 执行一次就绪探针
  27. httpGet: # 探针发送的请求
  28. path: /
  29. port: 8080
  1. 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

命令

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

原文链接:http://www.cnblogs.com/lb477/p/14893646.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号