一文读懂Kubernetes部署策略( 二 ) _Kubernetes

蓝色 web-app 的部署如下：
kind: Deploymentmetadata:name: web-app-01spec:template:metadata:labels:app: web-appversion: "v1.0.0"当我们想要将流量引导到应用程序的新（绿色）版本时，我们更新 manifest 文件以指向新版本 v2.0.0 。
kind: Servicemetadata: name: web-app-02 labels:app: web-appselector:app: web-appversion: v2.0.0绿色应用程序的部署如下：
kind: Deploymentmetadata:name: web-app-02spec:template:metadata:labels:app: web-appversion: "v2.0.0"4. 影子部署（Shadow Deployment）金丝雀与“影子部署”一词可以互换使用。
影子部署是一种策略，其中新版本的应用程序与现有的生产版本一起部署，主要用于监控和测试目的。在影子部署中，用户流量不会主动路由到新版本。这对于测试新功能的生产负载特别有用。

文章插图
这种技术比较复杂，需要特殊要求，尤其是出口流量。例如，有一个商品，您想调用支付服务进行影子测试，最终可能会让客户为他们的订单支付两次，所以复杂性比较高
5. 金丝雀部署（Canary Deployments）金丝雀部署可用于让一部分用户测试应用程序的新版本，或者在对新版本的功能性没有完全信心时使用。新版本的一个副本与旧版本一起发布，其中旧版本应用程序为大部分用户提供服务，而新版本应用程序为一小部分测试用户提供服务。如果新部署成功，则将其逐渐扩展到更多用户。

文章插图
例如，在一个具有 100 个运行的 Pod 的 K8s 集群中，有 95 个运行着应用程序的 v1.0.0 版本，而有 5 个运行着新的 v2.0.0 版本。95% 的用户将被路由到旧版本，而5% 的用户将被路由到新版本。为此，我们使用并行的两个部署，可以分别进行扩展。
旧应用程序的 yaml 文件中的 spec 部分可能如下所示:
spec:replicas: 95新应用程序的 yaml 文件中的 spec 部分可能如下所示：
spec:replicas: 5在上面的示例中，运行 100 个 Pod 可能是不切实际的。更好的方法是使用负载均衡器，如Nginx、HAProxy或Traefik，或者使用类似Istio、Hashicorp Consul或Linkrd的服务网格，他们可以提供对流量的更好控制。
6. A/B 部署与金丝雀部署类似，使用 A/B 部署，我们可以基于一些目标参数（通常是 HTTP 标头或 cookie等）定位给定的用户，并根据权重在不同版本之间分配流量。这种技术被广泛用于测试某个特定功能的转化率，然后选择转化率最高的版本进行最终部署。

文章插图
这种方法通常基于收集的用户行为数据，并用于做出更好的业务决策。在 A/B 测试期间，用户通常不会被告知新功能，以便进行真实的测试，并可以比较使用旧版本和新版本的用户之间的体验。由于额外的测试期和用户体验分析，使用 A/B 部署进行部署速度可能会较慢。
可以使用 Istio 和 Flagger 自动化进行 A/B 部署。
总结在本文中，我们讨论了6种常见的K8s部署策略。在决定如何部署或升级您的应用程序时，如何使用这些策略，以及使用哪些工具来实现每种策略是非常重要的。

【一文读懂Kubernetes部署策略】