配置pod和容器之---配置pod的liveness探针和readiness探针

本文参照官网相关内容,根据提出的以下疑问来学习介绍Pod的存活探针和准备探针。

问题1:为什么要配置探针,这两个探针有什么区别。

问题2:如何配置探针,配置探针后,pod有什么状态变化。

定义:探针Probe描述了对容器执行的运行状况检查,以确定它是否处于活动状态或已准备好接收流量。


问题1:在pod内为容器配置活动性探针和就绪性探针。主要是使kubelet使用liveness探针知道什么时候重新启动容器。例如:活动性探针可以捕获死锁,当应用程序正在运行,发生死锁,程序无法进行下去。在这种状态下可以通过重新启动容器使得应用程序更容易使用。kubelet使用readyness探测器来了解容器何时准备开始接受流量。当所有容器都准备就绪时,Pod被认为已准备就绪。此信号的一个用途是控制哪些Pod用作服务的后端。当Pod未就绪时,它将从服务负载平衡器中删除。


       在了解了容器存活性探针和就绪探针的基本概念和区别后,我们简单介绍一下K8S是如何让探针起作用的

1)probe探针是通过周期性地诊断kubelet上的容器。为了实现探测,kubelet调用容器实现的处理程序(Handler)。处理程序有三种类型:

  • ExecAction:在Container内执行指定的命令。如果命令以状态代码0退出,则认为诊断成功。(shell不起作用)

  • TCPSocketAction:对指定端口上的Container的IP地址执行TCP检查。如果端口打开,则诊断被认为是成功的。

  • HTTPGetAction:对指定端口和路径上的Container的IP地址执行HTTP Get请求。如果响应的状态代码大于或等于200且小于400,则认为诊断成功。

每个探针都有以下三个结果的一种:

  • Success: 容器通过了诊断。
  • Failure: 容器未通过诊断。
  • Unknown: 诊断失败,因此不应采取任何措施

通过上述的描述,我们基本了解了探针是如何探测容器是否健康运行,是否能够接受流量。下一步我们学习如何配置容器的探针。

问题2:根据以上的描述我们可以了解到kubelet调用容器的Headler来探测容器的健康状态,并且有三种方式可以进行探测。

三种方式分别是:1)command命令直接探测;2)httpGet探测;3)TCPsocket进行探测。下面通过具体的案例进行分析三种不同方式探针配置。

首先介绍第一种COMMAND探测,代码如下:


apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: bxhdocker/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 30"

对于Container的生命的前30秒,有一个/tmp/healthy文件。因此,在前30秒内,该命令cat /tmp/healthy返回成功代码。30秒后,cat /tmp/healthy返回失败代码。

       因此通过以上代码创建的pod应用状态将会是在30s内pod运行状态status状态为running,有消息指示活动探测失败,并且容器已被杀死并30s后重新创建。

第二种方式:HTTP GET请求探针


活动探测器使用HTTP GET请求。以下是基于k8s.gcr.io/liveness 映像运行容器的Pod的配置文件。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-gotest1
spec:
  containers:
  - name: liveness
    image: 192.168.106.129:5000/bxhdocker/gotest:v2.0
    livenessProbe:
      httpGet:
        path: /hello
        port: 50070
      initialDelaySeconds: 5
      periodSeconds: 3

kubelet向在Container中运行的服务器发送HTTP GET请求并侦听端口8080.如果服务器/healthz路径的处理程序返回成功代码,则kubelet认为Container是活动且健康的。如果处理程序返回失败代码,则kubelet会终止Container并重新启动它。

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

对于Container /hello处于活动状态的前30秒,处理程序返回状态200.之后,处理程序返回状态500。http代码如下:

package main

import (
        "net/http"
        "log"
        "fmt"
        "time"
)

func init() {
        log.SetFlags(log.Lshortfile | log.LstdFlags)
}

func main() {
        http.HandleFunc("/hello", HelloHandler)
        log.Fatal(http.ListenAndServe(":50070", nil))
}


func HelloHandler(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"))
    }
   fmt.Println("hello world")
}

第三种类型的活动探测器使用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上的 容器。如果活动探测失败,容器将重新启动。

 

配置探针参数


探针有许多字段,您可以使用它们来更精确地控制活动和准备情况检查的行为:

  • 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中设置“Host”。
  • scheme:用于连接主机(HTTP或HTTPS)的方案。默认为HTTP。
  • path:HTTP服务器上的访问路径。
  • httpHeaders:要在请求中设置的自定义标头。HTTP允许重复标头。
  • port:容器上要访问的端口的名称或编号。数字必须在1到65535的范围内。

对于HTTP探测,kubelet将HTTP请求发送到指定的路径和端口以执行检查。kubelet将探测器发送到pod的IP地址,除非地址被可选host字段覆盖httpGet。如果 scheme字段设置为HTTPS,则kubelet会发送跳过证书验证的HTTPS请求。在大多数情况下,您不希望设置该host字段。

你可能感兴趣的:(docker,kubernetes)