作用:

  1. 首先是应用的健康状态上面,可以实时地进行观测;
  2. 第二个是可以获取应用的资源使用情况;
  3. 第三个是可以拿到应用的实时日志,进行问题的诊断与分析。
    当出现了问题之后,首先要做的事情是要降低影响的范围,进行问题的调试与诊断。最后当出现问题的时候,理想的状况是:可以通过和 K8s 集成的自愈机制进行完整的恢复。
    两种probe
    Liveness(存活探针)
    Readness(就绪探针)
    介绍
    用于判断容器是否存活,既 Pod 状态是否为 running,如果 Liveness 探针判断容器不健康,则会触发 kubelet 杀掉容器,并根据配置的策略判断是否重启容器,如果默认不配置 Liveness 探针,则认为返回默认值认为成功
    用于判断容器是否启动完成,既 Pod 的 Condition 是否为 Ready,如果探测结果不成功,则会将 Pod 从 Endpoint 中移除,直至下次判断成功,再将 Pod 挂回到 Endpoint 上
    检测失败
    Pod挂掉
    切断上层流量到 Pod
    适用场景
    支持重新拉起的应用
    启动后无法立即对外服务的应用
    注意事项
    不论是 Liveness 还是 Readness 探针,选择合适的探测方式可以防止被误操作

2.Liveness 存活指针

Liveness probe 来确定你的应用程序是否正在运行,通俗点将就是是否还活着。一般来说,如果你的程序一旦崩溃了, Kubernetes 就会立刻知道这个程序已经终止了,然后就会重启这个程序。而我们的 liveness probe 的目的就是来捕获到当前应用程序还没有终止,还没有崩溃,如果出现了这些情况,那么就重启处于该状态下的容器,使应用程序在存在 bug 的情况下依然能够继续运行下去。 kubelet 使用活跃度探头知道什么时候重新启动的容器。例如,liveness probe 可以捕获死锁,应用程序正在运行,但无法取得进展。在这种状态下重新启动容器可以继续存活。
3.Readiness 就绪探针

Readiness 也叫就绪指针,用来判断一个 pod 是否处在就绪状态。当一个 pod 处在就绪状态的时候,它才能够对外提供相应的服务,也就是说接入层的流量才能打到相应的 pod。当这个 pod 不处在就绪状态的时候,接入层会把相应的流量从这个 pod 上面进行摘除。
readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了,现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态,因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态,那么我们就会将他从我们的工作队列(实际上就是我们后面需要重点学习的 Service)中移除出来,这样我们的流量就不会被路由到这个 Pod 里面来了。 使用 readiness probe 来了解容器何时准备开始接受流量。当所有容器准备就绪时,Pod 被认为已准备就绪。此信号的一个用途是控制哪些 Pod 用作服务的后端。当 Pod 未就绪时,它将从服务负载平衡器中删除。例如当一个应用服务有大文件加载时,这种情况下不允许接受用户访问,readiness probe 就不会对这类型的程序启动服务。
4.探测方式

