Pod探针解析及实战(k8s)
pod探针 探针类型 探针动作 pod探针实战 pod探针解析
一、探针类型
1.1livenessProbe存活探针
用于判断容器是否存活(running状态),如果LivenessProbe探针探测到容器不健康,则kubelet杀掉该容器,并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针,则kubelet认为该容器的LivenessProbe探针返回的值永远是“Success”。
1.2readinessProbe就绪探针
用于判断容器是否启动完成(ready状态),可以接收请求。如果ReadinessProbe探针检测到失败,则Pod的状态被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。
1.3startupProbe启动探针
指示容器中的应用是否已经启动。如果提供了启动探针(startup probe),则禁用所有其他探针,直到它成功为止。如果启动探针失败,kubelet 将杀死容器,容器服从其重启策略进行重启。如果容器没有提供启动探针,则默认状态为成功Success。
二、探针动作
2.1exec
在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
livenessProbe:
exec:
command: ["cat /tmp/health"]
initialDelaySeconds: 5
periodSeconds: 5
2.2tcpSocket
对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开,则诊断被认为是成功的。
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 15
periodSeconds: 20
2.3httpGet
对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400,则诊断被认为是成功的。path字段必须有。
livenessProbe:
httpGet:
path: /doc.html
port: 40017
failureThreshold: 1
periodSeconds: 10
三、探针配置
3.1通用字段
探针配置字段,可以使用这些字段精确的控制存活和就绪检测的行为:
initialDelaySeconds:容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认是 0 秒,最小值是 0。
periodSeconds:执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1。
timeoutSeconds:探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
successThreshold:探测器在失败后,被视为成功的最小连续成功数。默认值是 1。存活探测的这个值必须是 1。最小值是 1。
failureThreshold:当 Pod 启动了并且探测到失败,Kubernetes 的重试次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。优先级低于pod默认重启策略,更改后也不会按照该参数执行。
3.2专属字段
3.2.1exec
command
3.2.2tcpSocket
port
3.2.3httpGet
host:连接使用的主机名,默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。
scheme:用于设置连接主机的方式(HTTP 还是 HTTPS)。默认是 HTTP。
path:访问 HTTP 服务的路径。
httpHeaders:请求中自定义的 HTTP 头。HTTP 头字段允许重复。
port:访问容器的端口号或者端口名。如果数字必须在 1 ~ 65535 之间。
四、实战
以livenessProbe存活探针为例测试三种探针动作,其它的探针也是同样配置。
4.1exec
这里必须用busybox镜像,因为busybox自带一部分linux命令。pod启动时新建healthy文件,30秒后删除文件,再次检查时pod已经重启过一次。
apiVersion: v1
kind: Pod
metadata:
name: exec-probe
namespace: default
labels:
probe: liveness
spec:
containers:
- name: liveness-probe-container
image: busybox
command: ["/bin/sh","-c","touch /tmp/healthy;sleep 30;rm -rf /tmp/healthy","sleep 600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/healthy"]
initialDelaySeconds: 5
periodSeconds: 5
4.2tcpSocket
使用nginx镜像,容器默认开放端口为80,探针动作检测80端口已开启,pod运行正常。
apiVersion: v1
kind: Pod
metadata:
name: tcp-probe
namespace: default
labels:
probe: tcp
spec:
containers:
- name: tcp-rpobe
image: nginx
ports:
- name: http
containerPort: 80
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 10
periodSeconds: 5
将探针端口检测为改为81,再次测试,发现pod不断重启,重启多次后出现状态为CrashLoopBackOff。
4.3httpGet
pod启动在path路径下生成ishealthy.html,进去容器后手动删除ishealthy.html,
apiVersion: v1
kind: Pod
metadata:
name: http-probe
namespace: default
labels:
probe: http
spec:
containers:
- name: http-probe
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
lifecycle:
postStart:
exec:
command: ["/bin/bash","-c","echo Http-Probe > /usr/share/nginx/html/ishealth.html"]
livenessProbe:
httpGet:
path: /ishealth.html
port: http
scheme: HTTP
进入容器删除ishealth.html,,此处只会重启1次,因为pod重启后会重新生成ishealth.html文件。
kubectl exec http-probe -it bash
rm-rf /usr/share/nginx/html/ishealth.html
exit
参考文档:
解析
【项目实战17.5】k8s(3.5)—pod生命周期和探针_运维技术-陈工的博客-CSDN博客
存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)、容器钩子_startupprobe_刘李404not found的博客-CSDN博客
更多推荐
所有评论(0)