Kubernetes 0-1 Pod中的livenessProbe和readinessProbe解读
写在前面
K8S对Pod的健康状态可以通过两类探针来检查：livenessProbe和readinessProbe，kubelet通过定期执行这两类探针来诊断容器的健康状况。
livenessProbe简介
存活指针，判断Pod（中的应用容器）是否健康，可以理解为健康检查。我们使用livenessProbe来定期的去探测，如果探测成功，则Pod状态可以判定为Running；如果探测失败，可kubectl会根据Pod的重启策略来重启容器。
如果未给Pod设置livenessProbe，则默认探针永远返回Success。
当我们执行kubectl get pods命令，输出信息中STATUS一列我们可以看到Pod是否处于Running状态。
readinessProbe简介
就绪指针，就绪的意思是已经准备好了，Pod的就绪我们可以理解为这个Pod可以接受请求和访问。我们使用readinessProbe来定期的去探测，如果探测成功，则Pod 的Ready状态判定为True；如果探测失败，Pod的Ready状态判定为False。
与livenessProbe不同的是，kubelet不会对readinessProbe的探测情况有重启操作。
当我们执行kubectl get pods命令，输出信息中READY一列我们可以看到Pod的READY状态是否为True。
定义参数
livenessProbe和readinessProbe的定义参数是一致的，可以通过kubectl explain pods.spec.containers.readinessProbe或kubectl explain pods.spec.containers.livenessProbe命令了解：
就绪探针的几种类型：
httpGet
向容器发送Http Get请求，调用成功（通过Http状态码判断）则确定Pod就绪；
使用方式：
livenessProbe:
httpGet:
path: /app/healthz
port: 80exec
在容器内执行某命令，命令执行成功（通过命令退出状态码为0判断）则确定Pod就绪；
使用方式：
livenessProbe:
exec:
command:
- cat
- /app/healthztcpSocket
打开一个TCP连接到容器的指定端口，连接成功建立则确定Pod就绪。
使用方式：
livenessProbe:
tcpSocket:
port: 80一般就绪探针会在启动容器一段时间后才开始第一次的就绪探测，之后做周期性探测。所以在定义就绪指针时，会给以下几个参数：
- initialDelaySeconds：在初始化容器多少秒后开始第一次就绪探测；
- timeoutSeconds：如果该次就绪探测超过多少秒后还未成功，判定为超时，该次探测失败，Pod不就绪。默认值1，最小值1；
- periodSeconds：如果Pod未就绪，则每隔多少秒周期性的做就绪探测。默认值10，最小值1；
- failureThreshold：如果容器之前探测成功，后续连续几次探测失败，则确定容器未就绪。默认值3，最小值1；
- successThreshold：如果容器之前探测失败，后续连续几次探测成功，则确定容器就绪。默认值1，最小值1。
使用示例
目前我在docker hub有一个测试镜像：med1tator/helloweb:v1，容器启动后，有一个健康检查路由/healthz/return200，访问该路由状态码返回200；有一个检查路由/health/return404，访问该路由状态码返回404。
readinessProbe示例
在实验之前先了解一下Pod和Service的负载均衡关系：在K8S中，Service作为Pod的负载均衡器，是通过Label Selector匹配Pod的。但是这句话没有说完整，因为还有一个必要条件：Pod当前已经就绪。也就是说，Service通过Label Selector匹配当前就绪的Pod，还未就绪的Pod就算labelSelector匹配上了，也不会出现在Service的endpoints中，请求是不会被转发过去的，如下图示例。
示例说明：我们使用med1tator/helloweb:v1镜像启动三个Pod，三个Pod的Label都设置成一样，为了使Service匹配到；三个Pod其中两个readinessProbe使用httpGet探测/health/return200，模拟探测成功，一个readinessProbe使用httpGet探测/health/return404，模拟探测失败。
编写我们的helloweb-readinessProbe.yaml文件如下：
apiVersion: v1
kind: Pod
metadata:
name: helloweb1
labels:
app: helloweb
spec:
containers:
- name: helloweb
image: med1tator/helloweb:v1
readinessProbe:
httpGet:
path: /healthz/return200
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
ports:
- containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
name: helloweb2
labels:
app: helloweb
spec:
containers:
- name: helloweb
image: med1tator/helloweb:v1
readinessProbe:
httpGet:
path: /healthz/return200
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
ports:
- containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
name: helloweb3
labels:
app: helloweb
spec:
containers:
- name: helloweb
image: med1tator/helloweb:v1
readinessProbe:
httpGet:
path: /healthz/return404
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: helloweb
spec:
selector:
app: helloweb
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80运行命令部署Pod和Service：
kubectl apply -f helloweb-readinessProbe.yaml
之后，我们查看Pod的就绪情况：
可以看到Pod只有helloweb1和helloweb2当前使处于READY（就绪）的状态，helloweb3尚未Ready，我们接着查看helloweb service的endpoints：
可以看到Service的EndPoints只将helloweb1、helloweb2 pod的IP负载上了。
查看日志访问情况：
可以看到每隔10秒（readniessProbe.periodSeconds默认10s）就会做一次就绪探测。
livenessProbe示例
编写我们的helloweb-livenessProbe.yaml文件如下：
apiVersion: v1
kind: Pod
metadata:
name: helloweb4
labels:
app: helloweb
spec:
containers:
- name: helloweb
image: med1tator/helloweb:v1
livenessProbe:
httpGet:
path: /healthz/return200
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
ports:
- containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
name: helloweb5
labels:
app: helloweb
spec:
containers:
- name: helloweb
image: med1tator/helloweb:v1
livenessProbe:
httpGet:
path: /healthz/return404
port: 80
initialDelaySeconds: 30
timeoutSeconds: 10
ports:
- containerPort: 80运行命令部署Pod和Service：
kubectl apply -f helloweb-livenessProbe.yaml
之后，我们查看Pod的就绪情况：
可以看到helloweb4的STATUS状态为Running，而helloweb5的STATUS状态最终变为CrashLoopBackOff，并且一直在重启。
相信到这里，你已经对readniessProbe和livenessProbe有一个清晰的了解了。
