我是 LEE，老李，一个在 IT 行业摸爬滚打 16 年的技术老兵。
事件背景
之前写过一片关于 k8s 3 种探针的文章，收到很多小伙伴的反馈，说太繁琐了。学习曲线太过于陡峭，希望有一篇能快速入门的文章。
技术探索
一句话说清概念
- 存活性探测 (Liveness probes): 主要是探测应用是否还活着。如果检测到应用没有存活就杀掉当前 pod 并重启;
- 就绪性探测 (Readiness probes): 只要是探测应用是否准备好接受请求访问，如果检测应用准备好了，就把请求流量放进来；反之，则把应用节点从注册中心拿掉。
- 启动探测 (Startup Probes): 对于旧应用需要更长的启动时间，这时候既不想重启应用也不想让请求访问进来，可以设置启动探测给足够的启动时间保证应用启动成功
动画展示
ReadinessProbe
Readiness Probe 的设计目的是让 Kubernetes 明确知道 Pod 何时已经完全正版就绪。在向 POD 发送请求通信之前,首先进行 Readiness Probe 测试。如果测试没有通过,Kubernetes 停止向其发送通信请求，直到测试通过。
LivenessProbe
Liveness Probe 是为了让 k8s 知道 Pod 是否存活（而不一定可用）。如果 POD 死掉，则 k8s 会将其 Remove 并启动一个新的 POD 取而代之。
麻烦的启动时间线
可以自定义在 pod 启动时是否执行这些检测，如果不设置，则检测结果均默认为通过；如果设置，则顺序为： startupProbe --> readinessProbe --> livenessProbe
(★) 但是真的是上面的顺序嘛？ 官方文档上却说不是，其中有一段说到。
Caution: Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.
翻译：livenessProbe 不会等待 readinessProbe 成功。如果你想在执行 livenessProbe 之前等待，你应该使用 initialDelaySeconds 或 startupProbe。
好了，真正的顺序是：startupProbe --> readinessProbe(livenessProbe)
(★) readinessProbe 和 livenessProbe 之间是异步并发的
