在 Kubernetes 环境中，Probes 是用来检测容器内应用程序的状态的工具。具体来说，有两种类型的 Probes：Liveness 和 Readiness，它们用于确保服务按预期运行。
Liveness Probes
Liveness Probes 用来判断容器是否在运行。如果 Liveness Probe 失败，Kubernetes 会认为该容器已经死亡，这时候 Kubernetes 的 kubelet 将会重启该容器。使用 Liveness Probe 的目的是捕捉到应用程序陷入死锁的情况，无法正常工作，但进程还在运行。
使用场景：
- 应用程序陷入死循环
- 死锁
- 任何导致进程不响应的情况，但进程本身还没有退出
Readiness Probes
Readiness Probes 确定容器是否准备好接受流量。只有当 Readiness Probe 报告成功时，服务才会开始向该容器发送请求。如果一个 Pod 的容器未通过 Readiness Probe，那么该 Pod 将从 Service 的负载均衡中移除。
使用场景：
- 等待外部依赖如数据库、缓存等
- 应用程序正在加载大量的初始数据
- 动态配置加载
使用技巧
- 设置合适的检查间隔：
- 间隔太短可能会对容器内的应用程序或外部服务造成不必要的压力。
- 间隔太长可能会导致故障恢复不及时。
- 合理配置启动时间：
- 对于需要较长时间启动的应用，应适当延长
initialDelaySeconds的时间，以免在应用未完全启动之前就被 Kubernetes 认为是不健康的。
- 对于需要较长时间启动的应用，应适当延长
- 利用成功和失败阈值：
- 可以设置
failureThreshold和successThreshold来确定失败或成功的连续次数，以防止由于临时的问题而过早地重启应用。
- 可以设置
- 区分 Readiness 和 Liveness：
- 避免使用相同的检查作为 Liveness 和 Readiness Probe，因为启动就绪不一定意味着健康，反之亦然。
- 注意 Probe 路径的选择：
- 对于 HTTP 探针，选择不需要太多资源即可响应的路径，例如
/healthz，这样可以避免探针调用对应用造成影响。
- 对于 HTTP 探针，选择不需要太多资源即可响应的路径，例如
- 利用 exec 和 tcpSocket：
- 如果应用不提供 HTTP/S 接口，可以使用
exec命令或tcpSocket检查。
- 如果应用不提供 HTTP/S 接口，可以使用
实际使用案例
假设我们有一个 Web 应用程序，需要一段时间来加载数据，在这个过程中不应该接受流量。同时，应用程序可能会由于内部错误进入死锁状态，我们希望能够自动重启。
示例代码：
代码语言：javascript复制apiVersion: v1
kind: Pod
metadata:
name: my-web-application
spec:
containers:
- name: web-container
image: my-web-application:1.0
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
timeoutSeconds: 2
periodSeconds: 5
failureThreshold: 1
readinessProbe:
httpGet:
path: /readiness
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 2
periodSeconds: 5
successThreshold: 1
在这个配置中：
- Liveness Probe:
- 当
/healthz端点失败时（即应用程序死锁或崩溃），在 15
- 当
秒的启动延迟后，每 5 秒检查一次。
- 如果探针失败，kubelet 会立即重启容器（
failureThreshold为 1）。 - Readiness Probe:
- 应用启动 5 秒后，每 5 秒检查一次
/readiness端点，以确保应用已经准备好接收流量。 - 一旦探针成功，容器将接受流量（
successThreshold为 1）。
- 应用启动 5 秒后，每 5 秒检查一次
这个配置确保了在容器启动初期，如果应用程序未准备好，它不会接收流量；如果应用程序运行期间出现问题，它能够快速重启。
