k8s(11) — 探针和钩子
钩子和探针的区别：
在 Kubernetes（k8s）中，钩子（Hooks）和探针（Probes）是保障应用稳定运行的重要机制，不过它们的用途和工作方式存在差异，以下为你详细介绍：
定义与用途
- 钩子（Hooks）：它是与容器生命周期特定阶段相关联的回调机制。主要用于在容器启动后或者停止前执行特定操作，比如初始化配置、清理资源等，让用户能够自定义容器生命周期中的行为。
- 探针（Probes）：这是 Kubernetes 用来检查容器健康状况的一种机制。其目的在于判断容器是否正常运行、是否准备好接收流量，从而确保应用的可用性和可靠性。
类型与工作原理
- 钩子类型
- PostStart：容器创建完成后立即执行。不过它并不保证在容器的
ENTRYPOINT之前执行。- PreStop：容器终止之前执行，一般用于优雅关闭应用程序，释放资源等操作。
- 探针类型
- 存活探针（Liveness Probe）：判断容器是否正常运行。若探测失败，Kubernetes 会重启容器。
- 就绪探针（Readiness Probe）：判断容器是否准备好接收流量。若探测失败，容器不会被添加到服务的负载均衡中。
- 启动探针（Startup Probe）：检查容器内应用是否已经启动。在应用启动时间较长的场景中，可避免存活探针在应用还未完全启动时就将其误判为失败。
配置方式
- 钩子配置示例
yaml
apiVersion: v1 kind: Pod metadata:name: my-pod spec:containers:- name: my-containerimage: nginx:1.14.2lifecycle:postStart:exec:command: ["/bin/sh", "-c", "echo 'PostStart hook executed'"]preStop:exec:command: ["/bin/sh", "-c", "nginx -s quit"]在这个例子里，
postStart钩子在容器启动后执行一条打印命令，preStop钩子在容器停止前优雅关闭 Nginx 服务。
- 探针配置示例
yaml
apiVersion: v1 kind: Pod metadata:name: my-pod spec:containers:- name: my-containerimage: nginx:1.14.2livenessProbe:httpGet:path: /healthzport: 80initialDelaySeconds: 15periodSeconds: 5此例中，存活探针通过向
/healthz路径发送 HTTP 请求来检查容器的健康状况，容器启动 15 秒后开始探测，每 5 秒探测一次。触发时机
- 钩子触发时机：
PostStart钩子在容器创建完成后触发，PreStop钩子在容器终止前触发。- 探针触发时机：存活探针和就绪探针按照设定的时间间隔定期执行，启动探针在容器启动后开始执行，直到应用成功启动。
综上所述，钩子侧重于在容器生命周期的特定阶段执行自定义操作，而探针主要用于监控容器的健康状态，二者相互配合，共同保障 Kubernetes 应用的稳定运行。
分享
存活探针（Liveness Probe）有哪些探测方式？
如何配置Kubernetes的存活探针（Liveness Probe）？
钩子（Hooks）和探针（Probes）在实际应用中如何配合使用？
二、钩子与探针场景测试
1、探针测试
设置两处错误：
在启动探针加入命令探测当ls /a.txt 的结果返回0时，才会执行存活探针的内容；再将存活探测的http测试端口改为8080（nginx默认启动的端口为80所以探测8080会失败），所以容器将会一直处于未就绪状态。
livenessProbe:httpGet:path: /port: 8080successThreshold: 1startupProbe:exec:command:- /bin/sh- -c- ls /a.txtsuccessThreshold: 1
步骤一：创建pod
执行如下yaml
apiVersion: v1
kind: Pod
metadata:name: init-clabels:app: init-c
spec:containers:- name: nginx-1imagePullPolicy: IfNotPresentimage: nginx:1.23#存活探针livenessProbe:httpGet:path: /port: 80successThreshold: 1#启动探针 只有在根目录下创建一个a.txt才能正常启动才能接收请求startupProbe:exec:command:- /bin/sh- -c- ls /a.txtsuccessThreshold: 1
查看具体的报错原因:
kubectl describe pod init-c -n default
步骤二：启动探针测试
进入容器内部创建 /a.txt
[root@master podlifecycle]# kubectl exec -it init-c -- /bin/bash
root@init-c:/#
root@init-c:/#
root@init-c:/# > a.txt
root@init-c:/#
root@init-c:/#
查看容器的状态的日志：
步骤三：存活探针测试
将存活探测的端口改成80
启动状态正常
探针总结：
只有当启动探针状态正常后才会去执行存活探测和就绪探针，当yaml中全部定义3中类型的探针时需要所有的探针都探针成功pod才能处于正常被调度的状态。
2、钩子测试
测试yaml
apiVersion: v1
kind: Pod
metadata:name: init-clabels:app: init-c
spec:containers:- name: nginx-1imagePullPolicy: IfNotPresentimage: nginx:1.23#存活探针livenessProbe:httpGet:path: /port: 80successThreshold: 1#启动探针 只有在根目录下创建一个a.txt才能正常启动才能接收请求startupProbe:exec:command:- /bin/sh- -c- ls /a.txtsuccessThreshold: 1#钩子lifecycle:#启动后钩子postStart:exec:command: ["/bin/sh", "-c", "echo 'nginx start' > /usr/share/message"]#关闭前钩子preStop:exec:command: ["/bin/sh", "-c", "echo 'nginx stop' > /usr/share/message"]步骤一：启动后钩子测试
将启动后钩子检测参数设置为异常观察容器状态
1、将启动后钩子的参数设置为command: ["/bin/sh", "-c", "ls /c.txt"] 当容器启动后因为c.txt没有所以会被错，pod状态异常。
2、将启动后钩子检测参数设置为正常
步骤二：关闭前钩子测试
关闭容器查看停止前钩子会不会执行
停止前钩子执行命令："echo 'stop' > /usr/share/message"
1、进入容器内部执行如下命令：
while true;
do
cat /usr/share/message
done
2、关闭容器
kubectl delete -f test.yaml3、查看关闭前钩子是否执行