Liveness 指针和 Readiness 指针支持三种不同的探测方式:
1.第一种是 http.Get。它是通过发送 http Get 请求来进行判断的,当返回码是 200-399 之间的状态码时,标识这个应用是健康的
httpGet 里面有一个字段是路径,第二个字段是 port,第三个是 headers。这个地方有时需要通过类似像 header 头的一个机制做 health 的一个判断时,需要配置这个 header,通常情况下,可能只需要通过 health 和 port 的方式就可以了。
spec:
containers:

  • name: liveness-http
    image: xxxxx/busybox
    livenessProbe:
    httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: Custom-Header
    value: Awesome
    initialDelaySeconds: 3
    2.第二种探测方式是 Exec,它是通过执行容器中的一个命令来判断当前的服务是否是正常的,当命令的返回结果是 0,则标识容器是健康的。
    Liveness probe,它里面配置了一个 exec 的一个诊断。接下来,它又配置了一个 command 的字段,这个 command 字段里面通过 cat 一个具体的文件来判断当前 Liveness probe 的状态,当这个文件里面返回的结果是 0 时,或者说这个命令返回是 0 时,它会认为此时这个 pod 是处在健康的一个状态。
    spec:
    containers:
  • name: liveness
    image: xxxxx/busybox
    args:
    • /bin/sh
    • -c
    • touch /tmp/healthy
      lienessProbe:
      exec:
      command:
      • cat
    • /tmp/healthy
      3.第三种探测方式是 tcpSocket,它是通过探测容器的 IP 和 Port 进行 TCP 健康检查,如果这个 TCP 的链接能够正常被建立,那么标识当前这个容器是健康的
      tcpSocket 的使用方式其实也比较简单,你只需要设置一个检测的端口,像这个例子里面使用的是 8080 端口,当这个 8080 端口 tcp connect 审核正常被建立的时候,那 tecSocket,Probe 会认为是健康的一个状态。
      spec:
      containers:
  • name: goproxy
    image: xxxxx/busybox
    ports:
  • containerPort: 8080
    readinessProbe:
    tcpSocket:
    port: 8080
    livenessProbe:
    tcpSocket:
    port: 8080
    5.探测结果

从探测结果来讲主要分为三种:

  • 第一种是 success,当状态是 success 的时候,表示 container 通过了健康检查,也就是 Liveness probe 或 Readiness probe 是正常的一个状态;
  • 第二种是 Failure,Failure 表示的是这个 container 没有通过健康检查,如果没有通过健康检查的话,那么此时就会进行相应的一个处理,那在 Readiness 处理的一个方式就是通过 service。service 层将没有通过 Readiness 的 pod 进行摘除,而 Liveness 就是将这个 pod 进行重新拉起,或者是删除。
  • 第三种状态是 Unknown,Unknown 是表示说当前的执行的机制没有进行完整的一个执行,可能是因为类似像超时或者像一些脚本没有及时返回,那么此时 Readiness-probe 或 Liveness-probe 会不做任何的一个操作,会等待下一次的机制来进行检验。
    那在 kubelet 里面有一个叫 ProbeManager 的组件,这个组件里面会包含 Liveness-probe 或 Readiness-probe,这两个 probe 会将相应的 Liveness 诊断和 Readiness 诊断作用在 pod 之上,来实现一个具体的判断。
  1. Global 的参数

Global 的参数。

  • 第一个参数叫 initialDelaySeconds,它表示的是说这个 pod 启动延迟多久进行一次检查,比如说现在有一个 Java 的应用,它启动的时间可能会比较长,因为涉及到 jvm 的启动,包括 Java 自身 jar 的加载。所以前期,可能有一段时间是没有办法被检测的,而这个时间又是可预期的,那这时可能要设置一下 initialDelaySeconds;
  • 第二个是 periodSeconds,它表示的是检测的时间间隔,正常默认的这个值是 10 秒;
  • 第三个字段是 timeoutSeconds,它表示的是检测的超时时间,当超时时间之内没有检测成功,那它会认为是失败的一个状态;
  • 第四个是 successThreshold,它表示的是:当这个 pod 从探测失败到再一次判断探测成功,所需要的阈值次数,默认情况下是 1 次,表示原本是失败的,那接下来探测这一次成功了,就会认为这个 pod 是处在一个探针状态正常的一个状态;
  • 最后一个参数是 failureThreshold,它表示的是探测失败的重试次数,默认值是 3,表示的是当从一个健康的状态连续探测 3 次失败,那此时会判断当前这个 pod 的状态处在一个失败的状态。

两种probe相互作用,只设置其中一种都无法正常监测集群内容器健康状态。
例如:只配置了Liveness,那么在容器启动,应用还没有成功就绪之前,这个时候Pod是ready的(因为容器成功启动了)。那么流量就会被引入到容器的应用中,可能会导致请求失败。虽然在Liveness检查失败后,重启容器,此时Pod的ready的condition会变为false。但是前面会有一些流量因为错误状态导入。

