记录一下k8s三种探针的一些见解和一些骚操作

什么是k8s的探针

在 Kubernetes（k8s）中，有三种主要的探针：liveness probe（存活探针）、readiness probe（就绪探针）和 startup probe（启动探针），它们的原理如下：

• ①Liveness Probe（存活探针）
  • 原理：用于检测容器是否还在运行。Kubernetes 会定期（根据配置的时间间隔）执行存活探针定义的检查。如果检查失败，容器会被认为是不健康的，k8s 将会根据配置的重启策略（如 Always、OnFailure、Never）来决定是否重启容器。
  • 检查方式：
    • ExecAction：在容器内执行指定的命令。例如，对于一个基于 Java 的 Web 应用容器，可以执行ps -ef | grep java来检查 Java 进程是否在运行。如果命令的返回码是 0，表示检查成功；非 0 则表示失败。
    • TCPSocketAction：尝试通过 TCP 协议连接到容器内指定的端口。比如，对于一个运行 HTTP 服务的容器，可以检查 80 端口是否能够建立 TCP 连接。如果能够成功建立连接，说明容器健康；反之则不健康。
    • HTTPGetAction：向容器内指定的路径发送 HTTP GET 请求。以一个运行 Spring Boot 应用的容器为例，可向/actuator/health路径发送请求，根据返回的 HTTP 状态码来判断容器健康状况。如果返回的状态码在 200 - 399 之间，认为检查成功；其他状态码则认为失败。
• ②Readiness Probe（就绪探针）
  • 原理：用来判断容器是否已经准备好接收请求流量。与存活探针不同，就绪探针关注的是容器是否能够正确地处理请求。只有当容器的就绪探针检查成功时，才会将流量路由到该容器。这在容器启动过程中或者容器暂时无法处理请求（如正在加载配置文件、建立数据库连接等）的场景下非常有用。
  • 检查方式：
    • ExecAction：同存活探针中的 ExecAction，在容器内执行命令来检查容器是否就绪。例如，对于一个需要加载大量数据到缓存的应用容器，可以执行一个脚本来检查缓存是否已经加载完成。
    • TCPSocketAction：也是类似存活探针的方式，检查容器内指定端口是否可以建立 TCP 连接。但这里更侧重于检查容器的服务是否已经准备好接收请求，比如检查一个数据库容器的 3306 端口是否能够接收 SQL 连接请求。
    • HTTPGetAction：向容器内指定的路径发送 HTTP GET 请求，根据返回的状态码来判断。例如，对于一个 Web API 容器，可以向/api/v1/status路径发送请求，返回 200 状态码表示容器已经就绪，可以接收请求。
• ③Startup Probe（启动探针）
  • 原理：主要用于处理容器启动时间较长的情况。在容器启动期间，启动探针会覆盖存活探针的检查。这意味着在启动探针检查成功之前，即使存活探针检查失败，容器也不会被重启。只有当启动探针成功后，存活探针才会开始正常检查。这样可以确保容器有足够的时间来完成初始化过程，如加载复杂的配置、初始化数据库连接等。
  • 检查方式：
    • ExecAction：在容器启动过程中执行指定命令来检查启动状态。例如，对于一个容器化的机器学习模型服务，可能需要在启动时加载大量的模型权重文件，可以执行一个检查模型文件是否加载完成的命令。
    • TCPSocketAction：检查容器内指定端口是否能够建立 TCP 连接。例如，对于一个启动较慢的消息队列容器，可以检查其监听端口是否已经打开，以确定其是否完成启动。
    • HTTPGetAction：向容器内指定的路径发送 HTTP GET 请求并检查返回状态码。比如，对于一个基于 Flask 的应用，在启动时可以向/startup_check路径发送请求，当返回 200 状态码时，表示容器已经成功启动。

探针时间设置

