K8S学习之基础十八：k8s的灰度发布和金丝雀部署

灰度发布

逐步扩大新版本的发布范围，从少量用户逐步扩展到全体用户。

特点是分阶段发布、持续监控、逐步扩展

适合需要逐步验证和降低风险的更新

金丝雀部署

将新版本先部署到一小部分用户或服务器，观察其表现，再决定是否全面推广。

特点：小范围部署、实时监控、快速回滚

适合高风险更新或需要快速验证的情况。

灰度发布和金丝雀部署的关系

包含关系：金丝雀部署是灰度发布的第一阶段，先在小范围内验证，再逐步扩大。

目标一致：两者都旨在降低发布风险，确保稳定性。

策略互补：金丝雀部署用于快速验证，灰度发布用于逐步扩展，常结合使用。

金丝雀验证

简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。 如果金丝测试通过，则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。

优点：灵活，策略自定义，可以按照流量或具体的内容进行灰度(比如不同账号，不同参数)，出现问题不会影响全网用户

缺点：没有覆盖到所有的用户导致出现问题不好排查

1. 创建一个deployment，pod镜像使用版本v1

vi canary-v1.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: 172.16.80.140/myapp/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

2. 执行命令，更改版本，进行金丝雀部署

kubectl set image deployment myapp-v1 myapp=172.16.80.140/myapp/myapp:v2  && kubectl rollout pause deployment myapp-v1

新生成的pod，已经变成了新的版本

业务运行一段时候，版本没有问题，可以取消暂停完全部署

kubectl rollout resume deployment myapp-v1

pod都变成了新版本，并且数量也与deploy设置的相同

rs变成了两个，老版本的rs和新版本的共存，可以随时rollingupdate

4. pod变化分析

5. 居观察这种简单命令的金丝雀部署pod变化，应该是根据maxSurge和maxUnvaliable调整的

   默认都是25%

   当副本是5时，pod最多是 5 + 525% = 6.25，向上取整，所以最多有7个
   pod不可用数量是 5 - 5 25% = 3.75，向下取整为3，所以可用的4个，不可用的1个会被干掉

   总数为7，所以有 7 - 4 = 3 个新版本的pod

   以上分析只是猜测，官网没有找到具体说明，修改测试了几次都符合这个规律，是否正确还请指正

6. 以上只是金丝雀发布的一种比较简单的方式，具体可参考官网通过修改yaml文件实现