Kubernetes 健康检查的两种机制：Liveness 探测和 Readiness 探测，并实践了健康检查在 Scale Up 和 Rolling Update 场景中的应用。
kubelet使用启动探针来了解何时启动Container应用程序。如果配置了这样的探针，它将禁用活动性和就绪性检查，直到成功为止，以确保这些探针不会干扰应用程序的启动。这可用于对启动缓慢的容器进行活动检查，避免它们在启动和运行之前被kubelet杀死。
定义活动命令exec
在本练习中，您将创建一个Pod，该Pod可基于k8s.gcr.io/busybox图像运行一个Container 。这是Pod的配置文件：
pods/probe/exec-liveness.yaml apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep ; rm -rf /tmp/healthy; sleep
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds:
periodSeconds:
在配置文件中，您可以看到Pod具有单个Container。该periodSeconds字段指定kubelet应该每5秒执行一次活动性探测。该initialDelaySeconds字段告诉kubelet在执行第一个探测之前应等待5秒。为了执行探测，kubelet cat /tmp/healthy在容器中执行命令。如果命令成功执行，则返回0，并且kubelet认为Container处于活动状态且健康。如果命令返回非零值，则kubelet将杀死Container并重新启动它。
在容器寿命的前30秒中，有一个/tmp/healthy文件。因此，在前30秒内，该命令cat /tmp/healthy将返回成功代码。30秒后，cat /tmp/healthy返回失败代码。
在30秒内，查看Pod事件：
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
23s 23s {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
23s 23s {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
35秒后，再次查看Pod事件：在输出的底部，有消息指示活动性探针已失败，并且容器已被杀死并重新创建。
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
36s 36s {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
36s 36s {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
再等待30秒，并验证容器已重新启动：
kubectl get pod liveness-exec
NAME READY STATUS RESTARTS AGE
liveness-exec / Running 1m
定义活动HTTP请求
另一种活动性探针使用HTTP GET请求。这是基于k8s.gcr.io/liveness 映像运行容器的Pod的配置文件。
pods/probe/http-liveness.yaml apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port:
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds:
periodSeconds:
在配置文件中，您可以看到Pod具有单个Container。该periodSeconds字段指定kubelet应该每3秒执行一次活动性探测。该initialDelaySeconds字段告诉kubelet在执行第一个探测之前应等待3秒。为了执行探测，kubelet将HTTP GET请求发送到在Container中运行并在端口8080上侦听的服务器。如果服务器/healthz路径的处理程序返回成功代码，则kubelet认为Container处于活动状态且运行状况良好。如果处理程序返回失败代码，则kubelet将杀死Container并重新启动它。
任何大于或等于200且小于400的代码均表示成功。其他任何代码均指示失败。
您可以在server.go中查看服务器的源代码 。
在Container /healthz处于活动状态的前10秒钟中，处理程序返回状态200。此后，处理程序返回状态500。
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
duration := time.Now().Sub(started)
if duration.Seconds() > {
w.WriteHeader()
w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
} else {
w.WriteHeader()
w.Write([]byte("ok"))
}
})
容器启动后三秒钟，kubelet将开始执行运行状况检查。因此，前几次健康检查将成功。但是10秒钟后，运行状况检查将失败，并且kubelet将终止并重新启动Container。
定义TCP liveness探针
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
定义 readiness probes
有时，应用程序暂时无法为流量提供服务。例如，应用程序可能需要在启动过程中加载大数据或配置文件，或者在启动后依赖于外部服务。在这种情况下，您不想杀死应用程序，但也不想发送请求。Kubernetes提供了准备就绪探针以检测和缓解这些情况。带有容器的容器报告其容器尚未准备就绪，无法通过Kubernetes Services接收流量。
readiness的配置与liveness类似。唯一的区别是您使用readinessProbe字段而不是livenessProbe字段。
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds:
periodSeconds:
HTTP和TCP就绪性探针的配置也与活动性探针相同。
readiness和liveness可以并行用于同一容器。同时使用这两者可以确保流量不会到达尚未准备就绪的容器，并且可以确保容器在发生故障时重新启动。
