一文读懂Kubernetes部署策略

在这篇文章中,我们将深入研究 Kube.NETes 部署概念和一些常见策略,了解每种策略的优缺点 。合适的部署策略使我们能够在发布应用程序时最大限度地减少停机时间、增强客户体验并提高可靠性 。
什么是 Kubernetes 部署策略?Kubernetes 部署是一种声明性语句,通常在 YAML 文件中配置,用于定义应用程序生命周期以及如何管理对该应用程序的更新 。
当将应用程序部署到 K8s 集群时,所选择的部署策略将决定如何将应用程序从旧版本更新到新版本 。某些策略可能会导致停机时间,而其他策略则可能引入测试概念并允许用户分析 。本文将介绍两种常用的基本 K8s 部署策略:

  • 重新创建(Recreating)
  • 滚动更新(Rolling)
以下策略被认为是“高级部署策略”,因为可以以多种方式控制流量的流向:
  • 蓝/绿(Blue/Green)
  • 金丝雀(Canary)
  • A/B
  • 影子部署(Shadow Deployment)
K8s 使用滚动更新策略作为默认策略,但在某些情况下可能不适用 。让我们详细讨论每种策略!
1. 重新创建部署(Recreate Deployment)重新创建部署会终止所有的 Pod,并用新版本的 Pod 替换它们 。这在旧版本和新版本的应用程序不能同时运行的情况下很有用 。使用此策略产生的停机时间取决于应用程序关闭和启动所需的时间 。由于完全替换,应用程序状态也会完全更新 。
示例如下,type=Recreate表示为重新创建
spec:replicas: 10strategy:type: Recreate
一文读懂Kubernetes部署策略

文章插图

一文读懂Kubernetes部署策略

文章插图
2. 滚动更新部署(Rolling Deployment)滚动更新是 K8s 的默认部署方式,旨在减少集群的停机时间 。滚动更新会将运行旧版本应用程序的 Pod 逐步替换为新版本 , 而无需停机 。
一文读懂Kubernetes部署策略

文章插图
为了实现这一点,要使用就绪探针(Readiness probes)
就绪探针监视应用程序何时变为可用状态 。如果探针失败,流量将不会发送到该 Pod 。这些探针用于需要在就绪之前执行部分初始化步骤的应用程序,比如数据库链接、缓存数据初始化,应用的发布注册等操作 。
一旦就绪探针检测到新版本应用程序可用,旧版本应用程序将被删除 。如果出现问题,可以停止部署并回滚到上一个版本,避免整个集群的停机时间 。由于每个 Pod 逐个替换,对于较大的集群,部署需要一定的时间 。如果在另一个部署完成之前触发了新的部署,版本将更新为新部署中指定的版本,并且尚未部署成功的先前部署版本将被忽略 。
触发滚动更新部署的条件是 Pod 规范中的某些更改,例如更新 Pod 的镜像、环境变量或标签 。可以使用命令 kubectl set image 来更新 Pod 镜像 。
yaml文件的 Spec: -> strategy: 部分可以使用两个参数来细化部署:maxSurge 和 maxUnavailable 。这两个参数可以指定为百分比或绝对数值 。当使用水平 Pod 自动缩放时,应使用百分比 。
  • maxSurge 指定部署允许同时创建的最大 Pod 数量 。
  • maxUnavailable 指定在部署期间允许不可用的最大 Pod 数量 。
例如,下面的配置要求有 10 个副本,最多同时创建 3 个副本,允许在部署期间有 1 个副本不可用:
spec:replicas: 10strategy:type: RollingUpdaterollingUpdate:maxSurge: 3maxUnavailable: 13.蓝/绿部署(Blue/Green Deployment)蓝/绿部署涉及将新的应用程序版本(绿色)与旧版本(蓝色)一起部署 。通过服务选择器对象作为负载均衡器 , 当新应用程序(绿色)经过测试和验证后 , 将流量引导到新应用程序而不是旧应用程序 。蓝/绿部署可能会造成成本增加,因为在部署期间需要启动两倍数量的应用程序资源 。
一文读懂Kubernetes部署策略

文章插图
为了实现这一点,我们需要设置一个在部署之前的服务 。例如,对于名为 web-App 的应用程序的 v1.0.0 版本的蓝色部署,yaml 文件中的服务选择器部分可能如下所示:
kind: Servicemetadata: name: web-app-01 labels:app: web-appselector:app: web-appversion: v1.0.0


推荐阅读