大部分的应用程序我们在部署的时候都会适当的添加监控，对于运行载体容器则更应该如此。kubernetes提供了 liveness probes来检查我们的应用程序。它是由节点上的kubelet定期执行的。
首先说一下Pod的整个生命阶段：
- Pending：表示集群系统正在创建Pod，但是Pod中的container还没有全部被创建，这其中也包含集群为container创建网络，或者下载镜像的时间；
- Running：表示pod已经运行在一个节点商量，并且所有的container都已经被创建。但是并不代表所有的container都运行，它仅仅代表至少有一个container是处于运行的状态或者进程出于启动中或者重启中；
- Succeeded：所有Pod中的container都已经终止成功，并且没有处于重启的container；
- Failed：所有的Pod中的container都已经终止了，但是至少还有一个container没有被正常的终止(其终止时的退出码不为0)
对于Liveness Probe的结果也有几个固定的可选项值：
- Success：表示通过检测
- Failure：表示没有通过检测
- Unknown：表示检测没有正常进行
Liveness Probe的种类：
- ExecAction：在container中执行指定的命令。当其执行成功时，将其退出码设置为0；
- TCPSocketAction：执行一个TCP检查使用container的IP地址和指定的端口作为socket。如果端口处于打开状态视为成功；
- HTTPGetAcction：执行一个HTTP默认请求使用container的IP地址和指定的端口以及请求的路径作为url，用户可以通过host参数设置请求的地址，通过scheme参数设置协议类型(HTTP、HTTPS)如果其响应代码在200~400之间，设为成功。
当前kubelet拥有两个检测器，他们分别对应不通的触发器(根据触发器的结构执行进一步的动作)：
- Liveness Probe：表示container是否处于live状态。如果 LivenessProbe失败，LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉 container，并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为 Success，如果container没有提供LivenessProbe，则也认为是Success；
- Readiness Probe：表示container是否以及处于可接受service请求的状态了。如 果ReadinessProbe失败，endpoints controller将会从service所匹配到的endpoint列表中移除关于这个container的IP地址。因此对于Service匹配到的 endpoint的维护其核心是Readiness Probe。默认Readiness的初始值是Failure，如果一个container没有提供 Readiness则被认为是Success。
对于Liveness Probe和Readiness Probe用法都一样，拥有相同的参数和相同的监测方式。
- initialDelaySeconds：用来表示初始化延迟的时间，也就是告诉监测从多久之后开始运行，单位是秒
- timeoutSeconds: 用来表示监测的超时时间，如果超过这个时长后，则认为监测失败
当前对每一个Container都可以设置不同的restartpolicy，有三种值可以设置：
- Always: 只要container退出就重新启动
- OnFailure: 当container非正常退出后重新启动
- Never: 从不进行重新启动
如果restartpolicy没有设置，那么默认值是Always。如果container需要重启，仅仅是通过kubelet在当前节点进行container级别的重启。
最后针对Liveness Probe如何使用，请看下面的几种方式，如果要使用ReadinessProbe只需要将livenessProbe修改为readinessProbe即可：
apiVersion: v1
kind: Pod
metadata:
name: probe-exec
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
exec:
command:
- cat
- /tmp/health
initialDelaySeconds: 5
timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
name: probe-http
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
httpGet:
path: /
port: 80
host: www.baidu.com
scheme: HTTPS
initialDelaySeconds: 5
timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
namespace: coocla
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
initialDelaySeconds: 5
timeoutSeconds: 1
tcpSocket:
port: 80
关于kubectl资源创建的语法可以参考: kubernetes技术学习之—Construct语法
我们使用上面的construct创建资源：
kubectl create -f probe.yaml
kubectl get event
kubernetes之配置保活探针与就绪探针
在kubernetes中，kubelet通过liveness探针决定在何时重新启动容器。例如，容器中的应用运行时进入死锁状态，liveness探针对容器进行健康检查时检测到这种情况，那么探针检测失败，则kubelet就会重新启动容器。可以看到重新启动并没有从根本上解决死锁问题，只是忽略了问题使容器继续运行。
kubelet通过readiness类型的探针决定container是否准备就绪处理流量，当pod中的所有container全部处于ready状态时，pod被认为可以对外提供服务。readiness探针的典型应用是控制pod是否作为service的backend。以下示例中都没有为容器指定"restart policy"，所以均采用默认值"Always"。
Define a liveness command
有些程序因为长时间运行而进入崩坏的状态，其中的一个解决办法是重新启动，liveness探针专门用来解决此类问题。
下例是运行一个容器的pod，容器image是k8s.gcr.io/busybox，配置文件如下：
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 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5
从以上配置文件看出，pod包含一个容器。每隔 periodSeconds秒执行一次liveness探针诊断，initialDelaySeconds表示kubelet在启动容器后首次执行探针诊断的延迟时间。探针的具体实现是在容器内部执行cat /tmp/healthy命令，如果命令退出码是0表示容器存活健康，如果非0则kubelet重新启动容器。
容器启动以后执行如下指令：
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
创建pod：
kubectl create -f https://k8s.io/examples/pods/probe/exec-liveness.yaml
在30秒之内查看pod事件：
kubectl describe pod liveness-exec
输出如下：
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s 1 {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 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s 1 {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 1/1 Running 1 1m
restart次数被加1。
Define a liveness HTTP request
以下是HTTP GET类型的liveness探针示例，pod包含一个容器，image是k8s.gcr.io/liveness：
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: 8080
httpHeaders:
- name: X-Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3
注意探针中path、port、httpHeader的配置，kubelet通过这些信息，构建http get请求，并通过kuelet运行的网络将请求发送到容器的指定端口、路径上。当应答状态码大于等于200小于400时表示探针诊断通过，其它状态码表示失败。kubelet杀死容器然后重新启动。
Define a TCP liveness probe
TCP类型是最简单的探针，kubelet尝试打开容器上的某个端口，如果连接成功建立则诊断通过，否则失败，示例配置如下：
apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
Use a named port
在定义探针时使用命名端口，示例如下：
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
Define readiness probes
容器有时候会暂时无法对外提供服务，比如容器在启动阶段需要下载大量数据配置文件等，此时容器无法对外提供服务但又不能杀死它，而用户也希望此时容器不要授受来自service的流量 ，readiness类型探针专门处理此种情况。
readiness probe与liveness probe的配置类似，唯一不同的只是字段名称，将livenessProbe换成readinessProbe，如下：
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
readiness probe暂时阻止pod成为service的backend，当诊断通过时再将pod加入到相应service的后端。liveness探针影响的是单个容器，但readiness探针影响的是整个pod，即如果pod中有多个容器，只要有一个容器的readiness探针诊断失败，那么整个pod都会处于unready状态。