(K8s学习笔记七)Pod的升级和回滚

1.Deployment的升级

示例:滚动升级busybox-deployment容器

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: busybox: 1.7

# 查看busybox容器副本数量
kubectl get pods 

# 使用以下命令更新busybox到1.9版
kubectl set image deployment/busybox-deployment busybox=busybox:1.9
或者kubectl edit编辑bosybox的deployment文件将image 1.7改为1.9,修改后会自
动出发Pod滚动升级

# 查看更新过程
kubectl rollout status deployment/busybox-deployment

Deployment的更新策略包括:

1)Recreate:设置spec.strategy.type=Recreate,表示在更新Pod时会先杀掉所有正好运行的Pod,然后创建新的Pod

2)RollingUpdate:设置spec.strategy.type=RollingUpdate,表示Pod会以滚动升级的方式逐个更新,此为默认值,其中

spec.strategy.rollingUpdate.maxUnavilable指定更新过程中不可用状态的Pod的数量上限,如设置为30%,则更新过程中确保运行的Pod总数至少占Pod期望副本总数的70%。

spec.strategy.rollingUpdate.maxSurge:用于指定更新过程中Pod总数超过Pod期望副本数部分的最大值,如设为30%,则新的ReplicaSet可以在滚动更新开始时立即进行副本扩容,只需保证新旧ReplicaSet的Pod副本数之和不超过期望副本数的130%即可,一旦旧的Pod被杀掉,新的ReplicaSet就会进一步扩容。

 2.Deployment的回滚

# 使用kubectl rollout history命令查看deployment部署记录
kubectl rollout history deployment/nginx-deployment

# 查看特定版本的详细信息,加上revision=<N>参数
kubectl rollout history deployment/nginx-deployment --revision=3

# 回滚到ngin-deploymment上一个部署版本
kubectl rollout undo deployment/nginx-deployment

# 使用--to-revision回滚到指定部署版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2

 3.暂停和恢复Deployment的部署操作

对于一次复杂的Deployment配置修改,为了避免频繁触发Deployment的更新操作,可先暂停Deployment的更新操作,待修改完成后再恢复

# 通过kubectl rollout pause命令暂定deployment更新操作
kubectl rollout pause deployment/nginx-deployment

# 做更新image版本和容器资源操作
kubectl set image deployment/nginx-deployment nginx=nginx:1.10.1
kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=768Mi

# 恢复Deployment的部署操作
kubectl rollout resume deployment/nginx-deployment

 4.RC的滚动升级

使用kubectl rolling-update命令进行RC的滚动升级,升级时系统要求新的RC与旧的RC必须在相同的namespace里

# 使用nginx-rc-rollout-v1.17.yaml升级到1.17版,旧版本时1.15版
apiVersion: v1 
kind: ReplicatonController
metadata:
  name: nginx-rc-v1.17   # RC的name不能与旧版本相同
  labels:
    name: nginx-rc
    version: v1.17
spec:
  replicas: 1
  selector:                # selector中至少有一个version与旧版中的不同
    name: nginx-rc
    version: v1.17         
  template:
    metadata:
      labels:
        name: nginx-rc
        version: v1.17
    spec:
      containers:
      - name: nginx
        image: nginx:1.17
        ports:
        - containerPort: 80

# 执行命令滚动升级nginx-rc
kubectl rolling-update nginx-rc -f nginx-rc-rollout-v1.17.yaml
或者
# 直接使用命令更新
kubectl rolling-update nginx-rc --image=nginx:1.17
注:使用命令升级后新RC仍使用旧RC的name

# 如果在更新过程中发现配置有误,则可中断更新,执行以下命令回滚
kubectl rolling-update nginx-rc --image=nginx:1.17 --rollback 

RC的滚动升级不具有Deployment在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能。

5.DaemonSet的更新策略

DaemonSet包含两种升级策略:

1)OnDelete:默认的升级策略,使用此策略,在创建好新的DaemonSet配置之后,新的Pod并不会被自动创建,直到用户手动删除旧Pod才会出发新建操作

2)RollingUpdate:使用此策略更新时,旧版的Pod将被自动杀掉,然后自动创建新版的Pod,整改过程与普通Deployment的滚动升级一样可控,但回滚时不能通过kubectl rollback命令完成,必须通过再次提交旧版本配置的方式实现

要启用DaemonSet的滚动更新特性,必须将其spec.updateStrategy.type设置为RollingUpdate。
还可以设置spec.updateStrategy.rollingUpdate.maxUnavailable(默认值为1)和spec.minReadySeconds(默认值为0)

6.StatefulSet的更新策略

更新策略向Deployment和DaemonSet的策略看齐,也可使用RollingUpdate、Paritioned和OnDelete策略。

一入运维深似海,从此不见彼岸花
原文地址:https://www.cnblogs.com/cn-jasonho/p/13346024.html