K8S健康监测：K8S针对pod资源对象的健康监测机制有哪些?

你的名字 2024-02-19 09:00 52阅读 0赞

## 健康监测探针 ##

Kubernetes提供了几种方式来监测和确保Pod资源对象的健康状态。下面是一些常见的健康监测机制，以及它们的示例说明：

1.  存活探针（Liveness Probe）：  
    存活探针用于检测Pod是否处于正常运行状态。如果存活探针失败，Kubernetes将认为Pod不健康并重启它。存活探针可以是以下三种类型之一：

*  HTTP GET：发送HTTP GET请求到Pod的指定端点，如果返回200-399之间的状态码，则认为Pod是健康的。
 *  TCP Socket：尝试建立与Pod指定端口的TCP连接，如果连接成功，则认为Pod是健康的。
 *  Exec：在Pod中执行指定的命令，如果命令的退出状态为0，则认为Pod是健康的。

示例：

apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
      - name: my-app
        image: nginx
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10

上述示例配置了一个HTTP GET存活探针，每隔10秒向Pod的`/healthz`路径发送GET请求，如果返回200-399之间的状态码，Pod将被认为是健康的。

1.  就绪探针（Readiness Probe）：  
    就绪探针用于确定Pod是否已准备好接收流量。如果就绪探针失败，Kubernetes将从服务负载均衡器中将Pod的IP地址剔除。就绪探针的类型和配置方式与存活探针类似。

示例：

apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
      - name: my-app
        image: nginx
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

上述示例配置了一个HTTP GET就绪探针，每隔10秒向Pod的`/ready`路径发送GET请求。如果返回200-399之间的状态码，Pod将被认为是就绪的。

1.  启动探针（Startup Probe）：  
    启动探针用于检测应用程序的启动过程是否成功。它在Pod启动后执行，只有在启动探针成功后，存活探针和就绪探针才会启动。启动探针的配置方式与存活探针和就绪探针相似。

示例：

apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
      - name: my-app
        image: nginx
        startupProbe:
          httpGet:
            path: /startup
            port: 8080
          failureThreshold: 30
          periodSeconds: 5

上述示例配置了一个HTTP GET启动探针，每隔5秒向Pod的`/startup`路径发送GET请求。如果在30秒内连续失败，Pod将被认为是不健康的。

## 参数 ##

提供了三类probe（探针）来执行对pod的健康监测：

*  livenessProbe探针 （存活探针）:

可以根据用户自定义规则来判定pod是否健康，用于判断容器是否处于Running状态，

如果不是，kubelet就会杀掉该容器，并根据重启策略做相应的处理。如果容器不包含该探针，那么kubelet就会默认返回值都是success;

*  ReadinessProbe探针:

同样是可以根据用户自定义规则来判断pod是否健康，容器服务是否可用（Ready），如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功;

*  startupProbe探针:

启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，

这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可;

备注：每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：

*  initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败；
 *  periodSeconds：检查间隔，多久执行probe检查，默认为10s；
 *  timeoutSeconds：检查超时时长，探测应用timeout后为失败；
 *  successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。