一、前言
应用部署在 Kubernetes(k8s)上,有些应用启动慢一些,没启动好 就又被 k8s 重启了
二、处理过程
1. 看日志
[2023-05-23 14:38:52.249]|-INFO |-[background-preinit]|-o.h.v.i.u.Version[0]|-[TID: N/A]|-HV000001: Hibernate Validator 6.1.7.Final
[2023-05-23 14:40:11.817]|-INFO |-...
2023-05-23 14:40:22 登录主机: aaaa失败!
原因:Failed to upgrade to websocket: Unexpected HTTP Response Status Code: 500 Internal Server Error
2. 看探针配置
livenessProbe:
failureThreshold: 3
initialDelaySeconds: 30
periodSeconds: 10
successThreshold: 1
tcpSocket:
port: 60001
timeoutSeconds: 1
3. 分析
- 刚开始以为 80秒左右(14:38:52.249 到 14:40:11.817),应用被重启了
- 发现和 探针配置的不一样,initialDelaySeconds + periodSeconds * failureThreshold = 60秒
- 然后发现最终结束时间应该是 14:40:22 登录主机: aaaa失败,就是 90秒左右
- 最后发现还有个 terminationGracePeriodSeconds: 30,加上探针 60秒,刚好 90秒左右。至此终于 水落石出
- 建议运维把 initialDelaySeconds 改为 60 以后,成功启动
三、总结
- 最长重启时间:initialDelaySeconds + (periodSeconds + timeoutSeconds) * failureThreshold + terminationGracePeriodSeconds(默认30秒)
- 建议 适当调大 initialDelaySeconds(如 60)、failureThreshold(如 6)、periodSeconds(如 20),总之根据上面的公式计算的时长 要大于 实际启动时长(如 本地测试)
- 配置存活、就绪和启动探针 | Kubernetes
本文首先发布于 https://www.890808.xyz/ ,其他平台需要审核更新慢一些。
标签:14,Kubernetes,启动,initialDelaySeconds,40,60,periodSeconds,k8s,failureThreshold From: https://blog.51cto.com/javalover123/6334148