k8s升级回滚滚动更新详解！！上线之后的重点！！

最新推荐文章于 2024-06-19 16:16:28 发布

yuezhilangniao

最新推荐文章于 2024-06-19 16:16:28 发布

阅读量1.7k

点赞数

分类专栏： k8s-docker-service-mesh 文章标签： kubernetes

原文链接：https://www.jianshu.com/p/7411d15215b5

版权

k8s-docker-service-mesh 专栏收录该内容

138 篇文章 9 订阅

订阅专栏

一基础知识

https://zhuanlan.zhihu.com/p/90282741

扩展命令：

对于已经发布的服务。如何做到在线更新呢？
总结有这么几种办法：
kubectl annotate， kubectl edit， kubectl replace， kubectl scale，和 kubectl apply。

三个命令都可以实现更新镜像 # 先将三个主要命令 apply edit set-image
① 修改deployment文件进行更新

sed -i 's#1.13.0-alpine#1.10.0-alpine#g' abcdocker-test.yaml
kubectl apply -f abcdocker-test.yaml --record

# --record的作用是将当前命令记录到 revision 记录中，这样我们就可以知道每个 revison 对应的是哪个配置文件。
如果我们使用kubectl apply -f xx.yaml不加任何参数，那么在rollout将不会记录任何描述！！！

② 直接修改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

③ 接下来是使用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

回滚命令：

kubectl rollout history deployment nginx-deployment # 查看历史

kubectl rollout undo deployment nginx-deployment --to-revision=1 # 如果不加--to-revision=版本号，默认回退到上一个版本

二高级配置

设置滚动刚更新的策略和保留pod数量 https://www.jianshu.com/p/7411d15215b5

附录本文演示nginx deploy yaml：

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

三升级参数解释

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对象创建后至少需要等待多长的时间才能会被认为其就绪，在该段时间内，更新操作会被阻塞。

升级的标准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% # 默认不可用为1
    type: RollingUpdate # 默认策略
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.13.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80