概述

Probe探针是由kubelet对容器执行的定期诊断。具体地，Probe探针支持以下几种实现方式：

「1. Exec」

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

「2. grpc」

使用gRPC执行一个远程过程调用，目标应该实现gRPC健康检查。如果响应的状态是SERVING，则认为诊断成功；gRPC探针是一个alpha特性，必须先启用GRPCContainerProbe特性门控

「3. HTTP GET」

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

「4. TCP Socket」

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

Readiness Probe 就绪探针

用于指示容器是否准备好为请求提供服务。因为有些应用在启动后不是立即可以投入使用的，其需要需要一定的初始化时间以用于数据加载预热等操作。如果就绪探针报告失败，则会从Service的Endpoints列表中移除该Pod的IP地址。其中，初始延迟之前的状态值默认为失败；如果未指定就绪探针，则默认状态为成功

# 创建应用的RS资源

apiVersion: apps/v1
# 资源类型
kind: ReplicaSet
metadata:
  name: my-rs-apple-app
spec:
 # 副本数量
  replicas: 2
  # 标签选择器
  selector:
    matchLabels:
      company: Apple
  # Pod模板
  template:
    metadata:
      # 标签信息
      labels:
        company: Apple
    spec:
      # 容器信息
      containers:
      # 容器名称
      - name: my-apple-app
        # 镜像信息
        image: luksa/kubia
        # 仅用于展示容器所使用的端口
        ports:
          - containerPort: 8080
            protocol: TCP    
        # 就绪探针: Exec探针
        readinessProbe:
          # 容器启动后多久开始进行探测, Unit: s
          initialDelaySeconds: 20
          # 探针等待响应的时限, 超时则本次探测失败。Unit: s
          timeoutSeconds: 2
          # 探测周期, Unit: s
          periodSeconds: 20  
          # 连续探测1次成功表示成功
          successThreshold: 1
          # 连续探测5次失败表示失败
          failureThreshold: 5
          # Exec探针: 就绪探针将定期执行 ls /var/ready 命令
          # 如果文件存在，则ls命令的返回值为0。此时就绪探针就会成功
          # 如果文件不存在，则ls命令的返回值为非零。此时就绪探针就会失败
          exec:
            # 设置容器启动时执行的命令、参数
            command:
            - ls
            - /var/ready

---

# 创建应用的Service资源
apiVersion: v1
# 资源类型
kind: Service
metadata:
  name: apple-service
spec:
  # 标签选择器    
  selector:
    company: Apple
  ports:
    - port: 12345  # 服务监听端口
      targetPort: 8080  # 服务将请求转发到的目标端口

创建上述资源后，不难发现该RS的2个Pod的均为未就绪

figure 1.jpeg

当我们对某个Pod容器按照探针指定的路径建立文件/目录后，稍后即会发现该Pod的状态即为就绪。同时相应服务的Endpoints列表中也会包含该Pod的IP。说明此时该Pod已经准备就绪，可以通过Service资源对外提供服务

figure 2.jpeg

需要注意的是，由于Readiness Probe 就绪探针是定期执行的。故即使由于此前就绪探针执行成功，进而使得该Pod状态为就绪状态了。后续一旦就绪探针执行失败，则该Pod的状态会再次变为未就绪。直到就绪探针执行成功为止，Pod状态才会再次发生更新

Liveness Probe 存活探针

指示容器是否正在运行。如果存活探针结果为失败，则kubelet会杀死该容器并根据重启策略来决定是否需要重启该容器。如果容器不提供存活探针，则默认为成功。不难看出通过存活探针可以很方便地对我们的应用加入心跳机制，保障高可用性。下面即是一个典型的配置示例。值得一提的是，对于存活探针而言，其并不会等待就绪探针执行成功后，才开始进行探测。换言之，就绪探针与存活探针之间在执行时机上没有任何的依赖、关联

apiVersion: v1
# 资源类型
kind: Pod
metadata:
  # Pod 名称
  name: my-kubia-pod-3
spec:
  # 容器信息
  containers:
  # 容器名称
  - name: my-kubia-3
    # 镜像信息
    image: luksa/kubia
    # 仅用于展示容器所使用的端口
    ports:
      - containerPort: 8080
        protocol: TCP
    # 存活探针: HTTP GET探针
    livenessProbe:
      # 容器启动后多久开始进行探测, Unit: s
      initialDelaySeconds: 20
      # 探针等待响应的时限, 超时则本次探测失败。Unit: s
      timeoutSeconds: 2
      # 探测周期, Unit: s
      periodSeconds: 20  
      # 连续探测1次成功表示成功
      successThreshold: 1
      # 连续探测5次失败表示失败
      failureThreshold: 5
      # HTTP GET探针请求的路径、端口信息
      httpGet:        
        path: /
        port: 8080

Startup Probe 启动探针

指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会先被禁用，直到此探针成功为止。显然该探针十分适用于启动换成非常缓慢的应用。如果启动探测失败，则kubelet会杀死该容器并根据重启策略来决定是否需要重启该容器。如果容器没有提供启动探针，则默认为成功。下面即是一个典型的配置示例

apiVersion: v1
# 资源类型
kind: Pod
metadata:
  # Pod 名称
  name: my-kubia-pod-9
spec:
  # 容器信息
  containers:
  # 容器名称
  - name: my-kubia-9
    # 镜像信息
    image: luksa/kubia
    # 仅用于展示容器所使用的端口
    ports:
      - containerPort: 8080
        protocol: TCP
    # 启动探针: HTTP GET探针
    startupProbe:
      # 容器启动后多久开始进行探测, Unit: s
      initialDelaySeconds: 20
      # 探针等待响应的时限, 超时则本次探测失败。Unit: s
      timeoutSeconds: 2
      # 探测周期, Unit: s
      periodSeconds: 20  
      # 连续探测1次成功表示成功
      successThreshold: 1
      # 连续探测5次失败表示失败
      failureThreshold: 5
      # HTTP GET探针请求的路径、端口信息
      httpGet:        
        path: /
        port: 8080