kubernetes-探针

一、探针简介

探针是由kubelet对容器执行的定期诊断，以保证Pod的状态始终处于运行状态，要执行诊断，kubelet调用由容器实现的Handler（处理程序），有三种处理程序：

• ExecAction：在容器内执行指定命令，如果命令退出时返回码为0则认为诊断成功
• TCPSocketAction：对指定端口上的容器的IP地址进行TCP检查，如果端口打开，则诊断被认为时成功的
• HTTPGetAction：对指定端口和路径上的容器的IP地址执行HTTPGet请求，如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

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

• 成功：容器通过了诊断
• 失败：容器未通过诊断
• 未知：诊断失败，因此不会采取任何行动

二、探针类型

针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：

• livenessProbe：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器，并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。

• readinessProbe：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与Pod匹配的所有服务的端点列表中删除该 Pod 的 IP 地址（endpoints）。 初始延迟之前的就绪态的状态值默认为 Failure。如果容器不提供就绪态探针，则默认状态为 Success。readinessProbe用于控制pod是否添加至service后端。

• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。如果容器没有提供启动探测，则默认状态为 Success。

三、探针配置

探针有很多配置字段，可以使用这些字段精确的控制存活和就绪检测行为

• initialDelaySeconds：初始化延迟时间，告诉kubelet在执行第一次探测前应该等待多少秒，默认是0秒，最小值是0
• periodSeconds：探测周期间隔时间，指定了kubelet应该多少秒执行一次存活探测，默认是10秒。最小值是0
• timeoutSeconds：单次探测超时时间，探测后等待多少秒，默认值是1秒，最小值是1
• successThreshold：从失败转为成功的重试次数，探测器在失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是1
• failureThreshold：从成功转为失败的重试次数，当pod启动了并且探测到失败，kubernetes的重试次数，存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃pod会被打上未就绪的标签，默认值是3，最小值是1.

HTTP探测器可以在HTTPGet上配置额外的字段：

• host：连接使用的主机名，默认是pod的ip，也可以在http头中设置Host来代替，大多数情况下不用设置host字段，当pod的hostNetwork字段设置未true后，httpGet中的host字段应该设置为127.0.0.1
• scheme：用于设置连接主机的方式（http还是https），默认是http
• path：方位http服务的路径
• httpHeaders：请求中自定义http头，http头字段允许重复
• port：访问容器的端口号或者端口名，端口号必须在1-65535之间

ExecAction探针示例

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

TCP探针示例

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

HTTP探针示例

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

使用启动探测器保护慢启动容器

有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。 要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。 技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置 failureThreshold * periodSeconds 参数来保证有足够长的时间应对糟糕情况下的启动时间。

所以，前面的例子就变成了：

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

幸亏有启动探测，应用程序将会有最多 5 分钟(30 * 10 = 300s) 的时间来完成它的启动。 一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁可以快速响应。 如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 restartPolicy 来设置 Pod 状态。

四、livenessProbe和readinessProbe的对比

1、配置参数一样
2、livenessProbe连续探测失败会重启、重建pod；readinessProbe不会执行重启或者重建pod操作
3、livenessProbe连续检测指定次数失败后会将容器置于（Crash Loop BackOff）且不可用，readinessProbe不会
4、readinessProbe连续探测失败会从service的endpoints中删除该pod，liveninessProbe不具备此功能，但是会将容器挂起livenessProbe
总结：livenessProbe用于控制是否重启pod，readinessProbe用于控制pod是否添加至service