网站内容更新策略(如何简化容器化应用的更新过程部署策略/CD管道)

　　网站内容更新策略(如何简化容器化应用的更新过程部署策略/CD管道)

　　在现代应用技术领域，容器编排平台简化了基于微服务的应用的基础架构配置，并通过模块化实现了高效的工作负载管理。作为一个被广泛采用的可以支持多种部署资源的平台，Kubernetes 使企业可以更轻松地在*敏*感*词* CI/CD 管道中部署和管理各种应用程序。虽然 Kubernetes 提供滚动更新作为默认部署策略，但某些用例需要一种非常规的方法来部署或更新集群中的服务。下面，我们将基于对基本 Kubernetes 部署概念的回顾，深入探讨各种高级 Kubernetes 部署策略、它们的优缺点以及它们的用例。

　　

　　Kubernetes 中的部署概念

　　在部署期间，集群管理员可以自定义应用程序的生命周期以及如何执行更新。Kubernetes 通常使用部署资源并以声明方式更新各种应用程序。这种自动化部署方法实现并维护每个集群对象和应用程序的所需状态。此外，其后端可以以安全且可重复的方式执行应用程序更新，而无需人工干预。也就是说，Kubernetes的部署可以辅助集群管理员实现：

　　下面，我们将探讨 Kubernetes 如何简化容器化应用程序的更新过程，以及它将如何应对持续交付的挑战。

　　Kubernetes 对象

　　虽然 Kubernetes 可以利用各种工作负载资源对象作为持久实体来管理集群的状态，但 Kubernetes API 通常使用 Deployment、ReplicaSet、StatefulSet 和 DaemonSet。) 四个资源以声明方式更新应用程序。让我们仔细看看这四种资源的特点：

　　​​部署​​​

　　作为 Kubernetes 资源，部署可用于定义和识别应用程序所需的状态。集群管理员在 Deployment 的 YAML 文件中描述预期状态，以便部署控制器，并相应地将实际状态逐渐更改为预期状态。为了保证高可用，部署控制器还会持续监控失效的集群节点和Pod，并根据需要用健康的集群节点和Pod替换。

　　​​副本集​​​

　　ReplicaSet 可用于维护特定数量的 pod，以确保它们的高可用性。ReplicaSet 清单文件将包括以下字段：

　　​​有状态集​​​

　　StatefulSet 对象管理有状态应用程序中 pod 的部署和扩展。该资源将基于相同的容器规范来管理 Pod，并保证整个 Pod 组的唯一性和有序排列。StatefulSet 的持久 pod 标识符，使集群管理员能够将其工作负载连接到高可用性持久存储卷。

　　​​​守护程序集​​​

　　DaemonSets 通过确保一组节点在 Pod 的副本上运行来帮助维护应用程序部署。DaemonSet 资源主要用于管理各种代理的部署和生命周期，例如：

　　您还可以通过链接查看更多 Kubernetes 工作负载的资源列表及其详细信息 - 。

　　使用部署更新

　　Kubernetes 部署提供了一种可预测的方式来启动和停止 pod。有了这些资源，我们可以轻松地实施部署、回滚更改，并以自主、迭代的方式管理软件的发布周期。目前，Kubernetes 通过提供多种部署策略，可以实现更小、更频繁的更新，并为应用程序提供以下优势：

　　默认情况下，可以使用 Kubernetes 提供的滚动更新作为其标准部署策略，一次性将旧 pod 替换为新版本，以避免集群停机。此外，Kubernetes 支持各种高级部署策略，包括蓝绿、金丝雀和 A/B 部署，具体取决于功能的目标和类型。下面，让我们详细讨论这些策略的特点，以及它们的优缺点。

　　Kubernetes 部署的高级策略

　　部署配置和路由功能的结合使发布团队能够在提交完整版本之前在实时生产环境中测试新功能的有效性。为此，开发人员可以利用 Kubernetes 支持的高级部署策略来精确控制特定版本的质量。当然，应如何部署 Kubernetes 以向应用程序发布更新和新功能取决于实际用例和工作负载。

