钩子和探针的区别:
在 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.yaml
3、查看关闭前钩子是否执行