10分钟搞懂K8S容器探针

K8S | 容器探针

前言

K8S作为云原生架构下最流行的服务编排平台，核心功能之一就是对该平台上的容器进行动态编排。

容器的启动（Starting）、运行（Running）、终止（Terminated）在K8S平台上频繁发生。

为了系统的高可用，只有当容器已经具备提供服务的能力时，才能讲服务流量转发给该容器。

容器的生命周期

容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。

• Waiting: 如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。
• Running: Running 状态表明容器正在执行状态并且没有问题发生。
• Terminated: 容器已经开始执行了，但是现在已经执行完成或者因为某些原因执行失败了。

一般情况下，容器的状态是如下图的方向进行流转的：

什么是容器探针

容器探针（Container Probes）是一种机制，由 kubelet 对容器执行的定期诊断，从而获取容器的状态。

容器探针是一个用于检测容器健康状况的 Kubernetes 对象，可以在容器启动或运行时间时执行命令和检查，以确定容器是否正常工作。

容器探针的三种类型

容器探针主要有三种类型：

• 存活探针（Liveness Probe）
• 就绪探针（Readiness Probe）
• 启动探针（Startup Probe）

1) 存活探针（Liveness Probe）

用于检测容器内部应用程序是否处于运行状态。如果探针检测到应用程序处于非运行状态，则容器将被认为已死亡，并将被自动重启或回收。

2) 就绪探针（Readiness Probe）：

用于检测容器是否已经准备好接受流量。如果探针检测到应用程序不可用，Kubernetes将不会将流量路由到容器，并将其从负载均衡池中删除。

3) 启动探针（Startup Probe）：

用于检测容器内应用程序是否已经启动完成。启动探针与就绪性探针非常相似，但其目的在于确定容器是否已经完成启动，而不是确定容器是否已经准备好接收流量。

为什么需要容器探针？

容器探针可以确保您的容器在任何时候都处于可预测的状态。

如果没有容器探针，那么容器对于K8S平台而言，就处于一个黑盒状态。下面是没有使用容器探针可能出现的一些case：

• 容器未启动，负载均衡就把流量转发给容器，导致请求大量异常
• 容器内服务不可用/发生异常，负载均衡把流量转发给容器，导致请求大量异常
• 容器已经不正常工作（如容器死锁导致的应用程序停止响应），K8S平台本身无法感知，不能即时低重启容器。

容器探针——如何进行探测?

使用探针来检查容器有四种不同的方法。每个探针都必须准确定义为这四种机制中的一种：

• exec：命令实现方式
• TCP Socket: TCP套接字检查实现方式
• HTTP GET：HTTP 请求实现方式
• gRPC：gRPC远程过程调用实现方式

容器探针 | 探测结果

不管是那种每次探测都将获得以下三种结果之一：

• Success（成功）容器通过了诊断。
• Failure（失败）容器未通过诊断。
• Unknown（未知）诊断失败，因此不会采取任何行动.

方式一：exec | 命令实现方式：

在容器内执行特定命令。如果命令退出时返回码为 0 则认为诊断成功。

举个例子， 我们要部署一个 Tomcat 服务到 Kubernetes 集群中，并进行健康状态检查。使用命令实现的探针方式，我们需要在 Tomcat Pod 的 YAML 文件中添加如下探针配置：

yaml复制代码
apiVersion: v1
kind: Pod
metadata:
  name: tomcat-pod
spec:
  containers:
    - name: tomcat
      image: tomcat:8.0
      ports:
        - containerPort: 8080
      livenessProbe:
        exec:
          command:
            - sh
            - -c
            - wget -q 0.0.0.0:8080
        initialDelaySeconds: 15    # 接入K8S集群后， 第一次探测延迟15s
        periodSeconds: 5    # 探测间隔5s

方式二：TCP Socket | TCP套接字检查实现方式

对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。

举个例子：我们要部署一个 Nginx 服务(端口为80）到 Kubernetes 集群，并进行健康状态检查。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.7.9
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

使用 TCP Socket 实现的容器探针主要适用于检查容器内进程是否正在监听某些网络套接字上的连接。

方式三：HTTP Get | HTTP GET请求检查实现方式

对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

前置条件： 使用httpGet实现方式的探针，需要容器内启动了HTTP的服务，并且提供了用于探针的接口， 如：HTTP GET /healthy

下面是使用httpGet方式对应的Pods配置

apiVersion: v1
kind: Pod
metadata:
  name: go-pod
spec:
  containers:
  - name: go-container
    image: golang:1.8-alpine
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /healthy
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

使用 HTTP GET 实现的容器探针主要适用于检查容器内 Web 服务是否正常工作等场景。

方式四：grpc | gRPC请求检查实现方式

使用 gRPC 执行一个远程过程调用。目标应该实现 gRPC 健康检查。如果响应的状态是 "SERVING"，则认为诊断成功。

前置条件： 使用grpc实现方式的探针，需要容器内启动了一个监听端口为 8080 的 gRPC 服务，并注册了一个健康状态检查的 gRPC 接口。这个接口返回固定状态（SERVING），可以在 Kubernetes 中作为容器探针来使用。