• Liveness Probe（存活探针）设置
  • 时间间隔（periodSeconds）：
    • 在设置了启动探针的情况下，对于大多数应用，初始值可以设置在10秒以内，启动完成后马上进行存活探针。在没有设置启动探针的情况下，需要对应用启动的时间做一个大概的判断，最好是刚好在应用启动的10 - 30秒之后去检测，过早的检测会导致误判导致pod一直重启，太晚检测又浪费时间，在滚动更新的时候会特别慢。容器分配的CPU数量会影响启动速度，以一个java程序为例，1核cpu对比2核cpu有明显变慢。
    • 这个间隔是指 k8s检查容器是否存活的时间周期，这个时间间隔要高于超时时间。你设置5秒超时，3秒检查一次，也能运行，不过最好不要这么做。
  • 超时时间（timeoutSeconds）：
    • 一般设置为 1 - 5 秒。例如，对于一个通过 HTTPGetAction 检查的简单 Web 服务，设置为 3 秒比较合适。超时时间是指等待检查操作完成的最长时间，如果在这个时间内检查没有完成，就认为检查失败。如果容器内的检查操作可能比较耗时，比如执行一个复杂的数据库查询作为检查操作，可能需要适当延长超时时间。
  • 成功阈值（successThreshold）和失败阈值（failureThreshold）：
    • 成功阈值通常为 1，即只要一次检查成功就认为容器是存活的。失败阈值可以根据应用的稳定性和重要性来设置，一般在 3 - 5 之间。例如，对于一个关键的后端服务，设置失败阈值为 3，如果连续 3 次存活检查都失败，就会触发容器重启。
• Readiness Probe（就绪探针）设置
  • 时间间隔（periodSeconds）：
    • 同存活性探针。
  • 超时时间（timeoutSeconds）：
    • 通常设置为 1 - 3 秒。对于一个通过 TCP 连接检查是否就绪的容器，设置为 2 秒比较合适。超时时间用于控制检查容器是否就绪的操作等待时间。就绪探针的超时时间一般可以设置比存活探针短，3秒超时的时候，确实是到了要重启pod的时候，但是一般来说1 - 2秒的超时，对于系统来说就是有问题的了，这时候稳妥起见可以让该pod暂时不可被调度。正常来说，k8s从内部去进行HTTP/TCP连接，都是毫秒级返回，你大概率也不会选一个需要查大量数据的接口作为探针对象吧。
  • 成功阈值（successThreshold）和失败阈值（failureThreshold）：
    • 成功阈值一般为 1，失败阈值可以设置为 2 - 3。例如，对于一个提供 API 服务的容器，设置失败阈值为 2，如果连续 2 次就绪检查都失败，那么在这段时间内就不会将流量路由到这个容器。如果实例多，且追求用户尽可能少出现报错，失败次数也可以设置为1（PS：出错了就反省一下）。

• Startup Probe（启动探针）设置

  • 时间间隔（periodSeconds）：
    • 初始值需要根据服务的类型来定，一般一个go程序只需要几秒钟，一个java程序可能需要120秒甚至更长，nginx这类程序是毫秒级启动。容器分配的CPU数量也会影响启动速度。设置之前需要进行调试。
  • 超时时间（timeoutSeconds）：
    • 通常设置为 1 - 3 秒，使用tcp或者http的方式检查。
  • 成功阈值（successThreshold）和失败阈值（failureThreshold）：
    • 成功阈值一般为 1，一旦启动探针成功，存活探针就会开始正常工作。失败阈值可以根据容器启动的复杂性来设置，一般在 10 - 20 之间。例如，对于一个启动过程很复杂的容器，设置失败阈值为 15，如果启动检查连续 15 次失败，容器可能会被标记为启动失败，具体的处理方式还会受到容器的重启策略等因素的影响。

需要注意的是，这些设置参数的值需要根据具体的应用场景、应用的性能和资源消耗情况等来灵活调整。不同类型的应用（如 Web 应用、数据库应用、消息队列应用等）可能需要不同的探针设置来确保其正确运行。

设置探针的案例

如下是一个java程序的探针设置，简介一下该程序的情况：在2核CPU的情况下，启动时间大概是130秒，核心服务需要开多个实例。
在多实例的情况下，一般会设置滚动更新，如果把启动探针时间设置低于130秒，分配的宿主机比较卡的话，导致启动时间高于130秒，就会继续重启；如果启动探针时间在130以上，到160，那么这时候服务就算已经启动了，那么还得等待一段时间才会进行检查，才会判定他已经就绪，后续批次的pod才会陆续跟着启动，耽误时间。
在这种情况下，合适点的设置方法就是：

