目录
简介
在 Kubernetes中，liveness probe、readiness probe 和 startup probe 用于管理容器的生命周期：
- Liveness Probe（存活探针）：kubelet 通过 liveness probe 判断应用程序是否仍在运行。如果探针检测到应用崩溃，Kubernetes 会自动重启容器，以确保应用在出现问题时能够继续运行。
- Readiness Probe（可读性探针）：kubelet 使用 readiness probe 判断容器是否已准备好接收流量。只有当 Pod 中所有容器都处于就绪状态时，Pod 才会被认为是“就绪”的。未就绪的 Pod 会从 Service 的 Endpoints 列表中移除，避免流量被路由到此 Pod。
- Startup Probe（启动探针）：kubelet 通过 startup probe 检测应用是否已完全启动。在此探针成功之前，其他探针会被禁用。如果启动探针失败，kubelet 将终止容器并根据重启策略重启它。如果未定义启动探针，则默认认为容器已成功启动。
这样，通过配置这些探针，Kubernetes 能够更加灵活和精确地管理应用的生命周期。
什么时候使用探针？
何时使用存活探针（Liveness Probe）
- 容器可能卡死或无响应：如果你的应用程序在遇到问题时可能卡死或进入无响应状态，而不会自行崩溃，那么就应该使用存活探针。Liveness Probe 可以检测到这些状态，并触发 kubelet 终止并重启容器。
- 确保自动重启：如果你希望容器在探测失败时被杀死并重新启动，以确保应用的持续可用性，那么应配置存活探针。此时，可以将
restartPolicy设置为Always或OnFailure，以确保在探针检测到问题时容器能够自动重启。
何时使用就绪探针（Read iness Probe）
- 控制流量路由：如果你希望只有在探测成功时才开始向 Pod 发送请求流量，就需要指定就绪探针。就绪探针常与存活探针相同，但它确保 Pod 在启动阶段不会接收任何数据，只有探测成功后才开始接收流量。
- 维护状态：如果希望容器能自行进入维护状态，可以使用就绪探针，检查与存活探针不同的特定端点。对于依赖于后端服务的应用程序，可以同时使用存活探针和就绪探针。存活探针检测容器本身的健康状况，而就绪探针则确保所需的后端服务可用，避免将流量导向出错的 Pod。
- Pod 删除：注意，如果只是想在 Pod 被删除时排空请求，通常不需要使用就绪探针。Pod 在删除时会自动进入未就绪状态，无论是否有就绪探针，直到容器停止为止。
何时使用启动探针（Startup Probe）
- 应用启动慢：如果容器在启动期间需要加载大型数据或配置文件，可以使用启动探针。它确保在启动完成前不会触发其他探针。
容器探测方法
exec
执行一段命令，根据返回值判断执行结果。
返回值为0, 非0两种结果，可以理解为"echo $?"。
httpGet
通过发起HTTTP协议的GET请求检测某个http请求的返回状态码，从而判断服务是否正常。
常见的状态码分为很多类，比如: "2xx,3xx"正常, "4xx,5xx"错误。
200: 返回状态码成功。
301: 永久跳转，会将跳转信息缓存到浏览器本地。
302: 临时跳转，并不会将本次跳转缓存到本地。
401: 验证失败。
403: 权限被拒绝。
404: 文件找不到。
413: 文件上传过大。
500: 服务器内部错误。
502: 无效的请求。
504: 后端应用网关相应超时。
tcpSocket
测试某个TCP端口是否能够连接，类似于telnet这样的工具。
每次探测都将获得以下三种结果之一：
- Success（成功）：容器通过了诊断。
- Failure（失败）：容器未通过诊断。
- Unknown（未知）：诊断失败，因此不会采取任何行动。
容器探测使用
livenessProbe使用
exec使用
apiVersion: v1
kind: Pod
metadata:
name: livenessprobe-exec
spec:
containers:
- name: nginx
image: nginx:1.18
ports:
- containerPort: 80
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 600
# 定义健康检查探针
livenessProbe:
# 指定探针的检测方法为exec。
exec:
# 指定exec要执行的命令
command:
- cat
- /tmp/healthy
# 指定第一次进行健康检查的秒数，该值在生产环境中应该确保这个延迟时间内容器可以正常启动运行。
initialDelaySeconds: 15
# 指定每次周期的健康检查的间隔时间。
periodSeconds: 5
# 指定执行exec定义命令的超时的秒数。
timeoutSeconds: 1
# 检查1次成功就认为服务是健康的。
successThreshold: 1
# 检查连续3次失败就认为服务是不健康的。
failureThreshold: 3
httpGet使用
apiVersion: v1
kind: Pod
metadata:
name: livenessprobe-httpGet
spec:
containers:
- name: nginx
image: nginx:1.18
ports:
- containerPort: 80
# 定义健康检查探针
livenessProbe:
httpGet: # 指定探针的检测方法为httpGet。
path: /index.html # 指定访问的文件路径信息即可，无需指定IP地址，因为默认就是访问本机，可以理解为127.0.0.1。
port: 80 # 指定对容器的哪个端口发送GET请求。
initialDelaySeconds: 15
# 指定每次周期的健康检查的间隔时间。
periodSeconds: 5
timeoutSeconds: 1
successThreshold: 1
failureThreshold: 3
tcpSocket
apiVersion: apps/v1
kind: Deployment
metadata:
name: livenessprobe-tcpsocket
spec:
replicas: 1
selector:
matchLabels:
app: livenessprobe-tcpsocket
template:
metadata:
labels:
app: livenessprobe-tcpsocket
spec:
containers:
- name: nginx
image: registry.cn-guangzhou.aliyuncs.com/jiajia-k8s/nginx:1.21
ports:
- containerPort: 80
args:
- /bin/sh
- -c
- tail -f /etc/hosts
livenessProbe:
tcpSocket:
port: 80 # 检测80端口是否可以连通，若连不通则会抛出检查容器出现问题，而后重启容器。
initialDelaySeconds: 10
periodSeconds: 3
successThreshold: 1
failureThreshold: 2
很明显，上述案例暴露了80端口，由于启动容器时并没有启动nginx，而是去使用tail指令去查看一个文件内容达到阻塞容器的目的，因此在容器启动10后就开始第一次检查，而后每个3秒检查1次，达到指定次数后会触发重启操作，可以看到55秒内探测了4次，52秒内重启了两次
readinessProbe使用
exec使用
apiVersion: apps/v1
kind: Deployment
metadata:
name: readinessProbe-exec
labels:
apps: nginx
spec:
replicas: 3
selector:
matchLabels:
apps: nginx
template:
metadata:
name: nginx
labels:
apps: nginx
spec:
containers:
- name: nginx
image: nginx:1.18
command:
- /bin/bash
- -c
- touch /tmp/nginx-healthy; sleep 60; rm -f /tmp/nginx-healthy; sleep 60;
livenessProbe:
exec:
command:
- cat
- /tmp/nginx-healthy
failureThreshold: 3
initialDelaySeconds: 15
periodSeconds: 1
successThreshold: 1
timeoutSeconds: 1
readinessProbe:
exec:
command:
- cat
- /tmp/nginx-healthy-2023
failureThreshold: 3
initialDelaySeconds: 15
periodSeconds: 1
successThreshold: 1
timeoutSeconds: 1
从事件日志来看，Liveness Probe 和 Readiness Probe 都因为无法找到 /tmp/nginx-healthy 文件而失败。这是由于容器中的命令在 60 秒后删除了该文件，导致探针在检查时无法访问该文件。
- Liveness Probe 失败触发了容器重启。此探针用于检测容器是否健康，不健康时会重启容器。
- Readiness Probe 失败使得 Pod 从 Service 的 Endpoints 列表中移除，导致 Pod 无法接收流量。这表示 Pod 当前无法处理请求。
httpGet使用
apiVersion: apps/v1
kind: Deployment
metadata:
name: readinessprobe-httpget
spec:
replicas: 1
selector:
matchLabels:
app: readinessprobe-httpget
template:
metadata:
labels:
app: readinessprobe-httpget
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /healthz # HTTP 请求的路径
port: 80 # 容器内服务的端口
initialDelaySeconds: 15
periodSeconds: 5
failureThreshold: 3
successThreshold: 1
timeoutSeconds: 1
tcpSocket使用
apiVersion: apps/v1
kind: Deployment
metadata:
name: readinessprobe-tcpsocket
spec:
replicas: 1
selector:
matchLabels:
app: readinessprobe-tcpsocket
template:
metadata:
labels:
app: readinessprobe-tcpsocket
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
livenessProbe:
tcpSocket:
port: 80
failureThreshold: 3
initialDelaySeconds: 30
periodSeconds: 1
successThreshold: 1
timeoutSeconds: 1
readinessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 15
periodSeconds: 5
failureThreshold: 3
successThreshold: 1
timeoutSeconds: 1
startupProbe使用
httpGet使用
apiVersion: apps/v1
kind: Deployment
metadata:
name: startupprobe-httpget
spec:
replicas: 1
selector:
matchLabels:
app: startupprobe-httpget
template:
metadata:
labels:
app: startupprobe-httpget
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
startupProbe:
httpGet:
path: /startup
port: 80
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 10
timeoutSeconds: 5
tcpSocket使用
apiVersion: apps/v1
kind: Deployment
metadata:
name: startupprobe-tcpsocket
spec:
replicas: 1
selector:
matchLabels:
app: startupprobe-tcpsocket
template:
metadata:
labels:
app: startupprobe-tcpsocket
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
startupProbe:
tcpSocket:
port: 80
initialDelaySeconds: 30
periodSeconds: 10
failureThreshold: 10
timeoutSeconds: 5