k8s 蓝绿发布、滚动发布、灰度发布
在Kubernetes（k8s）中，蓝绿发布、滚动发布、灰度发布（金丝雀发布）是三种常见的应用部署和更新策略。下面将分别对这几种发布方式进行说明，并给出相应的例子。
蓝绿发布
蓝绿发布是一种无缝切换版本的部署策略。它通过在生产环境中同时运行两个相同版本的应用程序实例（蓝色环境和绿色环境），使得新版本的应用可以在不影响旧版本的情况下进行部署和测试。当新版本经过验证并准备好切换时，流量将被重定向到新环境（绿色），同时旧环境（蓝色）被移除或停止。
步骤：
- 准备两个相同的环境：蓝色环境和绿色环境。这两个环境应该具有相同的配置和基础设施。
- 在蓝色环境中部署当前的应用程序版本。
- 在绿色环境中部署新的应用程序版本。
- 配置K8s Ingress以将部分流量路由到绿色环境，进行新版本测试。
- 如果新版本表现良好，逐步增加流量比例，直到将所有流量都切换到绿色环境。
- 移除或停止蓝色环境中的旧版本。
优点：
- 易于设置：蓝绿发布策略相对简单，只需维护两个环境（蓝色和绿色），便于部署和切换。
- 流量完全受控：通过调整路由规则，可以轻松控制流量在新旧版本之间的切换，实现零停机时间更新。
- 降低风险：由于新版本在切换前已经过充分测试，因此可以降低生产环境出现问题的风险。
缺点：
- 维护成本高：需要同时维护两个相同的环境，增加了资源消耗和维护成本。
- 回滚速度可能较慢：在出现问题时，虽然可以回滚到旧版本，但由于需要切换环境，回滚速度可能相对较慢。
滚动发布
滚动发布是按批次停止老版本实例，启动新版本实例的发布方式。这种方式可以节约资源，但部署和回滚速度较慢。
步骤：
- 假设有一个包含3个副本的Deployment，当前版本为v1。
- 更新Deployment的版本为v2，并设置滚动更新策略。
- K8s将开始滚动更新，逐个替换v1版本的Pod为v2版本。
- 在滚动更新过程中，可以监控新版本的性能和稳定性。
- 如果出现问题，可以暂停滚动更新，回滚到旧版本。
优点：
- 节约资源：滚动发布可以逐步替换旧版本实例，无需同时运行两个完整版本的应用，从而节约资源。
- 灵活性高：滚动发布过程中可以暂停、继续或回滚更新操作，提供了较高的灵活性。
- 用户体验好：由于更新是逐步进行的，对用户的影响较小，可以保持较高的可用性。
缺点：
- 部署和回滚速度慢：滚动发布需要逐个替换实例，因此部署和回滚速度相对较慢。
- 复杂性高：滚动发布过程中需要监控新版本实例的性能和稳定性，增加了复杂性。
灰度发布（金丝雀发布）
灰度发布（又称金丝雀发布）是一种逐步将流量从旧版本迁移到新版本的发布方式。它通常先安排一小部分的用户流量去访问更新的Pod来进行测试，如果测试没问题后再扩大比例，直到全部更新完成为止。
步骤：
- 创建一个包含旧版本应用的Deployment和Service。
- 更新Deployment的版本，并配置暂停Deployment，以便进行金丝雀测试。
- 将一小部分流量路由到新版本的Pod，观察其性能和稳定性。
- 如果新版本表现良好，逐步调整流量权重比例，使得流量慢慢从旧版本迁移至新版本。
- 在迁移过程中，可以根据设置的流量比例对新版本服务进行扩容，同时对旧版本服务进行缩容。
- 当所有流量都迁移到新版本后，删除旧版本的Deployment和Service。
金丝雀发布的特别说明：
- 金丝雀发布的思想是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。
- 验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本。
- 在金丝雀发布中，将流量分流到新旧版本的这个过程被称为分阶段访问（Staged Access），也可以称为阶段性流量调度（Staged Traffic Shifting）。
优点：
- 降低风险：通过逐步将流量切换到新版本应用，可以及时发现并修复潜在的问题，降低大规模故障的风险。
- 提高发布成功率：灰度发布允许在小范围内测试新版本，确保稳定后再全面推广，从而提高发布成功率。
- 用户体验影响小：由于只有部分用户会首先体验到新版本，因此对其他用户的影响较小。
缺点：
- 自动化要求高：灰度发布需要自动化工具和流程来支持流量的逐步切换和监控。
- 发布期间需要人为操作：在某些情况下，灰度发布过程中可能需要人为干预和调整，增加了操作复杂度。
- 可能引发服务中断：如果新版本存在问题且未能及时发现，可能会引发服务中断或性能下降。
综上所述，蓝绿发布、滚动发布和灰度发布（金丝雀发布）各有优缺点，适用于不同的场景和需求。在实际应用中，应根据具体情况选择合适的发布策略。