本文介绍了 Kubernetes 中的就绪和活跃度探测，以及如何为容器配置它们。
什么是 Kubernetes 中的探针
由于多种原因，应用程序可能会变得不可靠。 您需要确保应用程序处于所需状态。 Kubernetes 提供了一种检查容器健康状况的方法。 这种健康诊断称为探测。
探测容器的方法
kubelet 使用以下方式之一在其容器上完成探测：
1.执行
Kubelet 在容器内执行命令。 结果取决于命令的退出代码。 退出代码 0 表示诊断成功。
2.http获取
Kubelet 发送一个 GET 请求到容器IP地址的指定端口。 200 到 400（含）之间的响应代码表示诊断成功。
3. TCP套接字
Kubelet 尝试在容器 IP 地址的指定端口上建立 TCP 连接。 已建立的连接表示诊断成功。
探头类型
Kubernetes 中有三种类型的探针：
活性探针
就绪探测
启动探针
启动探测器是最近添加到此列表中的，本文不对其进行讨论。
活性探针
liveness probe 检测容器是否存活。 这用于确保 pod 的可用性。 如果 liveness 探测成功，kubelet 什么都不做，因为容器已经处于所需状态。 如果失败，kubelet 将终止容器，进一步的操作过程取决于指定的 重启政策 的容器。
为什么要使用 Liveness Probe？
Kubelet 通过查看容器的状态来检查容器的健康状况 PID 1. 问题是状态 PID 1 不反映容器子进程的健康状况。 如果您只有一个进程容器，则无需指定活性探测器。 否则，您应该使用活性探针。
就绪探测
就绪探测器检测容器是否准备好为传入的网络请求提供服务。 您不想将流量发送到尚未准备好运行的 pod。 如果就绪探测失败，控制面板会停止到 pod 的网络流量。 在 pod 上运行第一个就绪探测之前，默认就绪状态设置为 Failure. 就绪探测在容器的整个生命周期内定期在容器上运行。
为什么要使用就绪探针？
一旦所有子进程启动，网络流量就应该被发送到容器。 如果没有就绪探测，Kubernetes 会尽快将网络流量发送到容器 PID 1 开始。 这并不意味着子进程已经启动。 在此状态下向容器发送网络流量可能会导致错误。 每次容器重新启动或创建应用程序的新实例时，应用程序都会遇到错误。
如何在 Kubernetes 中配置探针
在里面定义了一个探针 pods.spec.containers 场地。 每个探针都有以下五个参数：
初始延迟秒数：这指定了容器启动后等待探测运行的时间（以秒为单位）。 默认值为 0。
期间秒：这指定了每个周期性探测之间的时间间隔。 默认值为 10。
超时秒数：这指定了每个探测必须等待获得响应的时间。 默认值为 0。
成功门槛：这指定指示成功诊断的成功探测的计数。 默认值为 1。
失败阈值：这指定指示诊断失败的失败探测的计数。 默认值为 3。
所有这些参数都用于配置探测器。 要遵循本指南，您需要配置 Kubernetes 集群和 kubectl 客户端。 您可以使用 Vultr Kubernetes Engine 在云端部署 Kubernetes 集群并测试探针。 配置 kubectl 在你的机器上并跟随。
创建一个活性探测器
看下面的配置文件：
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-demo
spec:
containers:
- name: basic-container
image: registry.k8s.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 20; rm -f /tmp/healthy; sleep 1000
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 10
此配置创建了一个容器 pod 并定义了一个 liveness probe。 该探头使用 exec 进行诊断。 创建容器后， touch /tmp/healthy; sleep 20; rm -f /tmp/healthy; sleep 100 命令被执行。 该命令将：
创建一个
/tmp/healthy文件等待 20 秒。
删除
/tmp/healthy文件。让容器再存活 1000 秒。
注意 livenessProbe 下的字段 containers 场地。 这是您定义活性探测器的地方。 这里liveness probe会在容器创建后等待5秒，以10秒的时间间隔开始周期性诊断。 它使用 exec 方式执行探测。 如果命令 cat /tmp/healthy 返回0，探测成功。
创建吊舱：
kubectl apply -f config.yaml
检查 pod 的事件：
kubectl describe liveness-demo
在输出的末尾，您可以看到类似以下内容：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25s default-scheduler Successfully assigned default/liveness-demo to probescluster-3a397dd3c5ec
Normal Pulling 25s kubelet Pulling image "registry.k8s.io/busybox"
Normal Pulled 22s kubelet Successfully pulled image "registry.k8s.io/busybox" in 3.292188263s
Normal Created 22s kubelet Created container basic-container
Normal Started 22s kubelet Started container basic-container
到目前为止，pod 健康且正在运行。 25 秒后，再次查看 pod 的事件：
kubectl apply -f config.yaml
你可以期待看到类似的东西：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 56s default-scheduler Successfully assigned default/liveness-demo to probescluster-3a397dd3c5ec
Normal Pulling 55s kubelet Pulling image "registry.k8s.io/busybox"
Normal Pulled 52s kubelet Successfully pulled image "registry.k8s.io/busybox" in 3.292188263s
Normal Created 52s kubelet Created container basic-container
Normal Started 52s kubelet Started container basic-container
Warning Unhealthy 5s (x3 over 25s) kubelet Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal Killing 5s kubelet Container basic-container failed liveness probe, will be restarted
从输出中可以看到，5秒前，liveness探测失败，提示kubectl重启容器。 现在，检查 pod 的状态：
kubectl get pod liveness-demo
预期输出：
NAME READY STATUS RESTARTS AGE
liveness-demo 1/1 Running 1 (4s ago) 85s
请注意， 重启 现场表演 1 这确认容器已重新启动。
配置就绪探测器
配置就绪探针类似于配置活性探针。 您可以通过在配置文件中添加以下内容来创建类似的准备检查探测器 pods.spec.containers 场地。
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 10
结论
本文介绍了 Kubernetes 的活跃度和就绪度探测器、它们的用途以及如何配置它们。 要了解更多信息，请参阅 配置 Liveness、Readiness 和 Startup Probe 在 kubernetes.io。
文章标题 名称（可选） 电子邮件（可选） 描述
发送建议
注：本教程在Vultr VPS上测试通过，如需部署请前往Vultr.com
