默认情况下，kubernetes(以后简称k8s)当pod中所有container一“启动”，就向其发送通信请求，并在pod崩溃后重启他们。通常来说这已经够好了。但是k8s提供了一种更直接明了的方式。
那就是readiness和liveness探测器。
1 HealthChecks 分类
健康检查（health check）是用于检测应用实例是否正常工作，对应用状态的监控，保障业务高可用的一种机制。
k8s健康检测主要分为以下三种
1.存活性探测（Liveness probes） :主要是探测应用是否还活着。如果检测到应用没有存活就杀掉当前pod并重启;
2. 就绪性探测（Readiness probes）:只要是探测应用是否准备好接受请求访问，如果检测应用准备好了，就把请求流量放进来；反之，则把应用节点从注册中心拿掉。
3. 启动探测（Startup Probes）：对于旧应用需要更长的启动时间，这时候既不想重启应用也不想让请求访问进来，可以设置启动探测给足够的启动时间保证应用启动成功
1.1 Readiness
Readiness Probe的设计目的是让Kubernetes明确知道Pod 何时已经完全正版就绪。在向POD发送请求通信之前,首先进行Readiness Probe测试。如果测试没有通过,Kubernetes 停止向其发送通信请求，直到测试通过。
1.2 Liveness
Liveness Probe 是为了让k8s知道pod是否存活（而不一定可用）。如果POD死掉，则k8s会将其remove并启动一个新的POD 取而代之。
1.3 启动探测
startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success
可以自定义在pod启动时是否执行这些检测，如果不设置，则检测结果均默认 为通过，如果设置，则顺序为startupProbe>readinessProbe>livenessProbe
2 HealthCheck 工作原理
2.1 Readiness
当POD刚刚开始启动,对应的服务并不一定完全启动,正常提供服务,默认情况下Kubernetes会立刻向POD发送请求一旦进程启动(但此刻服务不一定可用),因此运用Readiness Probe，Kubernetes 会等待POD 完全ready后才会向其发送请求
2.2 Liveness
当POD 因特殊状况下一直处于挂起状态且不能响应任何请求，然后此时进程却存在,Kubernetes 会认认为服务一切正常并持续向挂起的POD发送请求.
若运用Liveness Probe,Kubernetes 会发现该POD意见停止响应,进而重启异常的POD
3 Kubernetes Probe 类型
Kubernetes 支持三种方式来执行探针
exec：在容器中执行一个命令，如果命令退出码返回0则表示探测成功，否则表示失败
tcp：对指定的容IP及端口执行一个TCP检查，如果端口是开放的则表示探测成功，否则表示失败
http：对指定的容器IP、端口及路径执行一个HTTP Get请求，如果返回的状态码在 [200,400)之间则表示探测成功，否则表示失败
3.1 HTTP Probe
基于HTTP的探测(HTTPGetAction)向目标容器发起一个HTTP请求，根据其相应码进行结果判定，响应码如2xx或3xx时表示检测通过。
#cat liveness-http.yaml
apiVersion : v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness-http
image: nginx
ports:
- name: http
containerPort: 80
lifecycle:
postStart:
exec:
command: ["/bin/sh" ,"-c","echo liveness-http test > /usr/share/nginx/html/health"]
livenessProbe:
httpGet:
path: /health
port: http
scheme: HTTP
initialDelaySeconds: 30 #表示延迟30S开始第一次探测，默认值是0，最小值是0
timeoutSeconds: 35 #表示每次探测的超时时间，35S后如果没返回结果就认为超时失败，默认值是1，最小值是1
periodSeconds: 30 #表示在探测失败后，最小的连续成功被认为是成功的，默认值是1，最小值是1
successThreshold: 1 #表示当探测失败时，Kubernetes将在认为失败前尝试failureThreshold次数。默认值是3，最小值是1;Liveness认为失败的操作是重启pod，而readiness认为失败的操作是把pod标记为 Unready
failureThreshold: 3 #表示多久进行一次探测，默认是10S，最小值是1
3.2 TCP Probe
基于TCP的存活性探测(TCPSocketAction)用于向容器的特定端口发起TCP请求并尝试建立连接，连接成功即为通过检测。
iveness-tcp.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-tcp
spec:
containers:
- name: liveness-tcp
image: nginx
ports:
- name: http
containerPort: 80
livenessProbe:
tcpSocket:
port: http
initialDelaySeconds: 50 # 延迟探测时间(秒) 【 在k8s第一次探测前等待秒 】
periodSeconds: 10 # 执行探测频率(秒) 【 每隔秒执行一次 】
timeoutSeconds: 1 # 超时时间
uccessThreshold: 1 # 健康阀值
failureThreshold: 3 # 不健康阀值
3.3 exec Probe
exec类型的探针通过在目标容器中执行由用户自定义的命令来判断容器的监控状态，若命令状态返回值为0则表示“成功”通过检测，其他值则均为“失败”状态
#cat liveness-exec.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness-exec
name: liveness-exec
spec:
restartPolicy: OnFailure
containers:
- name: liveness-exec
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command: ["test","-e","/tmp/healthy"]
initialDelaySeconds: 5 #探测延时时长，第一次探测前等待5秒，默认为0
periodSeconds: 5 #每5秒执行一次liveness探测,默认值10秒，最小1秒
timeoutSeconds: 2 #超长时长，默认为1s,最小值也为1s
failureThreshold: 3 #处于成功状态时，探测操作至少连续多少次的失败才被视为检测不通过，默认为3，最小为1
3 启动探测(Startup Probes)
#cat startup-probe.yml
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 10
startupProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 30
periodSeconds: 10
由于启动探测，应用最多有5分钟(30 * 10 = 300秒)来完成它的启动。一旦启动探测成功一次，活性探测（Livenees probes）将接管以提供对容器死锁的快速响应。如果启动探测从未成功，容器将在300秒后被杀死，并遵循pod的重启策略 restartPolicy
restartPolicy 主要有以下三种策略
Always: 当容器终止退出后，总是重启容器，默认策略
Onfailure: 当容器异常退出后（退出码非0）时，才重启容器
Never: 当容器终止退出时，不重启容器
每次探测都是以下三种结果之一：
成功：容器通过了探测
失败：容器未通过探测
未知：容器探测失败，不采取任何操作