钩子和探针的区别：

在 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.yaml

3、查看关闭前钩子是否执行