　　蓝绿部署

　　在蓝绿策略中，应用程序的新旧实例同时部署。虽然用户可以继续访问现有版本（蓝色），但相同数量的新版本（绿色）实例可供站点可靠性工程 (SRE) 和 QA 团队使用。一旦 QA 团队确认绿色版本已通过所有测试要求，用户将被重定向到新版本。这通常通过更新负载平衡服务的选择器字段中的版本标签来实现。通常，当开发人员想要避免版本控制问题时，蓝绿部署效果很好。

　　使用蓝绿部署策略

　　让我们假设应用程序的第一个版本是 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

　　如果应用程序的新版本按预期工作，则 v1.0.0 版本可以“下线”。

　　金丝雀部署

　　在金丝雀策略中，一部分用户被路由到托管新版本的 pod。这个用户群会逐渐增加，连接到旧版本的群组会相应减少。此策略可用于比较使用两个版本的一组用户的体验。如果没有检测到错误，我们可以将新版本推送给旧版本留下的用户。

　　使用金丝雀部署策略

　　原生 Kubernetes 金丝雀部署的过程包括以下步骤：

　　1. 通过以下方式部署运行版本 1 所需的副本：

　　部署第一个应用程序：

　　$ kubectl apply -f darwin-v1.yaml

　　将其扩展到所需的副本数量：

　　$ kubectl scale --replicas=9 deploy darwin-v1

　　2.部署版本 2 实例：

　　$ kubectl apply -f darwin-v2.yaml

　　3.测试第二版是否部署成功：

　　$ service=$(minikube service darwin --url)

$ while sleep 0.1; do curl "$service"; done

　　4.如果部署成功，扩展版本2的实例数量：

　　$ kubectl scale --replicas=10 deploy darwin-v2

　　5.一旦所有副本都处于活动状态，您可以“优雅地”删除版本 1：

　　$ kubectl delete deploy darwin-v1

　　A/B 部署

　　通过 A/B 部署，管理员可以将特定的用户子集路由到具有某些限制和/或条件的新版本。此类部署主要用于衡量用户群对某些新功能的响应。A/B 部署有时被称为“暗启动”，因为用户不知道他们在测试期间接触了新功能。

　　使用 A/B 部署策略

　　下面是一个如何在 Istio 服务网格上执行 A/B 测试的示例。这将有助于使用流量权重推出不同的版本：

　　1.假设集群上已经安装好了，那么我们首先需要部署两个版本的应用：

　　$ 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 的比例在版本之间分配流量权重。要转移流量的权重，我们可以编辑每个服务的权重，然后通过 Kubernetes CLI 更新 VirtualService 规则。

　　每种高级部署策略的适用场景

　　由于 Kubernetes 用例会根据可用性要求、预算限制、可用资源和其他考虑因素而有所不同，因此目前没有一种万能的部署策略。选择部署策略时，请考虑下表：

　　Kubernetes部署策略对比

　　

　　概括

　　借助各种部署资源，Kubernetes 管理员可以通过建立高效的版本控制系统来更新 pod、回滚到早期版本或扩展基础架构以满足不断增长的工作负载，并管理不同版本的应用程序以最大限度地减少停机时间。

　　上述各种 Kubernetes 高级部署策略，在一定程度上可以方便管理员将流量和请求路由到特定版本，从而处理真实测试环境中的各种错误。同时，这些策略还经常用于在管理员和开发人员完全提交更改之前验证新功能是否按原计划工作，并实施具有足够回滚选项的多个松散耦合服务，从而实现应用程序更新和功能的快速交付. 当然，如何选择还要看你的实际应用环境，参考上面的对比表进行选择。

　　其他参考资源译者介绍

　　Julian Chen，51CTO社区编辑，十余年IT项目实施经验，善于管控内外部资源和风险，注重传播网络和信息安全知识和经验；他继续发表博客文章、专题和翻译。，分享前沿技术和新知识；经常进行线上线下的信息安全培训和教学。

　　原标题：Sudip Sengupta 的高级 Kubernetes 部署策略