Kubernetes Pod健康检查机制

标签：init   inf   获取   完成   决定   failure   containe   socket   style   

一、Pod的整个生命阶段

• Pending：正在创建的Pod，但是Pod中的容器还没有完全被创建完成，这其中包含集群为容器创建网络，或者下载镜像的过程

• Running：Pod内所有的容器都已经被创建，且至少一个容器正在处于运行状态、正在启动状态或者重启状态

• Successed：Pod中所有容器都执行成功后退出，并且没有处于重启的容器

• Faild：Pod中所有容器都已退出，但是至少还有一个容器退出时为失败状态

• Unknow：由于一些原因，Pod的状态无法获取，通常是与Pod通信时错误导致的

二、Pod重启策略

• Always：只要容器失效退出就重启容器

• onFailure：当容器以非正常退出后重新启动容器

• Never：无论容器状态如何，都不重新启动容器

三、Pod的活性与就绪探针

1、Pod探针机制

在Kubernetes中Pod是最小的计算单元，而一个Pod又由多个容器组成，相当于每个容器就是一个应用，应用在运行期间，可能因为某也意外情况致使程序挂掉。那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，发生问题后进行重启等机制，就成为了重中之重的事情，考虑到这点 kubernetes 推出了活性探针机制。

有了活性探针后能保证程序在运行中如果挂掉能够自动重启，但是还有个经常遇到的问题，比如说，在 Kubernetes 中启动 Pod，显示明明 Pod 已经启动成功，且能访问里面的端口，但是却返回错误信息。还有就是在执行滚动更新时候，总会出现一段时间，Pod 对外提供网络访问，但是访问却发生 404，这两个原因，都是因为 Pod 已经成功启动，但是 Pod 的的容器中应用程序还在启动中导致，考虑到这点 Kubernetes 推出了就绪探针机制。

2、Pod两种探针

• LivenessProbe（存活探针）：存活探针的主要作用是，用指定的方式进入容器检测容器中的应用是否正常运行，如果检测失败，则认为容器不健康，那么 kubelet 将根据 Pod 中设置的 restartPolicy 策略来判断，Pod是否要进行重启，如果容器配置中没有配置 livenessProbe 存活探针， kubelet 将认为存活探针一直为成功状态

• ReadinessProbe（就绪探针）：用于判断容器中应用是否完成，当探测成功后才使Pod对外提供网络访问，设置容器 Ready 状态为 true ，如果探测失败，则设置容器的 Ready 状态为 false 。对于被Service管理的Pod，Service 与 Pod 、EndPoind 的关联关系也将基于Pod是否为 Ready 状态进行设置，如果Pod运行过程中 Ready 状态变为 false，则系统自动从 Service 关联的 EndPoint 列表中移除，如果Pod恢复为 Ready 状态，将再被加回 EndPoint 列表，通过这种机制就能防止将流量转发到不可用的Pod上。

3、Pod探针的探测方式与结果

目前LivenessProbe和ReadinessProbe两种探针都支持下面三种探测方法：

• ExecAction：在容器中执行指定的命令，如果能成功执行，则探测成功

• HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码200-400，则认为容器探测成功

• TCPSocketAction：通过容器IP地址和端口号执行TCP检查，如果能建立TCP连接，则探测成功

   

  探针探测结果有以下值：

• Success：表示通过检测

• Failure：表示未通过检测

• Unknow：表示检测没有正常进行

4、Pod探针的相关属性

两种探针有许多字段可选，可以用来更加精确的控制LivenessProbe和ReadinessProbe两种探针的探测：

• initialDelaySeconds：Pod启动后首次进行检查的等待时间，单位“秒”

• periodSeconds：检查的间隔时间，默认为10s，单位“秒”

• timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为1s，单位“秒”

• successThreshold：探针检测失败后认为成功的最小连接成功次数，默认为1s，在liveness探针中必须为1s，最小为1s

• failureThreshold：探测失败的重试次数，重试一定次数后将认为失败，在readiness探针中，Pod会被标记为未就绪，默认3s，最小值1s

5、两种探针的区别

总的来说 ReadinessProbe 和 LivenessProbe 是使用相同探测的方式，只是探测后对 Pod 的处置方式不同：

• ReadinessProbe：但检测失败后，将Pod的IP:Port从对应Service关联的EndPoint地址列表中删除

