K8s 底层能力相关 Checklist
理解健康检查
对于运行在 K8s 中的服务实例而言，K8s 设计了健康检查机制以确保集群中服务实例持续处于"可运行、可服务"状态。它主要通过探针（Probe）实现，由 K8s 节点本地的 agent 对 Pod 中的实例执行周期性检查，K8s 会根据健康检测的结果对不健康的实例进行摘流或重启操作。
健康检查是 K8s 与业务实例之间的约定，它本身并不能理解个性化的业务逻辑，仅仅依据探针返回结果（如 HTTP 200）判断实例是否健康，业务需要自行在健康检查接口中实现逻辑判断服务实例是否处于"可运行、可服务"状态。
K8s 原生提供三种探测方式，分别是 HTTP、TCP 和 EXEC，平台开放了 HTTP 和 TCP 两种探针，新服务默认是 HTTP 方式，下面是对 HTTP 和 TCP 两类探针适用场景的说明：
HTTP（GET）
节点本地 agent 向业务实例发送 HTTP 请求（以短连接的方式），调用 /api/health/ready，依据返回值判断是否健康，返回码 400 > code >= 200 为健康，其他返回值或者超时，均被判定为不健康。该方式能够做到 7 层探测，适用于绝大部分服务。
针对 Java 服务，微服务团队提供一个兜底的默认实现，包含通用的健康检查逻辑，接口为 /api/health/ready，默认实现只能验证基础的 HTTP 请求链路，并不包含具体的业务逻辑判断，业务上如有个性化的判断逻辑需自行实现（比如服务需要从外部加载数据到内存后才能对外提供服务，健康检查接口需要涵盖此逻辑，也就是在加载数据完成后可以正常提供服务时才返回 200）。
TCP
节点 agent 向业务实例指定端口发起 TCP 三次握手请求，握手成功则判定为健康，否则判定为不健康。该方式建议仅用于没有 Web 服务器无法处理 HTTP 请求或一些无法进行二开的开源组件，我们强烈不建议选用 TCP 探测方式，因为 TCP 协议只能体现端口是不是活着，不能体现服务内部的逻辑（常见的问题是进程内部出现了死锁，实际上已经不能对外正确提供服务了，但是 TCP 探测方式依然能够成功，K8s 无法识别服务状态快速重启 Pod 帮助业务自动恢复）。
参考文档
- Liveness, Readiness, and Startup Probes（当前部署的 K8s 版本比较老，不支持 Startup Probes）
- Configure Liveness, Readiness and Startup Probes（当前部署的 K8s 版本比较老，不支持 GRPC 探测方式）
理解存活探针
K8s 集群节点上的 agent 根据配置策略周期性地对业务容器进行探测，当探测持续失败达到阈值后，会立即对业务容器进行原地重启操作，该操作不具有全局视角，只针对探测的容器进行。
当前服务默认配置（服务粒度配置）
- 健康检查延时：300s（从容器启动开始计算，300 秒后存活探针开始工作，该配置可自定义配置）
- 存活探针最大失败次数：3（连续失败 3 次后触发重启操作，该配置可自定义配置）
- 存活探针探测周期：10s（每 10 秒钟探测一次，该配置为系统默认配置，无法自定义配置）
- 探针超时时间：1s（单次 HTTP 请求 timeout 时长，超时则被判定为请求失败，该配置为系统默认配置，无法自定义配置）
在以上默认配置下，当一个业务实例出现异常，无法正确响应健康检查，最长经过 30s，最短经过 20s，会被原地重启。
理解就绪探针
K8s 集群节点上的 agent 根据配置策略周期性地对业务实例进行探测，当探测持续失败达到阈值后，会立即将业务容器标记为不健康，随后会对实例进行解注册和摘流操作（HTTP 和 RPC 摘流行为有所不同），该操作不具有全局视角，只针对探测的容器进行。
当前服务默认配置（服务粒度配置）
- 存活探针最大失败次数：3（连续失败 3 次后触发标记为不健康，该配置可自定义配置）
- 探活探针探测周期：3s（每 3 秒钟探测一次，该配置为系统默认配置，无法自定义配置）
- 探针超时时间：1s（单次 HTTP 请求 timeout 时长，超时则被判定为请求失败，该配置为系统默认配置，无法自定义配置）
在以上默认配置下，当一个业务实例出现异常，无法正确响应健康检查，最长经过 9s，最短经过 6s，会被标记为不健康，进而被解注册和摘流。