在本文中,我们将讨论Kubernetes的部署策略,包括滚动部署以及诸如金丝雀部署及其变种之类的更高级的方法。
原文地址:https://www.weave.works/blog/kubernetes-deployment-strategies
如今,开发云原生应用程序的最大挑战之一是加快部署数量。 通过微服务,开发人员已经在使用和设计完全模块化的应用程序,该应用程序允许多个团队同时编写变更并将其部署到应用程序。
更短,更频繁的部署具有以下优点:
- 缩短了面向市场的时间
- 客户可以更快地使用功能
- 客户反馈更快地传递到产品团队,这意味着团队可以迭代功能并更快地解决问题
- 更高的开发人员士气和更多的产品特性
但是随着发布的频率提高,负面影响应用程序可靠性或客户体验的机会也会增加。因此,对于运营和DevOps团队来说,开发流程和管理部署策略以最小化产品和客户风险至关重要。
部署策略
您可以根据自己的目标采用几种不同类型的部署策略。例如,您可能需要对特定环境进行变更以进行更多测试,或者对用户/客户的子集进行变更,或者可能需要在使功能“通用”之前进行一些用户测试。
滚动部署
滚动部署是Kubernetes的标准默认部署。 它一步一步地工作,用新版本的Pod替换应用程序先前版本的Pod,而不会导致集群停机。
滚动更新等待新的Pod准备就绪(通过探针检测准备状态),然后再开始按比例缩小旧Pod。 如果出现问题,可以中止滚动更新或部署,而无需关闭整个群集。在用于此类部署的YAML定义文件中,新镜像替换了旧镜像。
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080
通过调整manifest文件中的参数,可以进一步完善滚动更新:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
重新建立
在这种非常简单的部署中,所有旧Pods都被立即杀死,并立即被新Pods替换。
manifest看起来像这样:
spec:
replicas: 3
strategy:
type: Recreate
template:
...
蓝/绿(或红/黑)部署
在蓝/绿部署策略(有时称为红/黑)中,应同时部署应用程序的旧版本(绿色)和新版本(蓝色)。 当这两个都部署时,用户只能访问绿色。 但是,质量保证小组可以使用蓝色,以通过单独的服务或通过直接端口转发进行测试自动化。
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"
在测试新版本并签署发布版本之后,服务将切换到蓝色版本,而旧的绿色版本将按比例缩小:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...
金丝雀部署
金丝雀部署有点像蓝/绿部署,但受到更多控制,并使用了一种“渐进式交付”逐步实施的方法。 金丝雀的保护范围有很多,包括:dark launches(或者叫Dark Testing是Fackbook使用的一种测试产品新功能的测试方法)或A/B测试。
当您想在应用程序后端测试一些新功能时,可以使用金丝雀部署。传统上,您可能拥有两台几乎完全相同的服务器:一台用于所有用户,另一台具有新功能,这些新功能会推广到一部分用户,然后进行比较。如果未报告任何错误,则新版本可以逐步推广到其他基础架构。
尽管可以仅通过使用Kubernetes资源来替换旧的和新的Pod来完成此策略,但是使用Istio这样的服务网格来实现该策略要方便得多,也容易得多。
例如,您可以将两个不同的manifest检入Git:标记为0.1.0的GA和标记为0.2.0的金丝雀。 通过更改Istio虚拟网关清单中的权重,可以管理这两个部署的流量百分比。
有关使用Istio实现金丝雀部署的分步教程,请参阅GitOps Workflows with Istio
使用Weaveworks Flagger来实现金丝雀部署
一种简单有效的管理金丝雀部署的方法是使用Weaveworks Flagger
使用Flagger,金丝雀部署的升级是自动化的。它使用Istio或App Mesh进行路由和转移流量,并使用Prometheus指标进行金丝雀分析。金丝雀分析还可以通过Webhooks进行扩展,以运行验收测试,负载测试或任何其他类型的自定义验证。
Flagger采用Kubernetes部署,还可以选择使用水平Pod自动缩放器(HPA)来创建一系列对象(Kubernetes部署,ClusterIP服务以及Istio或App Mesh虚拟服务),以推动金丝雀的分析和升级。
通过实现控制循环,Flagger逐渐将流量转移到金丝雀,同时测量关键性能指标,例如HTTP请求成功率,请求平均持续时间和Pod运行状况。基于对KPI的分析,金丝雀会被提升或中止,并将分析结果发布给Slack。有关概述和演示,请参阅Progressive Delivery for App Mesh
暗部署或者A/B部署
暗部署是金丝雀的另一种变化(顺带一提,Flagger也可以处理)。暗部署和金丝雀部署之间的区别在于,暗部署处理前端中的功能,而不像金丝雀部署那样处理后端的功能。
暗部署的另一个名称是A/B测试。您可以将其发布给一小部分用户,而不是为所有用户启动新功能。用户通常不知道自己被用作新功能的测试人员,因此称为“暗”部署。(游戏应用俗称暗改)
通过使用功能切换和其他工具,您可以监视用户与新功能的交互方式,是否正在转换用户,或者他们是否发现新的UI令人困惑以及其他类型的指标。
除了加权路由外,Flagger还可以根据HTTP匹配条件将流量路由到金丝雀。在A/B测试方案中,您将使用HTTP header或cookie来定位用户的特定细分受众群。这对于需要会话关联的前端应用程序特别有用。