Kubernetes-POD的健康检查

目录

• 简介
• 什么是探针
  • Liveness Probe（存活探针）
  • Readiness Probe（就绪探针）
  • Startup Probe（启动探针）
• 什么时候使用探针？
  • 何时使用存活探针（Liveness Probe）
  • 何时使用就绪探针（Read iness Probe）
  • 何时使用启动探针（Startup Probe）
• 容器探测方法
  • exec
  • httpGet
  • tcpSocket
• 容器探测使用
  • livenessProbe使用
    • exec使用
    • httpGet使用
    • tcpSocket
  • readinessProbe使用
    • exec使用
    • httpGet使用
    • tcpSocket使用
  • startupProbe使用
    • httpGet使用
    • tcpSocket使用

简介

在Pod的生命周期中，可以执行多种操作如下图：

1. 初始化容器：主容器启动前，可以先运行一个或多个初始化容器。初始化容器是串行执行的，必须全部成功完成后才会启动主容器。初始化容器运行结束后即退出，不再占用资源。
2. Post Start钩子：主容器启动后，可以指定一个Post Start钩子，用于在主容器启动后执行一些额外的操作。
3. Pre Stop钩子：在主容器终止之前，可以指定一个Pre Stop钩子，用于在主容器结束前执行必要的清理或其他操作。
4. 健康探针：Pod启动后，其健康状态由以下几类探针进行检测：
   • Startup Probe（启动探针）：用于确保容器成功启动，在启动完成前其他探针不会干扰容器的启动过程。
   • Liveness Probe（存活探针）：用于检测容器是否存活。如果探测失败，Kubernetes会重启该容器。
   • Readiness Probe（就绪探针）：用于检测容器是否已准备好接收流量。如果探测失败，该Pod将暂时从服务端点中移除，直到其恢复就绪状态。

什么是探针

在Kubernetes中，探针（Probe）用于管理容器的生命周期，主要包括以下三种类型：

Liveness Probe（存活探针）

• 作用：判断容器是否处于运行状态（即容器是否存活）。
• 行为：
  1. 如果Liveness Probe探测到容器处于非健康状态，kubelet会杀掉该容器，并根据容器的重启策略进行处理。
  2. 如果未配置Liveness Probe，kubelet会默认认为容器始终处于“成功”状态。
• 场景：Liveness Probe用于捕捉容器死锁等问题。例如，当应用程序虽然运行但无法处理请求时，探针会检测到这个问题，并重启容器，使应用在存在bug的情况下依然能够继续运行。

Readiness Probe（就绪探针）

• 作用：判断容器是否已启动完成并准备好接受请求。
• 行为：
  1. 如果Readiness Probe探测失败，Pod的状态会被修改，Endpoint Controller会将该Pod从Service的Endpoint中移除。
  2. 如果未配置Readiness Probe，kubelet会默认认为容器处于“成功”状态。
• 场景：Readiness Probe用于控制哪些Pod可以作为Service的后端。如果Pod处于非就绪状态，它将被从Service的负载均衡中移除。

Startup Probe（启动探针）

• 作用：检测应用程序是否已完全启动。
• 行为：
  1. 在Startup Probe成功之前，其他探针（Liveness和Readiness）将被禁用。
  2. 如果Startup Probe探测失败，kubelet将终止容器并根据重启策略重启它。
  3. 如果未配置Startup Probe，kubelet会默认认为容器已成功启动。
• 场景：Startup Probe适用于启动时间较长的应用程序，确保应用完全启动后再启用其他探针。

通过合理配置这三类探针，可以确保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: 1selector:matchLabels:app: livenessprobe-tcpsockettemplate:metadata:labels:app: livenessprobe-tcpsocketspec:containers:- name: nginximage: registry.cn-guangzhou.aliyuncs.com/jiajia-k8s/nginx:1.21ports:- containerPort: 80args:- /bin/sh- -c- tail -f /etc/hostslivenessProbe:tcpSocket:port: 80  # 检测80端口是否可以连通，若连不通则会抛出检查容器出现问题，而后重启容器。initialDelaySeconds: 10periodSeconds: 3successThreshold: 1  failureThreshold: 2

很明显，上述案例暴露了80端口，由于启动容器时并没有启动nginx，而是去使用tail指令去查看一个文件内容达到阻塞容器的目的，因此在容器启动10后就开始第一次检查，而后每个3秒检查1次，达到指定次数后会触发重启操作，可以看到55秒内探测了4次，52秒内重启了两次

readinessProbe使用

exec使用

apiVersion: apps/v1
kind: Deployment
metadata:name: readinessProbe-execlabels:apps: nginx
spec:replicas: 3selector:matchLabels:apps: nginxtemplate:metadata:name: nginxlabels:apps: nginxspec:containers:- name: nginximage: nginx:1.18command: - /bin/bash- -c- touch /tmp/nginx-healthy; sleep 60; rm -f /tmp/nginx-healthy; sleep 60;livenessProbe:exec:command:- cat- /tmp/nginx-healthyfailureThreshold: 3initialDelaySeconds: 15periodSeconds: 1successThreshold: 1timeoutSeconds: 1readinessProbe:exec:command:- cat- /tmp/nginx-healthy-2023failureThreshold: 3initialDelaySeconds: 15periodSeconds: 1successThreshold: 1timeoutSeconds: 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: 1selector:matchLabels:app: readinessprobe-httpgettemplate:metadata:labels:app: readinessprobe-httpgetspec:containers:- name: nginximage: nginx:1.21ports:- containerPort: 80readinessProbe:httpGet:path: /healthz        # HTTP 请求的路径port: 80              # 容器内服务的端口initialDelaySeconds: 15periodSeconds: 5failureThreshold: 3successThreshold: 1timeoutSeconds: 1

tcpSocket使用

apiVersion: apps/v1
kind: Deployment
metadata:name: readinessprobe-tcpsocket
spec:replicas: 1selector:matchLabels:app: readinessprobe-tcpsockettemplate:metadata:labels:app: readinessprobe-tcpsocketspec:containers:- name: nginximage: nginx:1.21ports:- containerPort: 80livenessProbe:tcpSocket:port: 80failureThreshold: 3initialDelaySeconds: 30periodSeconds: 1successThreshold: 1timeoutSeconds: 1readinessProbe:tcpSocket:port: 80initialDelaySeconds: 15periodSeconds: 5failureThreshold: 3successThreshold: 1timeoutSeconds: 1

startupProbe使用

httpGet使用

apiVersion: apps/v1
kind: Deployment
metadata:name: startupprobe-httpget
spec:replicas: 1selector:matchLabels:app: startupprobe-httpgettemplate:metadata:labels:app: startupprobe-httpgetspec:containers:- name: nginximage: nginx:1.21ports:- containerPort: 80startupProbe:httpGet:path: /startupport: 80initialDelaySeconds: 30periodSeconds: 10failureThreshold: 10timeoutSeconds: 5

tcpSocket使用

apiVersion: apps/v1
kind: Deployment
metadata:name: startupprobe-tcpsocket
spec:replicas: 1selector:matchLabels:app: startupprobe-tcpsockettemplate:metadata:labels:app: startupprobe-tcpsocketspec:containers:- name: nginximage: nginx:1.21ports:- containerPort: 80startupProbe:tcpSocket:port: 80initialDelaySeconds: 30periodSeconds: 10failureThreshold: 10timeoutSeconds: 5