让我们在探讨部署策略之前，先聊聊一些重要的主题。

副本控制器

一个 ReplicaSet 是一个 Kubernetes API 资源，用于控制运行应用程序的多个相同副本（称为副本集的 Pod 实例）。它可以按需增减副本数量。此外，它还能在所有副本上滚动更新应用程序的新版本。

部署工作

一个 Deployment 将 ReplicaSet 的功能抽象化并在内部进行管理。这意味着你不需要自己创建、修改或删除 ReplicaSet 对象。Deployment 保留应用版本的历史，并可以回滚到旧版本以应对阻碍生产或可能带来成本的问题。此外，它提供了调整副本数量的功能。

部署会将这些信息传递给副本集，副本集利用这些信息来管理副本。部署和副本之间的映射是通过标签选择实现的。为了让标签选择能正常工作，确保 spec.selector.matchLabels 和 spec.template.metadata 的值是一致的。

部署标签选取

部署是指将软件变更提供给最终用户或程序的过程，使这些变更可用。你需要考虑两个方面：如何部署变更以及如何将网络流量路由到应用程序。根据使用场景、应用类型和权衡选择合适的部署策略。

滚动部署计划

部署原语采用滚动更新作为默认的部署策略，也称为滚动部署。之所以称为“滚动”，是因为部署会逐步增加新版本的副本数量，从而将副本从旧版本过渡到新版本。当用户更新 Pod 模板时，部署会自动创建一个新的 ReplicaSet 来适应更改。

在这个场景中，用户将应用程序版本从1.0.0升级到2.0.0。结果，Deployment会创建一个新的ReplicaSet，并启动新的Pods，同时缩减旧版本的Pods。Service将网络流量路由到旧版本或新版本的应用程序。建议为Pod模板定义就绪探针，以确保副本能够处理传入请求。

滚动部署是一种适合滚动推出新版本应用且不间断服务的策略。值得注意的是，这种策略也伴随着潜在风险。新旧版本会并行运行。如果消费者尚未更新客户端软件以适应新版本，新版本中的破坏性更改可能会导致难以诊断的错误。建议以向后兼容的方式推出新版本应用。

部署方案

固定的部署策略将在创建一个新的副本集来控制新版本应用的副本之前，立即将运行旧版本应用的副本终止。

所有旧 ReplicaSet 的副本会同时关闭。然后，新的 ReplicaSet 控制的副本会启动。在这个过程中，服务可能无法访问任何副本，这会导致消费者不必要的停机。

配置就绪探测器并不是绝对必要，因为所有老版本的应用实例会同时被停止。然而，在传入流量到达容器之前，定义一个就绪探测来确保应用已经启动并运行正常仍然很有意义。

固定部署方式适用于可以接受应用停机的情况。在生产环境中，如果提前通知客户停机时间，这样的部署方式可能会有效。

蓝绿发布策略

蓝绿部署策略形象地用蓝色代表旧的应用实例，绿色代表新的应用实例。两个版本的应用会同时运行，且每个实例的副本数量相同。

Kubernetes将流量导向蓝色部署，而开发或测试团队则推出并测试绿色部署，同时进行。一旦绿色部署准备就绪，流量随即切换至绿色部署。这时，负责应用的团队就可以停用蓝色部署了。

蓝绿部署并不是一种可以直接在Deployment资源中配置的内置策略。你需要分别为两个应用版本创建各自的Deployment对象。服务将流量路由到由蓝色或绿色Deployment管理的相应副本。

蓝绿部署策略适合需要复杂升级且不能中断消费者服务的部署情况。这种情况通常发生在需要数据迁移或同时更新多个相互依赖软件组件时。如果需要回退到旧版本的应用程序，只需简单更改服务的选择标签即可。

需要注意的是，你需要的硬件资源会比采用其他部署策略时更多。如果你需要五个实例来运行旧的应用程序版本，也需要相同数量的资源来运行新版本的应用程序，假设两个版本对资源的需求没有变化。

金丝雀发布策略

金丝雀部署策略类似于蓝绿部署；然而，你只会让新版本的应用程序对一部分用户可用。通过这种方法，你可以对新功能进行 A/B 测试，或者收集用户行为的数据。根据预定的成功标准，可以逐步增加流向新应用版本的流量。目标是逐步将旧版本完全淘汰。

在 Kubernetes 集群中，你可以用 Deployment 对象来表示每个应用版本。你可以通过将 spec.replicas 属性设为较小的值来更新到新版本，使新版本的副本数少于当前版本。

组织通常采用金丝雀部署策略来推出可能影响系统性能的实验性功能或更改。在将新功能仅提供给一小部分用户的同时，您可以评估其成功标准。实施金丝雀部署通常比蓝绿部署需要更少的硬件资源，因为具有新应用版本的副本数量较少。

感谢阅读！👏 想继续关注以获取更多文章吗？点击订阅吧！🖥️

[Kubernetes认证应用开发者(CKAD)学习手册] 学习指南，Benjamin Muschko著