在配置 Kubernetes 的健康检查时，重点需要考虑两种检查方式：存活探针（Liveness Probe）和就绪探针（Readiness Probe）。存活探针用于确定容器何时需要被重启，例如，当应用程序处于死锁状态时，容器仍在运行，但无法处理新请求，此时需要重启。而就绪探针用来判断容器是否准备好处理请求，可以防止服务在尚未准备好时就开始接收流量。配置健康检查需在 Pod 的定义文件中指定，通常可以利用命令、HTTP 请求或 TCP 检查等方式来实现。在 Kubernetes 中配置健康检查是维护集群稳定性和可靠性的关键步骤。
接下来，本文将详细介绍如何配置 Kubernetes 的健康检查，包括存活探针和就绪探针的配置方法和实践范例。
一、配置存活探针
存活探针（Liveness Probe）的任务是判断容器是否还在运行。如果存活探针失败，kubelet 会杀死该容器并根据其重启策略进行处理。
1. 使用命令执行探针：
可以通过在容器内执行命令来确定容器是否活着。如果命令的返回状态码为 0，则认为探针成功。
“`yaml
livenessProbe:
exec:
command:
– cat
– /app/is_alive.txt
initialDelaySeconds: 15
timeoutSeconds: 1
“`
此示例中，livenessProbe 使用 exec 命令执行 `cat /app/is_alive.txt`，在容器启动后的 15 秒开始检测，每次检测命令超时时间为 1 秒。
2. 使用HTTP GET请求检查：
通过发送 HTTP GET 请求到容器来检查其存活状态。如果返回的 HTTP 状态码为 200-399，则认为探针成功。
“`yaml
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
timeoutSeconds: 1
“`
在上例中，存活探针通过 HTTP GET 请求 `/health` 端点进行检查，首次检测延迟为容器启动后的 15 秒，之后每次超时时间设置为 1 秒。
二、配置就绪探针
就绪探针（Readiness Probe）是用来确定容器是否已经准备好可以接受流量。如果就绪探针失败，那么该容器的 IP 地址会从服务的 Endpoints 中移除。
1. 使用命令执行探针：
与存活探针类似，可以执行一个命令来检查容器是否准备好服务请求。
“`yaml
readinessProbe:
exec:
command:
– cat
– /app/is_ready.txt
initialDelaySeconds: 5
timeoutSeconds: 1
“`
此配置示例中容器启动后的 5 秒开始执行 `cat /app/is_ready.txt` 命令作为就绪探针，超时时间为 1 秒。
2. 使用HTTP GET请求检查：
可以利用 HTTP GET 请求来检查容器是否已准备好接受客户端请求。
“`yaml
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 1
“`
在这个例子中，`/ready` 端点用作就绪探针检查，服务启动 5 秒后开始第一次探测，每次探测的超时时间为 1 秒。
三、细节配置选项说明
在配置存活和就绪探针时，有一些共同的配置选项，需要根据应用的具体情况进行细致的调整。
1. 初始延迟时间（initialDelaySeconds）：
设置探针启动前的延迟时间。这可以防止应用在启动期间即被判定为不健康。
2. 超时时间（timeoutSeconds）：
设置每次探针的响应超时时间。如果探针在该时间内没有响应，则认为探测失败。
3. 周期性检查（periodSeconds）：
定义每次执行探针检查的频率。缩短时间可以快速发现问题，但增加了系统资源的消耗。
4. 成功前需连续多少次成功（successThreshold）：
对于就绪探针，通常设置为 1。
5. 失败前需连续多少次失败（fAIlureThreshold）：
指定在重启或摘除前，探针需要连续失败的次数。这可以防止由于偶然的网络抖动导致的误判。
四、高级探针配置
高级用户可以根据自己的需要，为探针配置更加复杂的监测逻辑，以实现精确控制。
1. TCP Socket 探针：
通过建立 TCP 连接来判断容器健康状态。如果能够建立连接，则认为探针成功。
2. 特定命令行脚本：
大多数探针验证都很简单，但是有时候需要执行更复杂的检查，这时可以编写具体的脚本来实现。
五、综合示例及常见问题
最后，提供一个具体的 Pod 定义实例，集成了存活探针和就绪探针。
“`yaml
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
– name: example-container
image: k8s.gcr.io/busybox
args:
– /bin/sh
– -c
– touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
– cat
– /tmp/healthy
initialDelaySeconds: 3
periodSeconds: 5
readinessProbe:
exec:
command:
– cat
– /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
“`
在这个例子中，容器启动后会在 `tmp` 目录创建一个 `healthy` 文件，并在 30 秒后删除它。存活探针和就绪探针将检查这个文件的存在，探针每 5 秒执行一次。初始存活探针延迟 3 秒，而就绪探针延迟 5 秒。这种方式确保了我们简单地通过文件的存在与否来模拟应用的健康状况。
在设置健康检查时可能遇到的常见问题包括：
– 探针的配置参数不适合应用的启动时间导致过早或过晚的检测。
– 频繁的探针检查消耗太多系统资源，影响应用性能。
– 使用不恰当的探针类型，如利用 HTTP 探针检查不提供 HTTP 服务的应用。
总结
合理配置 Kubernetes 的健康检查对于确保应用高可用性和集群的健康至关重要。通过合理运用存活探针和就绪探针，可以有效地监控应用状态并及时采取必要的措施。此外，根据应用特性调整探针参数，可以进一步提升集群运行效率和稳定性。
相关问答FAQs：
如何在Kubernetes中配置应用的健康检查？
在Kubernetes中，可以使用不同类型的健康检查来确保应用程序的稳定运行。其中主要包括：
1. Liveness Probe（存活探针）：Liveness Probe用于指示容器是否在运行中。如果Liveness Probe失败，Kubernetes将重启容器。可以通过配置HTTP请求、TCP套接字或执行命令来设置Liveness Probe。
2. Readiness Probe（就绪探针）：Readiness Probe用于指示容器是否已经准备好接收流量。如果Readiness Probe失败，Kubernetes将从Service的Endpoint中将该实例删除。同样，可以使用HTTP请求、TCP套接字或执行命令来配置Readiness Probe。
3. Startup Probe（启动探针）：Startup Probe用于指示容器是否已经启动完成。与Liveness Probe不同的是，Startup Probe只在容器启动后执行一次。如果Startup Probe失败，Kubernetes将重启容器。
配置这些健康检查可以通过Pod模板中的`livenessProbe`、`readinessProbe`和`startupProbe`字段来完成。在这些字段中，可以设置探测请求的类型、路径、端口、间隔时间和超时时间等参数，以确保应用程序的健康状态被正确检测。通过合理配置健康检查，可以提高应用程序的稳定性和可靠性，确保它们能够正确响应服务请求。
