Kubernetes—健康检查

官方文档网址：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

探针类型有三种：

ExecAction（shell命令）
TCPSocketAction（针对端口）
HTTPGetAction（url get请求）

Probe有以下两种类型：

Liveness probe存活状态检测 判定主容器是否处于运行状态 Readines probe就绪状态检测
判定主容器中的主进程是否准备就绪并可以对外提供服务

Liveness probe区别Readines probe
Liveness probe是按照他所设定的标准检查容器是否符合规则，如果不符合就重启容器，这里的重启容器是指重新来一个新的容器，
Readines probe是指按照他的标准来检查容器是否可以对外提供服务并为其引入流量
如果他检测失败，那么service的endpoint里面将不会被转发，
如下图所示

此图为两者检查都失败

此图为Liveness probe成功，Readines probe失败

所以存活并不一定就绪，进程运行并不一定提供服务，就比如nginx运行但是网页文件没了，只能说未就绪但是还活着，具体怎么设置还需要按照需求来执行，但是两种检测机制是必须都得有的，

Probe支持以下三种检查方法：
httpGet 发送HTTP请求，返回200-400范围状态码为成功。
exec 执行Shell命令（命令一定得存在）返回状态码是0为成功
tcpSocket 发起TCP Socket建立成功

如果容器端口有命名，那么我们可以直接用命名例如

配置探针字段释意

initialDelaySeconds：启动活动或准备就绪探测之前容器启动后的秒数。
periodSeconds：执行探测的频率（以秒为单位）。默认为10秒。最小值为1。
timeoutSeconds：探测超时的秒数。默认为1秒。最小值为1。
successThreshold：失败后探测成功的最小连续成功次数。默认为1.活跃度必须为1。最小值为1。
failureThreshold：当Pod启动并且探测失败时，Kubernetes会failureThreshold在放弃之前尝试一次。在活动探测的情况下放弃意味着重新启动Pod。如果准备好探测，Pod将被标记为未准备好。默认为3.最小值为1。

HTTP探针 具有可以设置的其他字段httpGet：
host：要连接的主机名，默认为pod IP。您可能希望在httpHeaders中设置“主机”。
scheme：用于连接主机的方案（HTTP或HTTPS）。默认为HTTP。
path：HTTP服务器上的访问路径。
httpHeaders：要在请求中设置的自定义标头。HTTP允许重复标头。
port：容器上要访问的端口的名称或编号。数字必须在1到65535的范围内。

对于HTTP探测，kubelet将HTTP请求发送到指定的路径和端口以执行检查。kubelet将探测器发送到pod的IP地址，除非地址被可选host字段覆盖httpGet。如果 scheme字段设置为HTTPS，则kubelet会发送跳过证书验证的HTTPS请求。在大多数情况下，您不希望设置该host字段。这是您设置它的一个场景。假设Container侦听127.0.0.1并且Pod的hostNetwork字段为true。然后host，在httpGet，应设置为127.0.0.1。如果您的pod依赖虚拟主机，这可能是更常见的情况，您不应该使用host，而是设置Host标头httpHeaders。
对于探测器，kubelet在节点处而不是在pod中进行探测连接，这意味着您无法在host参数中使用服务名称，因为kubelet无法解析它。

格式分别为
(1)Httpget格式

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

在配置文件中，您可以看到Pod具有单个Container。该periodSeconds字段指定kubelet应每3秒执行一次活跃度探测。该initialDelaySeconds字段告诉kubelet它应该在执行第一次探测之前等待3秒。为了执行探测，kubelet向在Container中运行的服务器发送HTTP GET请求并侦听端口8080.如果服务器/healthz路径的处理程序返回成功代码，则kubelet认为Container是活动且健康的。如果处理程序返回失败代码，则kubelet会终止Container并重新启动它。
任何大于或等于200且小于400的代码表示成功。任何其他代码表示失败。

(2)Exec格式

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

在配置文件中，您可以看到Pod具有单个Container。该periodSeconds字段指定kubelet应每5秒执行一次活跃度探测。该initialDelaySeconds字段告诉kubelet它应该在执行第一次探测之前等待5秒。要执行探测，kubelet将cat /tmp/healthy在Container中执行命令。如果命令成功，则返回0，并且kubelet认为Container是活动且健康的。如果该命令返回非零值，则kubelet会终止Container并重新启动它。
当Container启动时，它会执行以下命令：
/bin/sh -c “touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600”
在Container的生命的前30秒，有一个/tmp/healthy文件。因此，在前30秒内，该命令cat /tmp/healthy返回成功代码。30秒后，cat /tmp/healthy返回失败代码。
(3)tcpSocker格式
第三种类型的活动探测器使用TCP套接字。使用此配置，kubelet将尝试在指定端口上打开容器的套接字。如果它可以建立连接，则容器被认为是健康的，如果它不能被认为是失败的话。

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

如您所见，TCP检查的配置与HTTP检查非常相似。此示例使用就绪和活性探针。在容器启动5秒后，kubelet将发送第一个就绪探测器。这将尝试连接到goproxy端口8080上的容器。如果探测成功，则该pod将标记为就绪。kubelet将每10秒继续运行此检查。
除准备探测外，此配置还包括活动探测。在容器启动15秒后，kubelet将运行第一个活体探测器。就像准备探测一样，这将尝试连接到goproxy端口8080上的 容器。如果活动探测失败，容器将重新启动。