容器探针-健康检查
官网
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
容器探针
甲探头是通过周期性地执行的诊断 kubelet 上的容器。为了执行诊断，kubelet 调用容器实现的 Handler。有三种类型的处理程序：
- ExecAction：在容器内执行指定的命令。如果命令退出时状态代码为 0，则认为诊断成功。
- TCPSocketAction：对指定端口上 Pod 的 IP 地址执行 TCP 检查。如果端口打开，则认为诊断成功。
- HTTPGetAction：
GET在指定的端口和路径上针对 Pod 的 IP 地址执行 HTTP请求。如果响应具有大于或等于 200 且小于 400 的状态代码，则认为诊断成功。
每个探针具有以下三个结果之一：
Success：容器通过了诊断。Failure：容器未通过诊断。Unknown：诊断失败，因此不应采取任何措施。
kubelet 可以选择对正在运行的容器执行三种探测并做出反应：
livenessProbe：表示容器是否正在运行。如果活性探测失败，kubelet 会杀死容器，并且容器会受到其重启策略的约束。如果 Container 不提供活性探测，则默认状态为Success。readinessProbe：表示容器是否准备好响应请求。如果就绪探测失败，端点控制器会从与 Pod 匹配的所有服务的端点中删除 Pod 的 IP 地址。初始延迟之前的默认就绪状态是Failure。如果 Container 不提供就绪探测，则默认状态为Success。startupProbe：表示容器内的应用程序是否启动。如果提供了启动探测器，则所有其他探测器都将被禁用，直到它成功。如果启动探测失败，kubelet 会杀死容器，并且容器会受到其重启策略的约束。如果 Container 不提供启动探测器，则默认状态为Success。
有关如何设置活动、就绪或启动探测器的更多信息，请参阅配置活动、就绪和启动探测器。
什么时候应该使用活性探针？
功能状态： Kubernetes v1.0 [stable]
如果您的容器中的进程在遇到问题或变得不健康时能够自行崩溃，则您不一定需要活性探测；kubelet 会根据 Pod 的restartPolicy.
如果您希望容器在探测失败时被restartPolicy终止并重新启动，则指定一个活跃度探测，并指定Always 或 OnFailure。
什么时候应该使用就绪探针？
功能状态： Kubernetes v1.0 [stable]
如果您想仅在探测成功时才开始向 Pod 发送流量，请指定就绪探测。在这种情况下，就绪探针可能与活性探针相同，但是规范中存在就绪探针意味着 Pod 将在不接收任何流量的情况下启动，并且只有在探针开始成功后才开始接收流量。
如果您希望您的容器能够自行关闭以进行维护，您可以指定一个准备就绪探测器，用于检查与活跃度探测器不同的特定于准备状态的端点。
如果您的应用严格依赖后端服务，您可以同时实现活跃度和就绪度探测。当应用程序本身健康时，活性探测通过，但就绪探测会额外检查每个所需的后端服务是否可用。这有助于您避免将流量定向到只能以错误消息响应的 Pod。
如果您的容器需要在启动期间加载大数据、配置文件或迁移，您可以使用 启动探测器。但是，如果您想检测失败的应用程序和仍在处理其启动数据的应用程序之间的差异，您可能更喜欢就绪探测。
注意：如果你想在 Pod 被删除的时候能够 Drain 请求，你不一定需要准备就绪探针；删除时，无论是否存在就绪探针，Pod 都会自动将自身置于未就绪状态。在等待 Pod 中的容器停止时，Pod 保持未就绪状态。
什么时候应该使用启动探针？
功能状态： Kubernetes v1.20 [stable]
启动探针对于具有需要很长时间才能投入使用的容器的 Pod 很有用。您可以配置单独的配置来在容器启动时对其进行探测，而不是设置较长的活跃时间间隔，从而允许比活跃时间间隔更长的时间。
如果您的容器通常在 多个 开始 initialDelaySeconds + failureThreshold × periodSeconds，您应该指定一个启动探针来检查与 liveness 探针相同的端点。默认为 periodSeconds10 秒。然后，您应该将其设置failureThreshold得足够高以允许容器启动，而无需更改活性探测器的默认值。这有助于防止死锁。
健康检查方式
存活性探测
就绪性健康检查:检查容器是否能够对外提供服务
存活性健康检查:检查容器是否正常运行
两者维度不一样
两者处理方式不一样：
存活性检查失败：把容器删掉
就绪性检查失败：移除集群（移除负载均衡）
用于判断容器是否存活，即Pod是否为running状态，如果LivenessProbe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略判断按照那种方式重启，如果一个容器不包含LivenessProbe探针，则Kubelet认为容器的LivenessProbe探针的返回值永远成功。存活性探测支持的方法有三种:ExecAction，TCPSocketAction，HTTPGetAction。
1.Exec
apiVersion: v1
kind: Pod
metadata:
name: probe-exec
namespace: defualt
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
exec:
command:
- cat
- /tmp/health
initialDelaySeconds: 30 # 初始化时间
successThreshold: 1 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
2.TCPSocket
# TcpSocket 相当于 ping
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
namespace: default
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 30 # 初始化时间
successThreshold: 1 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
3.HTTPGet
apiVersion: v1
kind: Pod
metadata:
name: probe-http
namespace: default
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
httpGet:
path: /index
port: 80
scheme: HTTP
initialDelaySeconds: 30 # 初始化时间
successThreshold: 1 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
4.参数详解
# 检查失败最少测试，默认：3
kubectl explain deployment.spec.template.spec.containers.livenessProbe
delay=10s : 探测延时时间initialDelaySeconds
timeout=1s ：探测的超时时间
period=10s ：探测的频率
success=1 ：成功多少次才算成功
failure=1 ：失败多少次才算失败
参数详解：
failureThreshold：最少连续几次探测失败的次数，满足该次数则认为fail
initialDelaySeconds：容器启动之后开始进行存活性探测的秒数。不填立即进行
periodSeconds：执行探测的频率（秒）。默认为10秒。最小值为1。
successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功，满足该次数则认为success。（但是如果是liveness则必须是 1。最小值是 1。）
timeoutSeconds：每次执行探测的超时时间，默认1秒，最小1秒。
就绪性探测
就绪性健康检查:检查容器是否能够对外提供服务
存活性健康检查:检查容器是否正常运行
用于判断容器是否正常提供服务，即容器的Ready是否为True，是否可以接收请求，如果ReadinessProbe探测失败，则容器的Ready将设置为False，控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除，从此不再将任何请求调度此Pod上，直到下次探测成功。（剔除此pod,不参与接收请求不会将流量转发给此Pod)
1.HTTPGet
通过访问某个URL的方式探测当前POD是否可以正常对外提供服务
# 就绪性探测的特点是探测失败，立即移出负载均衡（endprints ---> NotReadyAddresses）
kind: Pod
apiVersion: v1
metadata:
name: readinessprobe-nginx
namespace: default
labels:
provider: aliyun
business: pms
environmental: dev
spec:
containers:
- name: readinessprobe-nginx
image: nginx
imagePullPolicy: Always
ports:
- containerPort: 80
name: http
protocol: TCP
- containerPort: 443
name: https
protocol: TCP
readinessProbe:
httpGet:
port: 80
path: /demo.html
initialDelaySeconds: 30 # 初始化时间
successThreshold: 3 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
2.Exec
通过执行一条命令，探测服务是否可以正常对外提供服务。
kind: Pod
apiVersion: v1
metadata:
name: exec-pod
spec:
containers:
- name: nginx
imagePullPolicy: IfNotPresent
image: nginx
readinessProbe:
exec:
command:
- cat
- /usr/share/nginx/html/index.html
initialDelaySeconds: 30 # 初始化时间
successThreshold: 3 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
3.TCPSocket
通过ping某个端口的方式，探测服务是否可以正常对外提供服务。
kind: Pod
apiVersion: v1
metadata:
name: exec-pod
spec:
containers:
- name: nginx
imagePullPolicy: IfNotPresent
image: nginx
readinessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 30 # 初始化时间
successThreshold: 3 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
案例
livenessProbe: # 存活性检查
tcpSocket:
port: 3306
initialDelaySeconds: 30 # 初始化时间
successThreshold: 1 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
readinessProbe: # 就绪性检查
tcpSocket:
port: 3306
initialDelaySeconds: 30 # 初始化时间
successThreshold: 3 # 连续成功多少次算成功
failureThreshold: 3 # 连续失败几次算失败
timeoutSeconds: 2 # 探测超时时间
periodSeconds: 2 # 执行探测等频率，单位秒。默认10秒，最小1
总结
pod中所有容器的status=Running时，Pod的状 态才会是Running状态。
当存活性检查检测失败的时候，kebulet会删除容器，重新启动一个新的容器。继续检查。
存活性探测：探测失败，立即删除容器
就绪性探测：探测失败，立即移除负载均衡
