Kubernetes的部署策略，你常用哪种？
确定哪种Kubernetes部署方法最适合不断的推出，而不会影响用户的更新。当今开发云原生应用的最大挑战之一是加快部署的速度。通过微服务方法，开发人员已经开始使用并设计完全模块化的应用，允许多个团队同时编写和部署更改到应用去。
更短和更频繁的部署提供了以下优势：
- 缩短产品上市时间。
- 客户可以更快地利用功能。
- 客户反馈更快地流回产品团队，这意味着团队可以迭代功能并更快地解决问题。
- 提升开发人员状态，生产中具有更多功能。
但随着更频繁的发布，对应用可靠性或客户体验产生负面影响的可能性也会增加。这就是为什么DevOps团队必须开发流程和管理部署策略，以最大限度地降低产品和客户风险的原因。
以下，一起讨论Kubernetes的部署策略，包括滚动部署和更高级的方法，如金丝雀及其变体。
部署策略
根据你的目标，可以利用几种不同类型的部署策略。例如，可能需要将更改推广到特定环境以进行更多测试，或者是用户/客户的子集，或者你可能需要在创建“一般可用”功能之前进行一些用户测试。
滚动部署
滚动部署是Kubernetes的标准默认部署。它逐个缓慢地工作，使用新版本的pod替换以前版本的应用的pod，而不会导致任何集群停机。
在开始缩小旧容器之前，滚动更新会通过准备探针等待新的pod就绪。如果出现问题，可以中止滚动更新或部署，而无需关闭整个集群。在此类部署的YAML定义文件中，新镜像将替换旧镜像。
通过调整清单文件中的参数，可以进一步细化滚动更新：
重新创建
在这种非常简单的部署中，所有旧的pod都被一次性杀死，并且用新的pod一次全部替换。
这个清单看起来像这样：
蓝/绿（或红/黑）部署
在蓝/绿部署策略（有时称为红/黑）中，旧版本的应用（绿色）和新版本（蓝色）同时部署。当部署这两个用户时，用户只能访问绿色，而蓝色可供QA团队在单独的服务上进行测试自动化或通过直接端口转发。
在测试新版本并签署发布后，该服务将切换为蓝色版本，旧版绿色版本将按比例缩小：
金丝雀部署
金丝雀部署有点像蓝/绿部署，但更受控制并使用更“ 渐进式交付 ”的分阶段方法。有许多策略属于金丝雀的保护范围，包括灰度发布或A/B测试。
当你想要测试一些新功能时，通常在应用程序的后端使用金丝雀。传统上，你可能拥有两个几乎完全相同的服务器：一个用于所有用户，另一个用新功能推送到一部分用户然后进行比较。如果未报告任何错误，则新版本可逐渐推广到基础架构的其余部分。
虽然可以通过替换旧的和新的pod来使用Kubernetes资源来完成此策略，但使用像Istio这样的服务网格实现此策略会更方便，更容易。
例如，你可以在Git中检查两个不同的清单：GA标记为0.1.0，金丝雀标记为0.2.0。通过更改Istio虚拟网关清单中的权重，可以管理这两个部署的流量百分比。
使用Weaveworks Flagger的金丝雀部署
管理金丝雀部署的一种简单有效的方法是使用Weaveworks Flagger。
使用Flagger，金丝雀部署的推广是自动化的。它使用Istio或App Mesh来路由和转移流量，使用Prometheus指标进行金丝雀分析。金丝雀分析还可以通过webhook进行扩展，以运行验收测试，负载测试或任何其他类型的自定义验证。
Flagger采用Kubernetes部署和可选的水平pod自动缩放器（HPA）来创建一系列对象（Kubernetes部署，ClusterIP服务和Istio或App Mesh虚拟服务），以推动金丝雀分析和推广。
通过实施控制回路，Flagger逐渐将流量转移到金丝雀，同时测量关键性能指标，如HTTP请求成功率，请求平均持续时间和pod健康状况。根据对KPI的分析，金丝雀被提升或中止，分析结果发布给Slack。
灰度部署或A/B部署
灰度部署是金丝雀的另一种变体（顺便提一下，也可以由Flagger处理）。灰度部署和金丝雀之间的区别在于，灰度部署处理前端而不是后端的功能。
灰度部署的另一个名称是A/B测试。你可以将其发布给少数用户，而不是为所有用户启动新功能。用户通常不知道他们被用作新功能的测试人员，因此称为“灰度”部署。
通过使用功能切换和其他工具，你可以监控用户与新功能的交互方式，以及是否正在转换用户，或者他们是否发现新的UI令人困惑以及其他类型的指标。
Flagger和A/B部署
除了加权路由，Flagger还可以根据HTTP匹配条件将流量路由到金丝雀。在A/B测试场景中，你将使用HTTP标头或Cookie来定位用户的特定部分。这对需要会话关联的前端应用特别有用。