钩子和探针的区别：
在 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-container image: nginx:1.14.2 lifecycle: 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-container image: nginx:1.14.2 livenessProbe: httpGet: path: /healthz port: 80 initialDelaySeconds: 15 periodSeconds: 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: 8080
successThreshold: 1
startupProbe:
exec:
command:
- /bin/sh
- -c
- ls /a.txt
successThreshold: 1
步骤一：创建pod
执行如下yaml
apiVersion: v1
kind: Pod
metadata:
name: init-c
labels:
app: init-c
spec:
containers:
- name: nginx-1
imagePullPolicy: IfNotPresent
image: nginx:1.23
#存活探针
livenessProbe:
httpGet:
path: /
port: 80
successThreshold: 1
#启动探针 只有在根目录下创建一个a.txt才能正常启动才能接收请求
startupProbe:
exec:
command:
- /bin/sh
- -c
- ls /a.txt
successThreshold: 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-c
labels:
app: init-c
spec:
containers:
- name: nginx-1
imagePullPolicy: IfNotPresent
image: nginx:1.23
#存活探针
livenessProbe:
httpGet:
path: /
port: 80
successThreshold: 1
#启动探针 只有在根目录下创建一个a.txt才能正常启动才能接收请求
startupProbe:
exec:
command:
- /bin/sh
- -c
- ls /a.txt
successThreshold: 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、查看关闭前钩子是否执行
