K8s Liveness/Readiness/Startup 探针机制
官方参考文档
目录
-
- 前言
- 一、默认健康检测
-
- 1.1 restartPolicy
- 1.2 测试案例
- 二、Liveness
- 三、Readiness
- 四、Startup
前言
玩过 Docker Swarm 的应该都知道，有一种功能叫自愈功能，当集群检测到节点或服务故障时回进行自动故障转移，从而保障业务的可用性。而 K8s 集群相对于其他集群体系，其自愈能力更加强大，这也是 K8s 容器编排引擎的一重要特性。自愈从某种角度上来讲，其实现了以下几几种功能特性：
- 零停机部署；
- 避免无效镜像；
- 实现滚动升级与回退。
K8s 有三种探针，分别是：存活（Liveness）、就绪（Readiness）和启动（Startup）
-
存活（Liveness）：kubelet 使用存活探针来确定什么时候要重启容器。 例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
-
就绪（Readiness）：kubelet 使用就绪探针可以知道容器何时准备好接受请求流量。当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
-
启动（Startup）：kubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查， 确保这些存活、就绪探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。
K8s 探针有三种探测方式，分别是：ExecAction、HTTPGetAction 和 TCPSocketAction。
注意，这三种探测方式只能同时使用一种，不能两种或三种同时使用。
- ExecAction：在容器中执行指定的命令，如果执行成功，退出码为0则探测成功。
- HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。
- TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。
探针探测的结果有以下值：
- Success：表示通过检测。
- Failure：表示未通过检测。
- Unknown：表示检测没有正常进行。
一、默认健康检测
1.1 restartPolicy
了解 Docker 的都知道，每个容器启动时都会执行一个进程，该进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果进程退出或返回状态码为非零时，则认为容器发生故障，这个时候 K8s 就会根据 restartPolicy 重启容器。restartPolicy 有三种重启策略：
-
Always
Pod 中容器不论如何停止都将自动重启；
-
OnFailure
Pod 中容器非正常停止会自动重启，正常停止不会重启； -
Never
Pod 中容器不论以任何方式停止，都不会自动重启。
K8s 的 restartPolicy 默认为 Always。如果探针超过失败重试的次数，则 Pod 就会根据 restartPolicy 策略进行选择是否重启。
1.2 测试案例
1、创建一个 Pod
apiVersion: v1
kind: Pod
metadata:
labels:
test: healthcheck
name: healthcheck
spec:
restartPolicy: OnFailure
containers:
- name: healthcheck
image: busybox
args:
- /bin/sh
- -c
- sleep 10;exit 1
2、观察 Pod 状态
这个容器启动 10s 后会发生故障，接下来执行 kubectl apply 创建 Pod，Pod Name 为 healthcheck。过几分钟后看看 Pod 的状态：
可看到已经重启了三次，该案例中容器进程返回值为非零，k8s 则认为容器发生故障，需要重启。但可能有些情况下发生了故障进程不退出的现象，如访问 Web 服务器时返回 500 错误代码，这可能是系统负荷较大或资源锁死，此时 httpd 进程并没有异常退出，这种情况下可直接重启容器。而 K8s 的 Liveness 机制刚好能解决此类问题（即出现此类问题会直接 Kill 掉容器并重新启动）。
二、Liveness
Liveness 探针让用户可以自定义判断容器是否健康的条件，如果探测失败，K8s 就会重启容器，如下案例：
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
在这个配置文件中，可以看到 Pod 中只有一个 Container。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒（即 5 秒后才开始启动探针）。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。当容器启动时，会执行如下的命令：
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600"
这个容器生命的前 30 秒，/tmp/healthy 文件是存在的。 所以在这最开始的 30 秒内，执行命令 cat /tmp/healthy 会返回成功代码。 30 秒之后，执行命令 cat /tmp/healthy 就会返回失败代码。
执行 kubectl apply 创建 Pod 。
kubectl apply -f liveness.yml
查看 Pod 启动日志：
kubectl describe pod liveness-exec
前 30s /tmp/healthy 文件是存在的：
35s 后检测到/tmp/healthy 文件已经不存在：
再过十几秒后容器被重启：
三、Readiness
除了可以自定义判断容器是否健康的条件外，用户也可以通过 Readiness 探针告诉 K8s 什么时候可以重启容器实现自愈，Readiness 探针则告诉 K8s 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。就绪探针的配置和存活探针的配置相似。 唯一区别就是要使用 readinessProbe 字段，而不是 livenessProbe 字段。
apiVersion: v1
kind: Pod
metadata:
labels:
test: readiness
name: readiness-exec
spec:
containers:
- name: liveness
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
看看启动日志，与 Liveness 探针类似
kubectl describe pod readiness-exec
Probe 有很多配置字段，可以使用这些字段精确地控制启动、存活和就绪检测的行为：
initialDelaySeconds：容器启动后要等待多少秒后才启动启动、存活和就绪探针， 默认是 0 秒，最小值是 0。periodSeconds：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。successThreshold：探针在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。failureThreshold：当探测失败时，Kubernetes 的重试次数。 对存活探测而言，放弃就意味着重新启动容器。 对就绪探测而言，放弃意味着 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
注意：存活探针 不等待 就绪性探针成功。如果要在执行存活探针之前等待就绪性探针，应该使用 initialDelaySeconds 或 startupProbe。
四、Startup
Startup 是 k8s 1.16+ 版本后新加的探测方式，用于判断容器内应用程序是否已经启动，如果同时配置了 startuprobe、Livenessprobe、Readinessprobe，K8s 就会先禁用其他的探针，而首先使用 startuprobe 探测直到它成功为止，成功后将不再进行探测。
startupProbe 探针与另两种区别？
-
如果三个探针同时存在，先执行startupProbe探针，其他两个探针将会被暂时禁用，直到pod满足startupProbe探针配置的条件，其他2个探针启动，如果不满足按照规则重启容器。
-
另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而startupProbe探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。
那 Startup 存在的意义又是什么呢？
试想一个问题，如果启动一个服务需要 1 分钟，如果没有 Startup 的情况下，且假设我们配置了 livenessProbe 探针，具体如下：
livenessProbe:
httpGet:
path: /test
prot: 80
failureThreshold: 6
initialDelay：40
periodSeconds: 5
我们设置了失败重试次数为 6，每 5 秒探测一次，加上我们探测前等待的 40 秒，总时间就是：40 + 6 x 5 = 70s，这样 Pod 确实能够启动起来。那问题又来了，如果这个配置用于生产配置上，将会导致我们比较晚的收到服务不可用的情况，也就是说我的服务可能在 5s 时已经不可用，但是由于我们探测机制（有 6 次失败重试的机会），我们在至少 6 x 5 = 30s 才会发现服务不可用的情况，这在生产上一般是不被允许的。那该如何解决类似这样的问题呢？答案是 startupProbe。
注意上面这个案例，如果
failureThreshold设置为 1 或 2，那这个服务是永远起不起来的，因为你把initialDelay的时间算上也不足 1 分钟，因为我们说启动至少需要 1 分钟，那超过失败重试次数后，就会根据 Pod 的restartPolicy来重启容器。
接着我们引入 startupProbe，继续优化：
livenessProbe:
httpGet:
path: /test
prot: 80
failureThreshold: 1
initialDelay：5
periodSeconds: 5
startupProbe:
httpGet:
path: /test
prot: 80
failureThreshold: 60
initialDelay：5
periodSeconds: 5
前面说了，startupProbe 会在探测成功后停止探测，而其他两种探针则是随着 Pod 的生命周期一直在探测的。因此上面的配置功能就是：K8s 部署服务后会在 5s 后启动 startupProbe，在 5 x 60 = 300s 的时间内只要成功探测到服务则停止探测（否则需接受 Pod 的重启策略进行重启），并启用 livenessProbe 探针，此时livenessProbe 探针就会伴随着 Pod 的生命周期每 5s 检测一次，且我们只设置了 1 次失败重试的机会，这就意味着我们只需要在 1 x 5 = 5s 时间就可以发现服务不可用。因此，你配置了 startupProbe，那其他2种探针如果配置了initialDelaySeconds，建议时间就不要给太长。这就是 Startup 探针存在的意义。