• LivenessProbe：当检测失败后将容器杀死，并根据Pod的重启策略来决定对应措施

四、探针使用示例

1、LivenessProbe探针使用示例

（1）通过Exec方式做健康检测

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - echo ok >  /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 1000
    livenessProbe:
      initialDelaySeconds: 15
      periodSeconds: 3
      exec:
        command:
        - cat
        - /tmp/healthy

通过执行 cat /tmp/healthy 来判断一个容器是否正常运行。再创建 /tmp/healthy文件10s后将其删除，而LivenessProbe健康检测的初始时间（initialDelaySeconds）为15s，探测结果为fail，将导致kubelet杀掉容器并重启它

（2）通过HTTPGetAction方式做健康探测

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: mydlqclub/springboot-helloworld:0.0.1
    livenessProbe:
      initialDelaySeconds: 20
      periodSeconds: 5
      timeoutSeconds: 10
      httpGet:
        scheme: HTTP
        port: 8081
        path: /actuator/health

探测结果的HTTP 状态码如果为200 - 400，则表示探测成功。如果探测失败，则会杀死Pod进行重启操作

httpGet探测方法有如下可选的控制字段

• scheme：用于测试连接的协议，默认为HTTP

• host：要连接的主机名，默认为Pod IP

• port：容器上要访问端口号或名称

• path：HTTP 服务器上的访问URL

• httpHeaders：自定义http请求Headers，http允许重复Headers

（3）通过TCP方式做健康探测

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: nginx:1.19.0
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 20
      periodSeconds: 10
      timeoutSeconds: 1

TCP 检查方式和 HTTP 检查方式非常相似，在容器启动 initialDelaySeconds 参数设定的时间后，kubelet 将发送第一个 livenessProbe 探针，尝试连接容器的 80 端口，如果连接失败则将杀死 Pod 重启容器。

2、ReadinessProbe探针使用示例

Pod 的 ReadinessProbe 探针使用方式和 LivenessProbe 探针探测方法一样，也是支持三种，只是一个是用于探测应用的存活，一个是判断是否对外提供流量的条件。

apiVersion: v1
kind: Service
metadata:
  name: springboot
  labels:
    app: springboot
spec:
  type: NodePort
  ports:
  - name: server
    port: 8080
    targetPort: 8080
    nodePort: 31180
  - name: managerment
    port: 8081
    targetPort: 8081
    nodePort: 31181
  selector:
    app: springboot
?
---
apiVersion: v1
kind: Pod
metadata:
  name: springboot
  labels:
    app: springboot
spec:
  containers:
  - name: springboot
    image: mydlqclub/springboot-helloworld:0.0.1
    ports:
    - name: server
      containerPort: 8080
    - name: managerment
      containerPort: 8081
    readinessProbe:
      httpGet:
        scheme: HTTP
        port: 8081
        path: /actuator/health
      initialDelaySeconds: 20
      periodSeconds: 10
      timeoutSeconds: 10

3、ReadinessProbe+LivenessProbe配合使用示例

apiVersion: v1
kind: Service
metadata:
  name: rlprobe
  labels:
    app: rlprobe
spec:
  type: NodePort
  ports:
  - name: server
    port: 8080
    targetPort: 8080
    nodePort: 32280
  - name: managerment
    port: 8081
    targetPort: 8081
    nodePort: 32281
  selector:
    app: rlprobe
?
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rlprobe
  labels:
    app: rlprobe
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rlprobe
  template:
    metadata:
      name: rlprobe
      labels:
        app: rlprobe
    spec:
      containers:
      - name: rl
        image: mydlqclub/springboot-helloworld:0.0.1
        ports:
        - name: server
          containerPort: 8080
        - name: managerment
          containerPort: 8081
?
        readinessProbe:
          httpGet:
            scheme: HTTP
            port: 8081
            path: /actuator/health
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10
        livenessProbe:
          httpGet:
            scheme: HTTP
            port: 8081
            path: /actuator/health
          initialDelaySeconds: 20
          periodSeconds: 5
          timeoutSeconds: 10

Kubernetes Pod健康检查机制

标签：init   inf   获取   完成   决定   failure   containe   socket   style   

原文地址：https://www.cnblogs.com/bigberg/p/13559308.html