k8s 中的更新策略,版本回滚,金丝雀发布操作

导读:本篇文章讲解 k8s 中的更新策略,版本回滚,金丝雀发布操作,希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com

一、更新策略

1.滚动更新策略

滚动升级策略会允许集群存在新旧版本,可能会对应用存在服务访问问题;

注意点:

Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源,而是将它们分置于两个不同的控制器之下:旧控制器的Pod对象数量不断减少的同时,新控制器的Pod对象数量不断增加,直到旧控制器不再拥有Pod对象,而新控制器的副本数量变得完全符合期望值为止;
maxUnavailable:表示最大不可用pod数量,可以是整数或者百分比;
maxSurge:表示可超过预期值的pod数量,可以是整数或者百分比;
为了保存版本升级的历史,需要在创建Deployment对象时于命令中使⽤“–record”选项。“kubectl apply -f myapp-deploy.yaml –record”;
适用情况:一些无状态应用,允许多个版本存在访问,需要快速回滚;

2.重建策略

重建策略会在创建新策略之前删除所有现有容器集,Kubernetes 先终止当前版本中的所有容器,然后在旧容器删除时同时启动所有新容器,不会有 2 种版本容器同时运行,这对服务使用者来说更简单

一般建议在开发环境使用该策略;

3.蓝绿发布(通过修改label,或者是结合istio)

4.金丝雀发布9(通过修改label,或者是结合istio)

二、版本回滚

查看历史记录

kubectl rollout history deployment nginx

回滚到上一个版本

kubectl rollout undo deployment nginx

也可以使用 –revision参数指定某个历史版本:

 kubectl rollout undo deployment nginx  --to-revision=3

三、金丝雀发布

金丝雀发布(又称灰度发布、灰度更新):
金丝雀发布一般是先发1台机器,或者一个小比例,例如2%的服务器,主要做流量验证用,也称为金丝雀 (Canary) 测试,国内常称灰度测试。以前旷工下矿前,会先放一只金丝雀进去用于探测洞里是否有有毒气体,看金丝雀能否活下来,金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证,复杂的金丝雀测试需要比较完善的监控基础设施配合,通过监控指标反馈,观察金丝雀的健康状况,作为后续发布或回退的依据。如果金丝测试通过,则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败,则直接回退金丝雀,发布失败。

发布的各种策略详细介绍参考:蓝绿、ABTest、滚动部署、灰度发布、金丝雀发布介绍

实战

需要更新的应用

[root@k8s-master1 ~]# cat nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.7
        name: nginx

1、打开一个命令行,来监测更新过程

kubectl get pods -l app=nginx -n test -w
## 下面命令执行完之后显示如下,之前的pod还在,新创建了一个pod,没有立即删除。

(也可以使用kubectl rollout statusdeployment myapp-deploy,显示Waiting for deployment “myapp-deploy”rollout to finish: 1 out of 5 new replicas have been updated)

打开另一个命令行来操作,如下:

1、更新镜像,并暂停升级

kubectl set image deployment nginx nginx=nginx:1.8 -n test --record=true && kubectl rollout pause deployment nginx -n test

–record=true 每次更新应用时 Kubernetes 都会记录下当前的配置
注:上面的步骤解释说明

把myapp这个容器的镜像更新到myapp:v2版本,更新镜像之后,创建一个新的pod就立即暂停,这就是我们说的金丝雀发布;如果暂停几个小时之后没有问题,那么取消暂停,就会依次执行后面步骤,把所有pod都升级。

2、解除暂停
在这里插入图片描述

确认新版本没问题,则解除暂停

kubectl rollout resume deployment nginx -n test

在刚才监测的界面可以看到如下一些信息,下面过程是把余下的pod里的容器都更新到新的版本:

[root@k8s-master1 ~]# kubectl get pods -l app=nginx -n test -w
NAME                    READY   STATUS    RESTARTS   AGE
nginx-8fd4b9765-5j2v2   1/1     Running   0          98s
nginx-8fd4b9765-chd5x   1/1     Running   0          97s
nginx-8fd4b9765-xc8dr   1/1     Running   0          99s

nginx-58d48b746d-9j6kv   0/1     Pending   0          0s
nginx-58d48b746d-9j6kv   0/1     Pending   0          0s
nginx-58d48b746d-9j6kv   0/1     ContainerCreating   0          0s
nginx-58d48b746d-9j6kv   1/1     Running             0          1s
nginx-8fd4b9765-chd5x    1/1     Terminating         0          118s
nginx-58d48b746d-9xcrt   0/1     Pending             0          0s
nginx-58d48b746d-9xcrt   0/1     Pending             0          0s
nginx-58d48b746d-9xcrt   0/1     ContainerCreating   0          0s
nginx-8fd4b9765-chd5x    0/1     Terminating         0          119s
nginx-58d48b746d-9xcrt   1/1     Running             0          2s
nginx-8fd4b9765-5j2v2    1/1     Terminating         0          2m1s
nginx-58d48b746d-87x58   0/1     Pending             0          0s
nginx-58d48b746d-87x58   0/1     Pending             0          0s
nginx-58d48b746d-87x58   0/1     ContainerCreating   0          0s
nginx-58d48b746d-87x58   1/1     Running             0          0s
nginx-8fd4b9765-xc8dr    1/1     Terminating         0          2m2s
nginx-8fd4b9765-5j2v2    0/1     Terminating         0          2m2s
nginx-8fd4b9765-xc8dr    0/1     Terminating         0          2m3s
nginx-8fd4b9765-5j2v2    0/1     Terminating         0          2m3s
nginx-8fd4b9765-5j2v2    0/1     Terminating         0          2m3s
nginx-8fd4b9765-chd5x    0/1     Terminating         0          2m2s
nginx-8fd4b9765-chd5x    0/1     Terminating         0          2m2s

可以看到replicaset控制器有2个了

回滚
如果发现刚才升级的这个版本有问题可以回滚,查看当前有哪几个版本:

kubectl rollout history deployment nginx -n test

上面可以看到第一版没了,被还原成了第三版,第三版的前一版是第二版

kubectl get rs -n test -o wide

可以看到上面的rs已经用第一个了,这个就是还原之后的rs

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由半码博客整理,本文链接:https://www.bmabk.com/index.php/post/75660.html

(0)

相关推荐

半码博客——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!