那些网站能够做推广线下推广方式

#作者：曹付江

前言

深入了解就绪探针、PodDisruptionBudgets 和滚动更新，确保您的部署顺利、可控，并且不会导致应用程序宕机。

本文将分析如何使用 readinessProbes、preStop、termininationGracePeriodSeconds、rollingUpdate 策略和 PodDisruptionBudgets 在 Kubernetes 上实现零宕机部署。附带的 YAML 示例可根据实际使用情况进行修改。
为什么“滚动更新 ”并不总是安全的：Kubernetes 以其滚动更新而闻名，应用一个新版本，pod 就会被逐个替换。理论上，这应该意味着零停机时间。但实际上呢？宕机还是会发生。

如果您的应用程序启动缓慢，在部分负载下出现故障，或者不能干净利落地关闭，您的用户就会感觉到。滚动更新并非灵丹妙药。如果没有正确的保障措施，Kubernetes 会将流量导向不健康的 pod、一次性杀死过多 pod 或在最糟糕的时候允许中断。

本篇文章介绍如何利用三个功能强大（但经常被误解）的工具，深入探讨真正零停机
部署的机制：

• 就绪探测器
• PodDisruption 预算
• 滚动更新策略

1. 滚动更新策略： 基础知识（和陷阱）

默认情况下，Kubernetes 会使用 RollingUpdate 策略用新的 pod 替换旧的 pod。具体如下

strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 1

这意味着Kubernetes 会在更新过程中额外启动 1 个 pod（maxSurge） 在推出过程中，每次会关闭 1 个 pod（maxUnavailable）
问题所在Kubernetes 默认认为 pod 已 “就绪”，除非您另有指示。因此，它可能会提前开始将流量路由到您的 pod：

• 应用程序在某个端口上监听
• 数据库连接已建立
• 缓存预热

2. 准备就绪探测器： 准备就绪前不要服务

准备就绪探测器告诉 Kubernetes：“先不要向这里发送流量”。这是部署工具包中最简单却最强大的工具之一。
下面是一个例子：

readinessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 5periodSeconds: 10failureThreshold: 3

该配置每 10 秒检查一次 /healthz。如果它连续失败 3 次，Kubernetes 就会停止路由流量到 pod。

最佳实践：

• 将就绪状态与实际应用就绪状态挂钩： 数据库连接、缓存、依赖关系。
• 除非应用程序真的准备就绪，否则不要只返回 200 OK。
• 在不同环境中使用相同的 /healthz 端点以保持一致性。

3. PodDisruptionBudgets： 防止自愿驱逐

PodDisruptionBudget (PDB) 可确保在自愿中断期间（如节点耗尽或滚动部署）有最低数量的 pod 可用。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:name: my-app-pdb
spec:minAvailable: 2selector:matchLabels:app: my-app

该配置每 10 秒检查一次 /healthz。如果它连续失败 3 次，Kubernetes 就会停止路由流量到 pod。

该 PDB 保证至少有 2 个 pod 始终可用。如果可用的 pod 较少，Kubernetes 会延迟中断。为何重要：如果没有 PDB，节点耗尽可能会一次性驱逐所有 pod。再加上糟糕的就绪状态探测，就会导致宕机。

4. 优雅关机： 不要在请求中中断

当 Kubernetes 决定停止一个 pod 时，它会发送 SIGTERM 信号
等待终止时间（termininationGracePeriodSeconds）如果应用程序没有及时退出，则发送 SIGKILL 信号，您可以添加一个 preStop 钩子来延迟关闭，直到处理完飞行中的请求：

lifecycle:，preStop:exec:command: ["sh", "-c", "sleep 10"]
terminationGracePeriodSeconds: 15

Kubernetes 发送 SIGTERM → 开始 15 秒倒计时，preStop 休眠 10 秒，在 Kubernetes 发送 SIGKILL 之前，应用程序现在还有 5 秒钟时间优雅关闭，替换休眠以耗尽连接、耗尽飞行中请求并清理。

5. 将它们组合在一起： 零停机蓝图

让我们将所有内容整合到一个经过实战检验的部署策略中，在不影响推出安全性的前提下优先考虑可用性。

strategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 0readinessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 5periodSeconds: 10lifecycle:preStop:exec:command: ["sh", "-c", "sleep 10"]
terminationGracePeriodSeconds: 30
添加一个 PodDisruptionBudget:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:name: my-app-pdb
spec:minAvailable: 2selector:matchLabels:app: my-app

逐步说明：
•maxSurge：1：推出期间只创建一个额外的 pod，允许新版本在不影响当前流量的情况下启动。
•maxUnavailable： 0：确保在新的 pod 完全启动和就绪之前，不会移除任何 pod，从而保证零停机时间。
•readinessProbe： 充当看门人。只有当 pod 通过健康检查时，它才会开始接收流量，从而保护用户免受半初始化容器的影响。
•preStop + terminationGracePeriodSeconds： 关闭时，每个 pod 会获得 30 秒的缓冲时间。preStop 钩子会在这 30 秒宽限期内引入一个延迟（睡眠 10 秒），以允许：
•完成飞行中的请求
•负载平衡器从容脱离
•必要时执行清理任务
•PodDisruptionBudget： 通过确保至少 2 个 pod 始终处于就绪状态，在节点耗尽、群集自动缩放和手动驱逐期间确保可用性。
为何有效，这种配置实现了平衡：
•平滑推出（滚动更新，而不是一次性更新）
•可预测的行为（限制浪涌和中断）
•零未处理流量损失（得益于就绪探测器+预停止钩子）
•保证最低可用性（PDB 可防止意外中断）
•如果你的目标是在部署过程中实现零用户停机时间，即使节点正在回收、自动扩展或更新，你也希望在生产中采用这种设置。

6.结论

零停机时间并不只是巧妙的配置，而是要为 Kubernetes 完成其工作安排合适的条件。通过分层
•准备就绪探测器，发出真正准备就绪的信号。
•PodDisruptionBudgets 可避免有风险的中断。
•经过深思熟虑的激增/不可用滚动策略。
•生命周期钩子，实现优雅停机。
…您可以自信地说，您的推出不会导致应用程序宕机。