Pod探针（probe）

目录

&＃x1f9e1;什么是Pod探针&＃xff1f;

&＃x1f9e1;探针类型

livenessProbe 存活探针

startupProbe 启动探针

readinessProbe 就绪探针

&＃x1f9e1;探测方式

exec 命令行探测

tcpSocket 端口探测

httpGet api探测

grpc 远程探测

&＃x1f49f;这里是CS大白话专场&＃xff0c;让枯燥的学习变得有趣&＃xff01;

&＃x1f49f;没有对象不要怕&＃xff0c;我们new一个出来&＃xff0c;每天对ta说不尽情话&＃xff01;

&＃x1f49f;好记性不如烂键盘&＃xff0c;自己总结不如收藏别人&＃xff01;

&＃x1f9e1;什么是Pod探针&＃xff1f;

&＃x1f48c;Pod是k8s的最小执行单元&＃xff0c;probe 是由 kubelet 对容器执行的定期诊断。 要执行诊断&＃xff0c;kubelet 既可以在容器内执行代码&＃xff0c;也可以发出一个网络请求。

&＃x1f9e1;探针类型

&＃x1f48c;Pod探针主要有三种类型&＃xff1a;

livenessProbe 存活探针

&＃x1f48c;用于探测容器是否运行&＃xff0c;会一直检测。如果探测失败&＃xff0c;kubelet会杀死容器&＃xff0c;并根据配置的重启策略进行处理。若没有配置&＃xff0c;默认Success。

&＃x1f360;如果容器中的进程能够在遇到问题或不健康的情况下自行停止&＃xff0c;则不一定需要存活探针&＃xff1b; kubelet 将根据 Pod 的 restartPolicy 自动执行修复操作。

&＃x1f360;如果希望容器在探测失败时被杀死并重新启动&＃xff0c;那么请指定一个存活探针&＃xff0c; 并指定 restartPolicy 为 "Always" 或 "OnFailure"。

startupProbe 启动探针

&＃x1f48c;1.16版本新增探测方式&＃xff0c;用于判断容器内应用程序是否启动&＃xff0c;如果配置了startupProbe&＃xff0c;就会先禁止其他的探针&＃xff0c;直到探测到容器启动成功为止。如果探测失败&＃xff0c;kubelet会杀死容器&＃xff0c;并根据配置的重启策略进行处理。若没有配置&＃xff0c;默认Success。

&＃x1f360;对于所包含的容器需要较长时间才能启动就绪的 Pod 而言&＃xff0c;启动探针是有用的。 

&＃x1f360;如果容器需要在启动期间加载大型数据、配置文件或执行迁移&＃xff0c; 可以使用启动探针。

&＃x1f360;如果容器启动时间通常超出 initialDelaySeconds &＃43; failureThreshold × periodSeconds 总值&＃xff0c;应该设置一个启动探针&＃xff0c;对存活探针所使用的同一端点执行检查。 periodSeconds 的默认值是 10 秒。应该将其 failureThreshold 设置得足够高&＃xff0c; 以便容器有充足的时间完成启动&＃xff0c;并且避免更改存活探针所使用的默认值。 这一设置有助于减少死锁状况的发生。

readinessProbe 就绪探针

&＃x1f48c;一般用于探测容器内应用程序是否正常运行&＃xff0c;会一直监测。若为Success&＃xff0c;则表示程序已经完全启动&＃xff0c;可以接收流量。如果探测失败&＃xff0c; 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。若没有配置&＃xff0c;默认Success。

&＃x1f360;Pod 将在启动阶段不接收任何数据&＃xff0c;并且只有在探针探测成功后才开始接收数据&＃xff0c;需要指定就绪探针。 

&＃x1f360;如果希望容器能够自行进入维护状态&＃xff0c;也可以指定一个就绪探针。

&＃x1f360;如果应用程序对后端服务有严格的依赖性&＃xff0c;可以同时实现存活和就绪探针。 当应用程序本身是健康的&＃xff0c;存活探针检测通过后&＃xff0c;就绪探针会额外检查每个所需的后端服务是否可用。 这可以避免将流量导向只能返回错误信息的 Pod。

&＃x1f360;如果想区分已经失败的应用和仍在处理启动数据的应用&＃xff0c;更倾向于使用就绪探针。

&＃x1f9e1;探测方式

&＃x1f48c;使用探针来检查容器有四种不同的方法。 每个探针都必须准确定义为这四种机制中的一种&＃xff1a;

exec 命令行探测

&＃x1f48c;在容器内执行一个命令&＃xff0c;如果返回值为0&＃xff0c;则认为容器健康。

vim exec.yamlapiVersion: v1
kind: Pod
metadata:labels:test: liveness #为了健康检查定义的标签name: liveness-exec
spec: #定义了Pod中containers的属性containers:- name: livenessimage: nginxargs: #传入的命令- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5 #表示pod中容器启动成功后&＃xff0c;多少秒后进行健康检查 periodSeconds: 5 #在首次健康检查后&＃xff0c;下一次健康检查的间隔时间5stimeoutSeconds: 1failureThreshold: 30successThreshold: 1

tcpSocket 端口探测

&＃x1f48c;通过TCP连接检查容器内端口是否可以建立连接&＃xff0c;如果是通的则容器健康。

vim tcp.yamlapiVersion: v1
kind: Pod
metadata:labels:test: liveness #为了健康检查定义的标签name: liveness-tcp
spec: #定义了Pod中containers的属性containers:- name: livenessimage: nginxlivenessProbe:tcpSocket:port:8080initialDelaySeconds: 5 #表示pod中容器启动成功后&＃xff0c;多少秒后进行健康检查 periodSeconds: 5 #在首次健康检查后&＃xff0c;下一次健康检查的间隔时间5stimeoutSeconds: 1

httpGet api探测

&＃x1f48c;最可靠的方式&＃xff0c;通过应用程序暴露的API地址来检查程序是否是正常的&＃xff0c;如果状态码为200~400之间&＃xff0c;则认为容器健康。

vim http.yamlapiVersion: v1
kind: Pod
metadata:labels:test: liveness #为了健康检查定义的标签name: liveness-http
spec: #定义了Pod中containers的属性containers:- name: livenessports:- containerPort: 80image: nginxlivenessProbe:httpGet:port:80path: /index.htmlinitialDelaySeconds: 5 #表示pod中容器启动成功后&＃xff0c;多少秒后进行健康检查 periodSeconds: 5 #在首次健康检查后&＃xff0c;下一次健康检查的间隔时间5stimeoutSeconds: 1

grpc 远程探测

&＃x1f48c;使用gRPC执行一个远程过程调用。 目标应该实现 gRPC健康监测。 如果响应的状态是 "SERVING"&＃xff0c;则认为诊断成功。 gRPC 探针是一个 Alpha 特性&＃xff0c;只有在启用了"GRPCContainerProbe"时才能使用。