命令记不住

登陆

探针 Liveness 与 Readiness

  |   0 浏览

10.探针Liveness与Readiness

1.需求

  1. 首先是应用的健康状态上面，可以实时地进行观测；
  2. 第二个是可以获取应用的资源使用情况；
  3. 第三个是可以拿到应用的实时日志，进行问题的诊断与分析。

当出现了问题之后，首先要做的事情是要降低影响的范围，进行问题的调试与诊断。最后当出现问题的时候，理想的状况是：可以通过和 K8s 集成的自愈机制进行完整的恢复。

Liveness（存活探针） Readness（就绪探针）
介绍 用于判断容器是否存活，既Pod状态是否为running,如果Liveness探针判断容器不健康，则会触发kubelet杀掉容器，并根据配置的策略判断是否重启容器，如果默认不配置Liveness探针，则认为返回默认值认为成功 用于判断容器是否启动完成，既Pod的Condition是否为Ready,如果探测结果不成功，则会将Pod从Endpoint中移除，直至下次判断成功，再将Pod挂回到Endpoint上
检测失败 杀掉Pod 切断上层流量到Pod
适用场景 支持重新拉起的应用 启动后无法立即对外服务的应用
注意事项 不论是Liveness还是Readness探针，选择合适的探测方式可以防止被误操作

1.调大判断的超时阈值

2.调整判断的次数阈值

3.exec的如果是shell脚本判断，在容器中可能调用时间会非常长

4.使用tcpSocket的方式遇到TLS的场景，需要业务层判断是否有影响

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 之上，来实现一个具体的判断。

6. Global 的参数

Global 的参数。

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

7.注意事项

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

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