当然只配置了Readiness是无法触发容器重启的

注意事项:
在使用 Liveness 指针和 Readiness 指针的时候有一些注意事项。因为不论是 Liveness 指针还是 Readiness 指针都需要配置合适的探测方式,以免被误操作。

  • 第一个是调大超时的阈值,因为在容器里面执行一个 shell 脚本,它的执行时长是非常长的,平时在一台 ecs 或者在一台 vm 上执行,可能 3 秒钟返回的一个脚本在容器里面需要 30 秒钟。所以这个时间是需要在容器里面事先进行一个判断的,那如果可以调大超时阈值的方式,来防止由于容器压力比较大的时候出现偶发的超时;
  • 第二个是调整判断的一个次数,3 次的默认值其实在比较短周期的判断周期之下,不一定是最佳实践,适当调整一下判断的次数也是一个比较好的方式;
  • 第三个是 exec,如果是使用 shell 脚本的这个判断,调用时间会比较长,比较建议大家可以使用类似像一些编译性的脚本 Golang 或者一些 C 语言、C++ 编译出来的这个二进制的 binary 进行判断,那这种通常会比 shell 脚本的执行效率高 30% 到 50%;
  • 第四个是如果使用 tcpSocket 方式进行判断的时候,如果遇到了 TLS 的服务,那可能会造成后边 TLS 里面有很多这种未健全的 tcp connection,那这个时候需要自己对业务场景上来判断,这种的链接是否会对业务造成影响

应用部署
vi liveness.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness-exec
  name: liveness-exec
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness-exec
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/healthy"]
      initialDelaySeconds: 5    #探测延时时长,第一次探测前等待5秒,默认为0
      periodSeconds: 5          #每5秒执行一次liveness探测,默认值10秒,最小1秒
      timeoutSeconds: 2         #超长时长,默认为1s,最小值也为1s
      failureThreshold: 3       #处于成功状态时,探测操作至少连续多少次的失败才被视为检测不通过,默认为3,最小为1

创建

kubectl apply -f live.yaml --validate=false

查看

kubectl describe po liveness-exec
Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  3m24s                default-scheduler  Successfully assigned kuberhealthy/liveness-exec to dce-10-6-116-12
  Normal   Pulled     67s (x3 over 2m59s)  kubelet            Successfully pulled image "busybox"
  Normal   Created    66s (x3 over 2m59s)  kubelet            Created container liveness-exec
  Normal   Started    65s (x3 over 2m58s)  kubelet            Started container liveness-exec
  Warning  Unhealthy  42s (x9 over 2m47s)  kubelet            Liveness probe failed:
  Normal   Killing    42s (x3 over 2m37s)  kubelet            Container liveness-exec failed liveness probe, will be restarted
  Normal   Pulling    12s (x4 over 3m19s)  kubelet            Pulling image "busybox"

验证成功

http方式

apiVersion : v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness-http
    image: nginx
    ports:
    - name: http
      containerPort: 80
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh" ,"-c","echo liveness-http test > /usr/share/nginx/html/health"]
    livenessProbe:
      httpGet:
        path: /health
        port: http
        scheme: HTTP

创建

[root@dce-10-6-116-10 ~]# kubectl apply -f live-http.yaml --validate=false
[root@dce-10-6-116-10 ~]# kubectl get po -o wide
liveness-http           1/1     Running             0          91s   172.29.213.217   dce-10-6-116-12   <none>           <none>

测试

[root@dce-10-6-116-10 ~]# curl 172.29.213.217/health
liveness-http test

删除测试页面health

[root@dce-10-6-116-10 ~]# curl 172.29.213.217/health
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.21.3</center>
</body>
</html>

发现容器重启一次

[root@dce-10-6-116-10 ~]# kubectl get po -o wide
liveness-http           1/1     Running             1          7m13s   172.29.213.217   dce-10-6-116-12   <none>           <none>
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