在现代应用架构中，容器编排平台通过模块化和自动化管理，简化了以微服务为核心的基础设施配置与运维。Kubernetes 作为广泛使用的平台，帮助企业在持续集成/持续交付（CI/CD）流程中实现应用的持续部署、扩展与治理。尽管默认提供滚动更新作为标准部署策略，但在某些场景下，企业需要采用更为丰富的策略来部署或更新服务。以下内容在回顾基本部署概念的基础上，深入探讨各种高级 Kubernetes 部署策略、它们的优缺点与典型用例。
Kubernetes 的部署概念
在部署阶段，集群管理员可以定义应用的生命周期与更新方式。Kubernetes 通常通过 Deployment、ReplicaSet、StatefulSet 和 DaemonSet 等资源来实现声明式更新，确保应用达到所需状态并持续自我修正，从而在无需人工干预的情况下安全且可重复地完成更新。借助这些资源，集群管理员能够实现以下目标：
部署单个 Pod 或副本集、更新整组 Pod、回滚到早期版本、暂停或继续部署、扩展和缩减副本等操作。
下面，我们将探讨 Kubernetes 如何简化容器化应用的更新流程，以及如何应对持续交付的挑战。
Kubernetes 对象概览
尽管 Kubernetes 支持多种工作负载资源来持久化管理集群状态，常用的核心对象仍包括 Deployment、ReplicaSet、StatefulSet 和 DaemonSet。下面简要介绍这四种资源的要点：
Deployment
Deployment 用于定义应用的目标状态。通过描述期望状态，部署控制器会逐步将实际状态调整为目标状态，并在需要时替换健康的节点和 Pod 以确保高可用性。
ReplicaSet
ReplicaSet 用于维持指定数量的 Pod，确保服务的持续可用性。清单中包含 Pod 选择器、副本数量以及用于创建新 Pod 的模板等字段。
StatefulSet
StatefulSet 管理有状态的应用的 Pod 的部署与扩缩。它确保 Pod 的顺序性和唯一性，并为每个 Pod 提供稳定的持久化标识符，便于与持久化存储卷整合。
DaemonSet
DaemonSet 确保集群中所有节点或特定节点组上运行一组 Pod，常用于日志收集、节点监控等场景。
您还可以参考相关资源，了解更多 Kubernetes 工作负载对象的清单与详细信息。
部署更新的核心能力
Kubernetes 的部署资源提供可预测的方式来启动、停止和滚动更新 Pod。通过这些资源，我们可以实现持续部署、变更回滚，以及逐步、可控的发布节奏。当前，Kubernetes 提供多种部署策略，帮助实现更小且更频繁的更新，并为应用带来以下优势：
更快的反馈与功能迭代、更短的上市时间、提升 DevOps 团队的生产力。
默认的滚动更新是标准部署策略的一部分，旨在平滑替换旧版本以避免停机。根据具体目标与用例，Kubernetes 还支持包括蓝绿、金丝雀和 A/B 部署等高级策略。下面将详细介绍这些策略及其适用场景、优缺点。
高级部署策略概览
将部署配置与路由能力结合使用，可以在生产环境中实时验证新功能，而不影响现有版本。开发团队可以利用 Kubernetes 提供的高级部署策略，精确控制特定版本的可用性与质量。具体应如何选择部署方式，取决于实际用例与工作负载。
蓝绿部署
在蓝绿策略中，同时运行新旧版本实例。用户仍可无缝访问当前版本（蓝色），同时新版本（绿色）就绪供测试与验证。一旦 QA 团队确认绿色版通过测试，流量将切换到新版本，通常通过更新负载均衡器中的路由选择器（Selector）或标签来实现。蓝绿部署在需要避免版本回滚风险时特别有用。
蓝绿部署示例场景
假设服务 v1.0.0 已上线，准备引入 v2.0.0。以下示例展示指向第一版本的服务配置：
APIversion: v1
kind: Service
Metadata:
name: darwin-service-a
spec:
type: LoadBalancer
selector:
app: nginx
version: v1.0.0
ports:
– name: http
port: 80
targetPort: 80
指向第二版本的配置如下：
APIversion: v1
kind: Service
Metadata:
name: darwin-service-b
spec:
type: LoadBalancer
selector:
app: nginx
version: v2.0.0
ports:
– name: http
port: 80
targetPort: http
测试通过后，将第一个服务的选择器切换到 v2.0.0，即完成向新版本的迁移：
APIversion: v1
kind: Service
Metadata:
name: darwin-service-a
spec:
type: LoadBalancer
selector:
app: nginx
version: v2.0.0
ports:
– name: http
port: 80
targetPort: http
如果新版本稳定运行，旧版本将逐步下线。
金丝雀部署
金丝雀策略将新版本逐步暴露给部分用户，随着对新版本的验证逐步扩大覆盖范围，旧版本的用户数量则相应减少。若未发现错误，可继续将新版本推广给剩余用户。
金丝雀部署的典型流程
1. 部署 v1 副本：
部署应用 v1：
$ kubectl apply -f darwin-v1.yaml
将副本扩展至目标数量：
$ kubectl scale –replicas=9 deploy darwin-v1
2. 部署 v2 的实例：
$ kubectl apply -f darwin-v2.yaml
3. 验证 v2 是否已就绪：
$ service=$(minikube service darwin –url)
$ while sleep 0.1; do curl “${service}”; done
4. 如验证通过，增大 v2 的副本数：
$ kubectl scale –replicas=10 deploy darwin-v2
5. 所有副本上线后，平滑移除 v1：
$ kubectl delete deploy darwin-v1
A/B 部署
通过 A/B 流量分发，管理员可以将特定用户群路由到带有新特性的版本。通常用于评估新功能对不同用户群的实际影响，在测试阶段用户通常不知情的情况下体验到新功能，因此也被称为“暗启动”。
A/B 部署策略示例
以下示例演示如何在 Istio 服务网格中执行 A/B 测试，通过流量权重来分配不同版本：
1. 集群已安装 Istio 时，先部署两个版本：
$ kubectl apply -f darwin-v1.yaml -f darwin-v2.yaml
2. 通过 Istio 网关发布两个版本，并将请求先路由到第一服务：
$ kubectl apply -f ./gateway.yaml -f ./virtualservice.yaml
3. 使用权重规则应用 Istio 的 VirtualService：
$ kubectl apply -f ./virtualservice-weight.yaml
它将实现 1:10 的版本间流量分发。为调整比例，可编辑各服务的权重并更新 VirtualService 规则。
不同高级策略的适用场景
不同用例对可用性、预算、资源等因素的要求各不相同，因此不存在放之四海皆准的“最佳策略”。在选择时，请结合实际的应用场景、负载特性与运维目标进行权衡。
小结
通过灵活的部署资源，运维团队可以实现对 Pod 的版本控制、快速回滚、以及对基础设施的扩展，同时通过对不同版本的管理，尽量缩短停机时间。上述高级部署策略在一定程度上帮助管理员将流量定向到指定版本，以在接近真实环境的测试中发现并修复问题。同时，它们也用于在正式变更发布前，验证新功能的可靠性和可用性，并提供回滚选项，以实现更松耦合的服务更新与快速交付。具体应如何选择策略，请结合实际应用场景与前述比较进行决策。
相关资源以 kubectl 和 Kubernetes 官方示例为参考，包含更多部署用例与生命周期状态的资料。
作者：技论文记载，技术社区编辑，具备十年以上 IT 项目实施经验，致力于传播网络与信息安全的知识与经验；以博文、专题与译文等形式，分享前沿技术动态与实践经验。
原文标题：Advanced Kubernetes Deployment Strategies，作者：SudIP Sengupta