• 初始值设置在100秒，他表现优秀的时候有可能100秒启动完，这时候立马进行检查，状态存活，完美。

• 间隔时间为10秒，在100秒还没有启动的话，没隔10秒去检查一次，如果检查到成功，则判定存活。

• 不健康阈值设置为20，20 * 10 = 200，一共进行20次检查，每次10秒，200秒后如果还没起来，则判定启动失败，按照容器重启策略进行后续处理。成功1次就判定为存活，此时存活探针开始工作。也就是最低100秒就可以判定为存活，最久300秒还没启动成功，就让他按照容器重启策略进行后续处理了。这样的方式比较灵活。

    在deployment中，配置在spec.template.spec.containers.下面，跟容器名name同级。
  

  startupProbe:			#启动探针
    failureThreshold: 20	#失败次数阈值，20次后还是没有successThreshold里面次数的成功，就判定为启动失败
    httpGet:			#使用HTTP的检测方式
      path: /test/actuator	#HTTP检测的接口，URL的拼接:容器IP:8080//test/actuator
      port: 8080		#HTTP检测的端口
      scheme: HTTP		#检测方式
    initialDelaySeconds: 100	#初始检查时间：pod运行后多长时间之后才开始进行检查，单位秒
    periodSeconds: 10	#检查的周期，单位秒
    successThreshold: 1	#成功次数阈值
    timeoutSeconds: 3	#超时时间
  livenessProbe:		#存活探针
    failureThreshold: 2	#失败次数阈值，检查到2次失败，就对容器进行重启
    httpGet:			#同启动探针，不重复解释
      path: /test/actuator
      port: 8080
      scheme: HTTP
    initialDelaySeconds: 10	#初始检查时间：启动探针成功多长时间之后才开始进行检查，单位秒
    periodSeconds: 5	#检查的周期，单位秒
    successThreshold: 1	#成功次数阈值：在检查到失败后，再检查到一次成功，就判定容器为存活，如果失败次数是1，那么检查到失败就重启。
    timeoutSeconds: 3	#超时时间
  readinessProbe:		#就绪探针
    failureThreshold: 2	#失败次数阈值，检查到2次失败，就让容器不被调度（不会重启容器）
    httpGet:
      path: /test/actuator
      port: 8080
      scheme: HTTP
    initialDelaySeconds: 10	#初始检查时间：启动探针成功多长时间之后才开始进行检查，单位秒
    periodSeconds: 5	#检查的周期，单位秒
    successThreshold: 1	#成功次数阈值：检查到失败后，再检查到一次成功，就继续让容器被调度
    timeoutSeconds: 3	#超时时间

如果是一个nginx程序的探针，那就容易多了。nginx启动速度快，用不到启动探针，直接舍弃。这时候存活探针和就绪探针的初始化值，就跟启动探针没关系，就是pod启动后的x时间后就开始检查。

  livenessProbe:		#存活探针
    failureThreshold: 2	#失败次数阈值，检查到2次失败，就对容器进行重启
    httpGet:
      path: /web/index.html
      port: 80
      scheme: HTTP
    initialDelaySeconds: 10	#初始检查时间：POD启动多长时间之后才开始进行检查，单位秒
    periodSeconds: 5	#检查的周期，单位秒
    successThreshold: 1	#成功次数阈值：在检查到失败后，再检查到一次成功，就判定容器为存活，如果失败次数是1，那么检查到失败就重启。
    timeoutSeconds: 3	#超时时间
  readinessProbe:		#就绪探针
    failureThreshold: 2	#失败次数阈值，检查到2次失败，就让容器不被调度（不会重启容器）
    httpGet:
      path: /web/index.html
      port: 80
      scheme: HTTP
    initialDelaySeconds: 10	#初始检查时间：POD启动多长时间之后才开始进行检查，单位秒
    periodSeconds: 5	#检查的周期，单位秒
    successThreshold: 1	#成功次数阈值：检查到失败后，再检查到一次成功，就继续让容器被调度
    timeoutSeconds: 3	#超时时间