pod健康检查(liveness probe存活探针&&readiness probe 可读性探针)

Kubernetes集群当中,我们可以通过配置liveness probe(存活探针)和readiness probe(可读性探针)来影响容器的生存周期。参考文档:https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

kubelet 通过使用 liveness probe 来确定你的应用程序是否正在运行,通俗点将就是是否还活着。一般来说,如果你的程序一旦崩溃了, Kubernetes 就会立刻知道这个程序已经终止了,然后就会重启这个程序。而我们的 liveness probe 的目的就是来捕获到当前应用程序还没有终止,还没有崩溃,如果出现了这些情况,那么就重启处于该状态下的容器,使应用程序在存在 bug 的情况下依然能够继续运行下去。
kubelet使用活跃度探头知道什么时候重新启动的容器。例如,liveness probe可以捕获死锁,应用程序正在运行,但无法取得进展。在这种状态下重新启动容器可以继续存活。
kubelet 使用 readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了,现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态,因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态,那么我们就会将他从我们的工作队列(实际上就是我们后面需要重点学习的 Service)中移除出来,这样我们的流量就不会被路由到这个 Pod 里面来了。
使用readiness probe来了解容器何时准备开始接受流量。当所有容器准备就绪时,Pod被认为已准备就绪。此信号的一个用途是控制哪些Pod用作服务的后端。当Pod未就绪时,它将从服务负载平衡器中删除。例如当一个应用服务有大文件加载时,这种情况下不允许接受用户访问,readiness probe就不会对这类型的程序启动服务。
 

许多运行很长时间的应用程序最终会转换到损坏状态,除非重新启动,否则无法恢复。Kubernetes提供活体探测器来检测和纠正这种情况。

通过busybox来练习一下liveness probe

liveness-exec.yaml  liveness-http.yaml  pod-example.yaml  poststart-hook.yaml  prestop-hook.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: 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返回失败代码。

创建Pod:

kubectl apply -f liveness-exec.yaml

在30秒内,查看Pod事件:

kubectl describe pod liveness-exec

有消息指示活动探测失败,并且容器已被杀死并重新创建。

另一种活动探测器使用HTTP GET请求

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
  labels:
    app: liveness
spec:
  containers:
  - name: liveness
    image: cnych/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3

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

任何大于或等于200且小于400的代码表示成功。任何其他代码表示失败。

您可以在server.go中查看服务器的源代码 。

对于Container /healthz处于活动状态的前10秒,处理程序返回状态200.之后,处理程序返回状态500。

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})

在容器启动3秒后,kubelet开始执行运行状况检查。因此,前几次健康检查将成功。但是10秒后,运行状况检查将失败,并且kubelet将终止并重新启动Container。

要尝试HTTP活跃度检查,请创建一个Pod:

kubectl apply -f liveness-http.yaml

10秒后,查看Pod事件以验证活动探测失败并且Container已重新启动:

kubectl describe pod liveness-http

在v1.13之前的版本(包括v1.13)中,如果在运行pod的节点上设置了环境变量http_proxy(或HTTP_PROXY),则HTTP活动探针将使用该代理。在v1.13之后的版本中,本地HTTP代理环境变量设置不会影响HTTP活动探测。

定义TCP活动探测

第三种类型的活动探测器使用TCP套接字。使用此配置,kubelet将尝试在指定端口上打开容器的套接字。如果它可以建立连接,则容器被认为是健康的,如果它不能被认为是失败的话。

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

我们可以看到,TCP 检查的配置与 HTTP 检查非常相似,只是将httpGet替换成了tcpSocket。 而且我们同时使用了readiness probeliveness probe两种探针。 容器启动后5秒后,kubelet将发送第一个readiness probe(可读性探针)。 该探针会去连接容器的8080端,如果连接成功,则该 Pod 将被标记为就绪状态。然后Kubelet将每隔10秒钟执行一次该检查。

除了readiness probe之外,该配置还包括liveness probe。 容器启动15秒后,kubelet将运行第一个 liveness probe。 就像readiness probe一样,这将尝试去连接到容器的8080端口。如果liveness probe失败,容器将重新启动。

有的时候,应用程序可能暂时无法对外提供服务,例如,应用程序可能需要在启动期间加载大量数据或配置文件。 在这种情况下,您不想杀死应用程序,也不想对外提供服务。 那么这个时候我们就可以使用readiness probe来检测和减轻这些情况。 Pod中的容器可以报告自己还没有准备,不能处理Kubernetes服务发送过来的流量。

从上面的YAML文件我们可以看出readiness probe的配置跟liveness probe很像,基本上一致的。唯一的不同是使用readinessProbe而不是livenessProbe。两者如果同时使用的话就可以确保流量不会到达还未准备好的容器,准备好过后,如果应用程序出现了错误,则会重新启动容器。

另外除了上面的initialDelaySecondsperiodSeconds属性外,探针还可以配置如下几个参数:

  • timeoutSeconds:探测超时的秒数。默认为1秒。最小值为1。
  • initialDelaySeconds:启动活动或准备就绪探测之前容器启动后的秒数。
  • periodSeconds:执行探测的频率(以秒为单位)。默认为10秒。最小值为1。
  • failureThreshold:当Pod启动并且探测失败时,Kubernetes会failureThreshold在放弃之前尝试一次。在活动探测的情况下放弃意味着重新启动Pod。如果准备好探测,Pod将被标记为未准备好。默认为3.最小值为1。
  • successThreshold:失败后探测成功的最小连续成功次数。默认为1.活跃度必须为1。最小值为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无法解析它。

 

上一篇:logback与logstash简单整合


下一篇:pytest接口自动化测试框架搭建