一、前言

利用部署在 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/ ，其余平台须要审核更新慢一些。