Kubernetes 部署策略
查找最适合你的应用程序的 Kubernetes 发布策略。
了解你的 Kubernetes 部署选项
无论你是想缩短上市时间、创建无停机时间的可复原部署、更快或更频繁地发布应用和功能，还是想以更大的灵活性执行操作，选择合适的 Kubernetes 部署策略都极为关键，只有这样你才能交付可复原的应用程序和基础结构。每个 Kubernetes 部署策略都有其优势，具体取决于你的目标和需求。
Kubernetes 部署的工作原理
在应用 Kubernetes 部署策略之前，你需要了解 Kubernetes 部署的各个组成部分以及它们如何共同发挥作用。
Kubernetes 部署中的内容
YAML 文件
描述 Kubernetes 群集的所需状态（Pod 配置），充当 Kubernetes 部署的基础。
Pod
运行应用或工作流所需的容器、共享资源和环境。
ReplicaSet
具有相同配置的 Pod 组称为 ReplicaSet，它可以按照 Kubernetes 部署中 YAML 文件的描述，确保始终有指定类型和数量的 Pod 在运行。如果某个 Pod 出现故障，将创建一个新 Pod。
Kube-controller-manager
更改群集的当前状态以匹配 YAML 中描述的所需状态，创建新 Pod 和 ReplicaSet，并更新或删除现有 Pod 和 ReplicaSet。
Kube-scheduler
确定如何在工作器节点之间部署 Pod 和 ReplicaSet，以及如何向这些节点分发流量。
推出
将群集从其当前状态重新配置为所需状态的过程 - 在大多数情况下，该过程无需停机时间即可完成。
Kubernetes 推出的工作原理
- 创建一个描述群集的所需状态配置的 YAML 文件。
- 通过 kubectl（Kubernetes 命令行接口）将 YAML 文件应用到群集。
- Kubectl 将请求提交给 kube-apiserver，后者在将更改记录到数据库 etcd 之前会对请求进行身份验证和授权。
- Kube-controller-manager 持续监视系统是否有新的请求，并努力将系统状态调节至所需状态 - 在此过程中创建 ReplicaSet、部署和 Pod。
- 在所有控制器都运行之后，kube-scheduler 会看到有 Pod 处于"挂起"状态，因为它们尚未被安排在节点上运行。计划程序会为 Pod 查找合适的节点，然后与每个节点中的 kubelet 通信以控制并启动部署。
Kubernetes 部署用例
创建
推出全新的 Kubernetes Pod 和 ReplicaSet。
更新
声明一个新的所需状态，并以一种受控的方式推出新的 Pod 和 ReplicaSet。
回滚
将 Kubernetes 部署还原为之前的状态 - 如果当前状态不稳定，这非常有用。
扩展
增加 Kubernetes 部署中 Pod 和 ReplicaSet 的数量，而无需更改它们。
Kubernetes 部署策略
适用于你的方案的最佳 Kubernetes 部署策略取决于诸多因素：你可以留出多少停机时间（如果有）、你的部署环境、你对新版本或平台的稳定性有多大的信心、你是否需要测试以及你希望了解什么、资源成本和可用性，以及业务目标。以下是组织在生产中使用的四种常见部署策略。
滚动
Kubernetes 的默认推出方式是滚动部署。此部署按一次一个的方式慢慢替换 Pod，以免出现停机时间。旧 Pod 只有在新 Pod 准备就绪后才会减少。如果部署遇到问题，可以暂停或取消 Kubernetes 部署，而不用使整个群集脱机。
蓝/绿
在蓝/绿部署中，应用程序或工作流的新版本（蓝色）会在当前版本（绿色）仍在运行时发布。这样就可以在生产环境中测试蓝色版本，同时只向用户公开稳定的绿色版本。测试后，蓝色版本会逐渐替代绿色版本。
Canary
通过向一小部分客户发布新版本，允许客户测试你的 Kubernetes 部署。你将同时运行新版本的一个 ReplicaSet 以及当前版本，然后，当无错误时间达到指定长度后，扩展新版本并删除旧版本。
A/B 测试
与 Kubernetes 的 Canary 部署策略类似，A/B 测试策略面向特定的客户组。但是，A/B 测试部署不仅仅用于验证版本的稳定性，还用于测试版本在实现业务目标时的有效性。新版本根据 cookie、地理位置、操作系统和设备类型等因素分发给用户，并且经常与当前版本一起运行 - 在新版本证明其价值后对其进行扩展。
Kubernetes 部署工具
虽然可以使用命令行或 YAML 文件来执行这些 Kubernetes 部署策略中的任何一种策略，但通过实现此类 Kubernetes 部署工具和服务，你可以更好地利用群集和部署。
