当前位置：首页 > news >正文

从零到一：K8S滚动更新与探针配置实战优化

news 2026/6/28 21:29:17

1. 为什么需要滚动更新和探针配置？

刚接触Kubernetes时，我最头疼的就是服务升级时的停机问题。记得有一次半夜做版本发布，整个服务挂了将近5分钟，报警短信直接把手机震到没电。后来才发现，问题出在没有正确配置滚动更新策略和容器探针。

Kubernetes的Deployment默认确实提供了滚动更新机制，但如果不配合适当的探针配置，很容易出现新Pod还没完全启动就被接入流量，或者旧Pod被提前终止导致请求失败的情况。这就好比换轮胎时直接把四个轮子都拆了再装新的，车子能不趴窝吗？

在实际生产环境中，我们需要做到真正的"无感知升级"，这意味着：

新版本Pod完全启动并准备好接收流量前，旧Pod继续保持服务
旧Pod只有在确认没有未完成请求时才会被终止
整个过程中始终有足够数量的Pod在提供服务

2. Deployment滚动更新策略详解

2.1 基本滚动更新配置

先来看一个典型的Deployment定义片段：

apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0

这里有几个关键参数需要理解：

maxSurge: 更新过程中允许创建的超出期望副本数的Pod数量，可以是具体数字或百分比。设置为1意味着可以比replicas多1个Pod。
maxUnavailable: 更新过程中允许不可用的Pod数量。设置为0意味着必须始终保持所有Pod可用。

我曾经在一个电商项目中犯过错误，将maxUnavailable设置为1，结果大促期间更新导致瞬间容量减少，引发了短暂的服务降级。后来调整为maxSurge=1和maxUnavailable=0的组合，更新时K8S会先启动一个新Pod，等它完全就绪后再替换一个旧Pod，如此循环直到全部更新完成。

2.2 高级更新策略

对于更复杂的场景，你可能还需要考虑：

minReadySeconds: 新创建的Pod被认为可用前的最小就绪秒数。这个参数经常被忽视，但实际上能有效避免"启动即崩溃"的情况。
progressDeadlineSeconds: Deployment进度卡住多少秒后报告失败。默认600秒，对于启动较慢的应用可能需要调大。

一个经验公式是：minReadySeconds应该大于你的应用平均启动时间+就绪探针检测间隔。比如应用启动需要30秒，就绪探针每10秒检查一次，那么minReadySeconds设置为45秒比较安全。

3. 容器探针的实战配置

3.1 存活探针(Liveness Probe)配置

存活探针用于判断容器是否在正常运行。如果探测失败，kubelet会杀死容器并根据重启策略决定是否重启。一个常见的Spring Boot应用配置示例：

livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 60 periodSeconds: 10 failureThreshold: 3

这里有几个坑需要注意：

initialDelaySeconds必须足够长，确保应用完全启动。我曾经设置为30秒，结果每次部署都被杀掉，因为Spring Boot启动实际需要45秒。
探测端点要轻量级，避免影响性能。不要用需要查询数据库的接口。
failureThreshold设置要合理，避免网络抖动导致的误杀。

3.2 就绪探针(Readiness Probe)配置

就绪探针决定Pod是否可以接收流量。与存活探针不同，就绪探针失败不会重启容器，只是从Service的Endpoint中移除。配置示例：

readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 30 periodSeconds: 5 successThreshold: 1 failureThreshold: 3

特别提醒：就绪探针的检查条件应该比存活探针更严格。比如一个需要连接数据库的应用，存活探针可以只检查进程是否存在，而就绪探针应该验证数据库连接是否正常。

3.3 启动探针(Startup Probe)的使用

对于启动特别慢的应用（如Java大型应用），K8S 1.16+引入了启动探针：

startupProbe: httpGet: path: /actuator/health/startup port: 8080 failureThreshold: 30 periodSeconds: 5

启动探针的特殊之处在于：

在启动探针成功前，其他探针都会被禁用
通常设置较大的failureThreshold，给应用足够的启动时间
启动成功后，控制权会转交给存活/就绪探针

4. 实现真正的零停机部署

4.1 优雅终止配置

即使配置了完善的探针，如果不处理终止信号，仍然可能出现请求丢失。K8S在删除Pod前会发送SIGTERM信号，我们需要确保应用正确处理这个信号。对于Spring Boot应用，可以这样配置：

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

更优雅的做法是启用Spring Boot的优雅停机功能（2.3+版本支持）：

server.shutdown=graceful spring.lifecycle.timeout-per-shutdown-phase=30s

这样应用收到SIGTERM后：

停止接收新请求
等待现有请求完成（最长30秒）
关闭容器

4.2 完整的部署配置示例

下面是一个经过实战检验的完整Deployment配置：

apiVersion: apps/v1 kind: Deployment metadata: name: order-service spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 minReadySeconds: 45 template: spec: containers: - name: app image: order-service:1.2.0 ports: - containerPort: 8080 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 30 periodSeconds: 5 timeoutSeconds: 1 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 60 periodSeconds: 10 startupProbe: httpGet: path: /actuator/health/startup port: 8080 failureThreshold: 30 periodSeconds: 5 lifecycle: preStop: exec: command: ["sh", "-c", "sleep 15"]

这套配置在多个生产环境中验证过，能够实现真正的无感知升级。关键点在于：

滚动更新策略确保始终有可用实例
三层探针机制覆盖应用全生命周期
优雅终止处理保证请求不丢失
合理的超时和等待设置适应应用特性

5. 常见问题排查技巧

5.1 探针调试方法

当探针配置不当时，可以使用这些命令排查：

# 查看Pod详情，重点关注Conditions和Events部分 kubectl describe pod <pod-name> # 查看容器日志 kubectl logs <pod-name> -c <container-name> # 进入容器手动执行探针检查 kubectl exec -it <pod-name> -- curl http://localhost:8080/actuator/health