如何配置Minikube部署/服务,确保滚动更新时本地端点可用?
解决滚动更新时端点不可用的配置修改方案
你的Deployment已经设置了maxUnavailable: 0,理论上不该出现服务中断,但实际仍有短暂不可用,核心原因是Kubernetes默认只检查容器是否启动,不会验证服务是否真正就绪——新Pod刚启动(容器运行但服务未完成初始化)就被加入Service端点,同时旧Pod被终止,请求落到未就绪的新Pod上就会失败;另外旧Pod可能没有优雅终止,直接被杀死导致正在处理的请求中断。
需要修改以下几处配置:
1. 添加就绪探针(Readiness Probe)
就绪探针会定期验证Pod内的服务是否真正能处理请求,只有探针成功后,Pod才会被加入Service的端点列表。对于Spring Boot应用,优先用Actuator的健康检查端点,没有Actuator的话可以用自定义的健康接口。
示例配置:
readinessProbe: httpGet: path: /actuator/health # 替换为你的健康检查路径,比如/health port: 8080 initialDelaySeconds: 10 # 容器启动后多久开始第一次检查,根据应用启动时长调整 periodSeconds: 5 # 检查间隔 failureThreshold: 3 # 连续失败多少次标记为未就绪
2. 添加存活探针(Liveness Probe)
存活探针用于检测Pod是否存活,若失败会自动重启Pod。虽不直接解决滚动更新中断,但能确保不健康的Pod被及时替换,间接提升服务稳定性。
示例配置:
livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 20 # 比就绪探针晚启动,确保服务完全初始化 periodSeconds: 10 failureThreshold: 3
3. 配置优雅终止参数
默认情况下,Kubernetes发送终止信号后会立即杀死容器。添加terminationGracePeriodSeconds给Pod留足处理现有请求的时间,配合preStop钩子让应用优雅关闭(比如停止接收新请求、等待现有请求完成)。
示例配置:
terminationGracePeriodSeconds: 30 # 给30秒处理请求和关闭流程 lifecycle: preStop: exec: command: ["sh", "-c", "sleep 5"] # 简单方案:给负载均衡器留时间移除该Pod;Spring Boot 2.3+可使用内置优雅关闭逻辑
4. 确认滚动更新参数(当前配置无需修改)
你当前的maxSurge: 1和maxUnavailable: 0是正确的,确保更新过程中始终有至少2个可用Pod(对应replicas=2),保持现有配置即可。
修改后的完整Deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: spring-boot-k8s spec: replicas: 2 selector: matchLabels: app: spring-boot-k8s strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: metadata: labels: app: spring-boot-k8s spec: terminationGracePeriodSeconds: 30 # 新增:优雅终止时长 containers: - name: spring-boot-k8s image: springboot-k8s-demo:1.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 readinessProbe: # 新增:就绪探针 httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 10 periodSeconds: 5 failureThreshold: 3 livenessProbe: # 新增:存活探针 httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 20 periodSeconds: 10 failureThreshold: 3 lifecycle: # 新增:预停止钩子 preStop: exec: command: ["sh", "-c", "sleep 5"]
额外注意事项
- 若未启用Actuator,将
path替换为你自己的健康检查接口(比如返回200状态码的/health)。 - 根据应用实际启动时间调整
initialDelaySeconds,确保服务完全就绪后再开始探测。 - 测试滚动更新时,可用
kubectl rollout status deployment/spring-boot-k8s跟踪进度,同时用curl或压测工具持续访问端点验证可用性。
内容的提问来源于stack exchange,提问作者peter123
相关产品推荐
相关产品推荐

