提供了编程的基础技术教程

zl程序教程

您现在的位置是：首页 >  后端

当前栏目

k8s 发布策略 AB 蓝绿 金丝雀 滚动更新 灰度

k8s 发布 更新 策略 滚动 灰度 AB
2023-09-11 14:20:30 时间

大部分公司都已经在使用 Kubernetes 进行容器管理和编排了，但是关于 Kubernetes 的发布策略相关的概括我们很多同学还没有一个完整的认识，下面我们对 Kubernetes 的多种发布策略从整体上做一个概括的认识。Kubernetes 中常见的发布策略主要有如下六种：

重建（recreate) ：即停止一个原有的容器，然后进行容器的新建。

注意：重建这种策略缺点是十分明显的，当服务停止之后再创建新的服务。服务什么时候启动，也是根据服务启动时间决定的。

------------------------------------------------------

滚动更新（rollingUpdate) ：停掉一个容器，然后更新一个容器。

1. 准备一个新版本的 POD，比如新版本为 V2，旧版本为 V1。

2. 当 V2 版本的 POD 准备好后，在负载均衡中的实例池中将 V2 的版本加入。

3. 在实例池中剔除一个 V1 版本的 POD。

4. 逐个实例替换，直到每个版本都是 V2 版本。

  1. strategy:
  2. type: RollingUpdate
  3. rollingUpdate:
  4. maxSurge: 1
  5. maxUnavailable: 0
    maxSurge:滚动更新时最多可以多启动多少个pod
    maxUnavailable:滚动更新时最大可以删除多少个pod
    maxSurge和maxUnavailable可以用来决定更新是的最大pod数和最小pod数
    是先启动一个pod再删除一个pod还是先删除一个pod再启动一个pod
    例如
    replicas是5
    maxSurge: 1
    maxUnavailable: 0
    更新时 最大的pod数是 replicas+ maxSurge = 5+1 =6，最大的个数是6
    最小pod数是 replicas - maxUnavailable = 5-0 = 5,最小pod数是5，所以只能先启动一个pod，再删除一个pod
     
    在这个过程中，我们发现第二个版本有问题，我们需要进行回滚，此时我们需要执行一下如下命令

kubectl rollout undo deploy my-app
如果想两个版本都观察一下，这个时候需要执行命令。

kubectl rollout pause deploy my-app
如果发现第二个版本没有问题，那么我们要恢复执行

kubectl rollout resume deploy my-app
最后我们清理一下所有的部署

kubectl delete -l app=my-app

    --------------------------------------------

蓝绿布署（blue/green ）：准备一套蓝色的容器和一套绿色的容器，进行流量切换。

蓝绿部署是最常见的⼀种0 downtime部署的⽅式，是⼀种以可预测的⽅式发布应⽤的技术，⽬的是减少发布过程中服务停⽌的时间。蓝绿
部署原理上很简单，就是通过冗余来解决问题。通常⽣产环境需要两组配置（蓝绿配置），⼀组是active的⽣产环境的配置（绿配置），⼀
组是inactive的配置（蓝绿配置）。⽤户访问的时候，只会让⽤户访问active的服务器集群。在绿⾊环境（active）运⾏当前⽣产环境中的
应⽤，也就是旧版本应⽤version1。当你想要升级到version2 ，在蓝⾊环境（inactive）中进⾏操作，即部署新版本应⽤，并进⾏测试。
如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝⾊环境了。随后需要监测新版本应⽤，也就是version2 是否有故障和异
常。如果运⾏良好，就可以删除version1 使⽤的资源。如果运⾏出现了问题，可以通过负载均衡器指向快速回滚到绿⾊环境。
蓝绿部署的优点

从过程不难发现，在部署的过程中，应⽤始终在线。并且，新版本上线的过程中，并没有修改⽼版本的任何内容，在部署期间，⽼版本的状
态不受影响。这样风险很⼩，并且，只要⽼版本的资源不被删除，理论上，可以在任何时间回滚到⽼版本。
蓝绿部署的弱点：
使⽤蓝绿部署需要注意的⼀些细节包括：
1、当切换到蓝⾊环境时，需要妥当处理未完成的业务和新的业务。如果数据库后端⽆法处理，会是⼀个⽐较⿇烦的问题。
2、有可能会出现需要同时处理“微服务架构应⽤”和“传统架构应⽤”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务
停⽌；
3、需要提前考虑数据库与应⽤部署同步迁移/回滚的问题。
4、蓝绿部署需要有基础设施⽀持。
5、在⾮隔离基础架构（ VM 、 Docker 等）上执⾏蓝绿部署，蓝⾊环境和绿⾊环境有被摧毁的风险。
6、另外，这种⽅式不好的地⽅还在于冗余产⽣的额外维护、配置的成本，以及服务器本⾝运⾏的开销。

如果测试没问题，就可以把负载均衡器／反向代理／路由指向蓝⾊环境了。随后需要监测新版本应⽤，也就是version2 是否有故障和异
常。如果运⾏良好，就可以删除version1 使⽤的资源。如果运⾏出现了问题，可以通过负载均衡器指向快速回滚到绿⾊环境。
蓝绿部署的优点：
这种⽅式的好处在你可以始终很放⼼的去部署inactive环境，如果出错并不影响⽣产环境的服务，如果切换后出现问题，也可以在⾮常短的

kubctl patch service my-ap -p '{"spec":{"selector":{"version":"v2.0.0"}}}'

注意：蓝绿部署需要准备两套资源，相对有的时候需要的资源会多； 这种情况可以快速还原版本，不会出现滚动更新那样，回滚需要的时间会很久。
--------------------------------------

金丝雀发布（canary) ：更新部分容器，没有问题后进行逐步替换，直到切完。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
      version: v2.0.0
  template:
    metadata:

 

kubectl scale --replicas=10 deploy my-app-v2

------------------------------------------------------------------------------------------------

A/B测试发布：即将发布的结果面向部分用户，这块没有现成的组件，需要进行自行处理，比如使用 Istio、Linkerd、Traefik 等。这种方式采用在 Http 的 Header 上进行处理。

无损发布：现在很多发布都是将容器停掉，当没有请求的时候这个时候发布会实现无损发布。

A/B 测试跟蓝绿部署完全是两码事。A/B 测试是⽤来测试应⽤功能表现的⽅法，例如可⽤性、受欢迎程度、可见性等等。 蓝绿部署的⽬的
是安全稳定地发布新版本应⽤，并在必要时回滚。
A/B 测试与蓝绿部署的区别在于， A/B 测试⽬的在于通过科学的实验设计、采样样本代表性、流量分割与⼩流量测试等⽅式来获得具有代
表性的实验结论，并确信该结论在推⼴到全部流量可信。
A/B 测试和蓝绿部署可以同时使⽤。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/balance-algorithm: roundrobin
    ingress.kubernetes.io/blue-green-deploy: group=blue=1,group=green=1
    ingress.kubernetes.io/blue-green-mode: pod
    ingress.kubernetes.io/ssl-redirect: "false"
  name: bluegreen
spec:
  rules:
  - host: bluegreen.example.com
    http:
      paths:
      - backend:
          serviceName: bluegreen
          servicePort: 8000
        path: /

 

 

 无损发布 EDAS

 

 

 

 

 

相关文章