Kubernetes 的部署基本上都是默认滚动式的,并且保证零宕机,但是它是有一个前置条件的。正是这个前置条件让零宕机部署表现为一个恼人的问题。为了实现 Kubernetes 真正的零宕机部署,不中断或不丢失任何一个运行中的请求,我们需要深入应用部署的运行细节并找到根源进行深入的根源分析。本篇的实践内容继承之前的知识体系,将更深入的总结零宕机部署方法。
刨根问底
滚动更新
我们首先来谈谈滚动更新的问题。根据默认情况,Kubernetes 部署会以滚动更新策略推动 Pod 容器版本更新。该策略的思想就是在执行更新的过程中,至少要保证部分老实例在此时是启动并运行的,这样就可以防止应用程序出现服务停止的情况了。在这个策略的执行过程中,新版的 Pod 启动成功并已经可以引流时才会关闭旧 Pod。
Kubernetes 在更新过程中如何兼顾多个副本的具体运行方式提供了策略参数。根据我们配置的工作负载和可用的计算资源,滚动更新策略可以细调超额运行的 Pods(maxSurge)和多少不可用的 Pods (maxUnavailable)。例如,给定一个部署对象要求包含三个复制体,我们是应该立即创建三个新的 Pod,并等待所有的 Pod 启动,并终止除一个 Pod 之外的所有旧 Pod,还是逐一进行更新?下面的代码显示了一个名为 Demo 应用的 Deployment 对象,该应用采用默认的 RollingUpdate 升级策略,在更新过程中最多只能有一个超额运行的 Pods(maxSurge)并且没有不可用的 Pods。
kind: Deployment
apiVersion: apps/v1
metadata:
name: demo
spec:
replicas: 3
template: