详细谈谈负载均衡的startupProbe探针、livenessProbe探针、readnessProbe探针如何使用以及使用差异化

文章目录

  • startupProbe探针
    • startupProbe说明
    • 示例配置
      • 参数解释
    • 使用场景说明
    • 实例——要求： 容器在8秒内完成启动，否则杀死对应容器
      • 工作流程说明
      • timeoutSeconds: 和 periodSeconds: 参数顺序说明
  • livenessProbe探针
    • livenessProbe说明
    • 示例配置
      • 参数解释
    • 使用场景说明
    • 实例——题目要求：如果发现业务4秒后无响应，杀死对应容器，并进行重启
      • 工作流程说明
  • readnessProbe探针
    • readnessProbe说明
    • 示例配置
      • 参数解释
    • 使用场景说明
    • 实例——如果发现业务3秒后无响应，访问流量将不会传值该容器，5秒内如果回复响应，访问流量将继续转发至该容器
      • 工作流程说明
  • 一个完整的包含3个探针的实例yaml文件

startupProbe探针

  • startupProbe 是 Kubernetes 中的一种探针，用于检测容器的启动状态。
    • 如果容器未能在指定的时间内启动，Kubernetes 将杀死并重启该容器。【简单来说startupProbe 用于检测容器是否已经成功启动。如果 startupProbe 失败，Kubernetes 将杀死容器并根据策略进行重启。】
    • startupProbe 主要用于那些启动时间较长的应用，以确保它们在完全启动之前不会被其他探针（如 livenessProbe 和 readinessProbe）误判为失败。也就是说，它通常用于那些启动时间较长的应用程序，以确保在应用程序完全启动之前不会触发 livenessProbe 和 readinessProbe。

startupProbe说明

  • 以下是 startupProbe 的常用参数及其说明：

    1. httpGet: 使用 HTTP GET 请求进行探测。
      • path: 要探测的 HTTP 路径。
      • port: 要探测的端口。
      • scheme: 使用的协议（HTTP 或 HTTPS）。

    示例：

    httpGet:
  path: /
  port: 8080
  scheme: HTTP
    1. tcpSocket: 使用 TCP 检查进行探测。
      • port: 要探测的端口。

    示例：

    tcpSocket:
  port: 8080
    1. exec: 使用命令执行进行探测。
      • command: 要执行的命令及其参数。

    示例：

    exec:
  command:
    - cat
    - /etc/hosts
    1. initialDelaySeconds: 在容器启动后等待多长时间开始进行第一次检查。
      • 类型：整数
      • 默认值：0
    1. timeoutSeconds: 探针等待响应的时间。如果超过这个时间没有响应，则认为探针失败。
      • 类型：整数
      • 默认值：1
    1. periodSeconds: 探针之间的间隔时间，即每隔多少秒进行一次检查。
    • 类型：整数
    • 默认值：10
    1. successThreshold: 探针连续成功的次数，只有达到这个次数才认为探针成功。
    • 类型：整数
    • 默认值：1
    1. failureThreshold: 探针连续失败的次数，只有达到这个次数才认为探针失败，并触发容器重启。
    • 类型：整数
    • 默认值：3

示例配置

  • 以下是一个完整的 startupProbe 配置示例：
startupProbe:
  httpGet:
    path: /
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 0
  timeoutSeconds: 5
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3

参数解释

  • httpGet: 使用 HTTP GET 请求检查 / 路径，端口为 8080，使用 HTTP 协议。
  • initialDelaySeconds: 0: 容器启动后立即开始进行探测。
  • timeoutSeconds: 5: 探针等待5秒以获取响应。如果超过5秒没有响应，则认为探针失败。
  • periodSeconds: 10: 每10秒进行一次探测。
  • successThreshold: 1: 探针只需一次成功就认为探测通过。
  • failureThreshold: 3: 探针需要连续三次失败才认为探测失败，并触发容器重启。

使用场景说明

  • 使用场景一般有下面2个：

    • 启动时间较长的应用：对于启动时间较长的应用，使用 startupProbe 可以确保它们在完全启动之前不会被误判为失败。
    • 避免误判：在应用启动过程中，livenessProbe 和 readinessProbe 可能会误判应用为失败。使用 startupProbe 可以避免这种情况。

  • 通过合理配置 startupProbe，可以确保容器在启动过程中得到正确的检测和处理，避免因启动时间较长而导致的不必要的重启。

实例——要求： 容器在8秒内完成启动，否则杀死对应容器

  • 根据题意，最终参数如下：
    这种配置确保了探针能够每2秒检查一次容器状态，并且在容器未能在8秒内启动完成时杀死容器。探针等待4秒以获取响应，如果超过4秒没有响应，则认为探针失败。探针需要连续两次失败（即8秒内两次失败）才会将容器标记为启动失败并触发重启。
startupProbe:
  exec:
    command:
      - cat
      - /etc/hosts
  initialDelaySeconds: 0
  timeoutSeconds: 4
  periodSeconds: 2
  successThreshold: 1
  failureThreshold: 2

工作流程说明

  • 解析
startupProbe 【只启动一次】——容器启动的时候完成探针，失败就kill
	exec: 通过在容器内执行命令来检查应用的健康状况。
	  command: 要执行的命令。
	    - cat
	    - /etc/hosts
	`initialDelaySeconds 0` 用于指定在容器启动后多长时间开始进行首次健康检查。
		它的作用是让容器有足够的时间来完成初始化操作，避免在容器还未完全启动时就进行健康检查，从而导致误判。
		例如，如果将 `initialDelaySeconds` 设置为 `30`，那么 Kubernetes 会在容器启动后的 30 秒才开始进行第一次 `startupProbe` 检查。
	`timeoutSeconds 4`: 探测的超时时间（秒）。
	`periodSeconds 2`: 执行探测的周期（秒）。
	`successThreshold 1`: 探测成功的阈值。连续成功达到这个阈值后，容器被认为已经成功启动。默认值是 1。如果设置为 1，只要有一次成功的探测，容器就会被认为启动成功。
	`failureThreshold 2`: 探测失败的阈值。在达到这个阈值之前，容器不会被认为启动失败。

  • 参数解释

    • exec: 使用命令执行方式进行探测，这里使用 ls /mnt 命令。

      • command: 定义了要执行的命令，这里是 ls /mnt。

    • initialDelaySeconds: 在容器启动后等待多长时间开始进行第一次检查。

      • 在你的配置中，initialDelaySeconds: 0 表示容器启动后立即开始进行探测。

    • timeoutSeconds: 探针等待响应的时间。如果超过这个时间没有响应，则认为探针失败。

      • 在你的配置中，timeoutSeconds: 4 表示探针等待4秒以获取响应。如果超过4秒没有响应，则认为探针失败。

    • periodSeconds: 探针之间的间隔时间，即每隔多少秒进行一次检查。

      • 在你的配置中，periodSeconds: 2 表示每2秒进行一次探测。

    • successThreshold: 探针连续成功的次数，只有达到这个次数才认为探针成功。

      • 在你的配置中，successThreshold: 1 表示探针只需一次成功就认为探测通过。

    • failureThreshold: 探针连续失败的次数，只有达到这个次数才认为探针失败，并触发容器重启。

      • 在你的配置中，failureThreshold: 2 表示探针需要连续两次失败才认为探测失败。

  • 工作流程

      1. 容器启动后，探针会立即开始进行探测（initialDelaySeconds: 0）。
      1. 每2秒，探针会执行一次 ls /mnt 命令（periodSeconds: 2）。
      1. 如果探针在4秒内没有成功执行 ls /mnt 命令（timeoutSeconds: 4），则认为探针失败。
      1. 探针需要连续两次失败（failureThreshold: 2）才会触发容器重启。

  • 适用场景

    • initialDelaySeconds: 0：适用于希望容器启动后立即开始探测的场景。
    • timeoutSeconds: 4：适用于希望容器在执行命令时有足够的时间响应。
    • periodSeconds: 2：适用于希望频繁检查容器启动状态的情况。
    • successThreshold: 1：适用于希望探针只需一次成功就认为容器启动成功的情况。
    • failureThreshold: 2：适用于希望探针需要连续两次失败才认为容器启动失败的情况，避免偶发性故障导致不必要的重启。

  • 结论
    这个配置是合适的，因为它能够满足以下需求：
    8秒内完成启动：探针每2秒检查一次容器状态，探针等待4秒以获取响应。如果超过4秒没有响应，则认为探针失败。探针需要连续两次失败（即8秒内两次失败）才会将容器标记为启动失败并触发重启。

  • 口水话深度解析

    • 容器启动后，探针会立即开始进行探测。
    • 开始第一个循环，循环内容持续时间是4秒，循环内容为：探针每4秒（periodSeconds: 4）执行一次 ls /mnt 命令。持续时间为2秒（timeoutSeconds: 2）【时间是包含关系【（periodSeconds: 4）包含（timeoutSeconds: 2）】，而不能（periodSeconds: 4）x（timeoutSeconds: 2）=8秒】
      • 【换种方式来说就是，4秒执行一次，持续时间4秒（periodSeconds: 4），4秒中做的事情是，2秒内（timeoutSeconds: 2）有没有成功执行 ls /mnt命令】
    • 如果探针在2秒（timeoutSeconds: 2）内没有成功执行 ls /mnt 命令，则认为探针失败。然后开始下一个循环（failureThreshold: 2），一组循环的参数是（periodSeconds: 4）和（timeoutSeconds: 2）。
    • 探针需要连续两次失败（即8秒内两次失败）才会触发容器重启。【时间计算是（periodSeconds: 4）x（failureThreshold: 2）】
    • 而所谓的“否则杀死对应容器”，就是表示容器不运行而已

timeoutSeconds: 和 periodSeconds: 参数顺序说明

  • 容器在8秒内完成启动，否则杀死对应容器，下面2个参数哪个更合适？
startupProbe:
  exec:
    command:
      - ls
      - /mnt
  initialDelaySeconds: 0
  timeoutSeconds: 2
  periodSeconds: 4
  successThreshold: 1
  failureThreshold: 2
  
#和

startupProbe:
  exec:
    command:
      - ls
      - /mnt
  initialDelaySeconds: 0
  timeoutSeconds: 4
  periodSeconds: 2
  successThreshold: 1
  failureThreshold: 2

根据你的需求：容器在8秒内完成启动，否则杀死对应容器。

  • 区别

      1. timeoutSeconds:
      • 配置1: timeoutSeconds: 2，探针等待2秒以获取响应。如果超过2秒没有响应，则认为探针失败。
      • 配置2: timeoutSeconds: 4，探针等待4秒以获取响应。如果超过4秒没有响应，则认为探针失败。
      1. periodSeconds:
      • 配置1: periodSeconds: 4，每4秒进行一次探测。

    • 配置2: periodSeconds: 2，每2秒进行一次探测。

  • 需求分析

    • 8秒内完成启动：需要探针在8秒内检测到容器是否启动完成，否则杀死容器。

  • 配置选择

    • 配置1

      • 探针每4秒检查一次容器状态。
      • 探针等待2秒以获取响应。
      • 探针需要连续两次失败（即8秒内两次失败）才会将容器标记为启动失败并杀死容器。

    • 配置2

      • 探针每2秒检查一次容器状态。
      • 探针等待4秒以获取响应。
      • 探针需要连续两次失败（即8秒内两次失败）才会将容器标记为启动失败并杀死容器。

  • 结论

    • 配置2 更合适，因为它能够更频繁地检查容器状态，并且在8秒内检测到容器是否启动完成。
    • 这种配置确保了探针能够每2秒检查一次容器状态，并且在容器未能在8秒内启动完成时杀死容器。探针等待4秒以获取响应，如果超过4秒没有响应，则认为探针失败。探针需要连续两次失败（即8秒内两次失败）才会将容器标记为启动失败并杀死容器。
startupProbe:
  exec:
    command:
      - ls
      - /mnt
  initialDelaySeconds: 0
  timeoutSeconds: 4
  periodSeconds: 2
  successThreshold: 1
  failureThreshold: 2

livenessProbe探针

livenessProbe说明

  • livenessProbe 是 Kubernetes 中的一种探针，用于检测容器是否处于健康状态。

    • 如果探针失败，Kubernetes 会杀死容器并根据策略进行重启。
    • livenessProbe 主要用于确保容器在运行过程中保持健康状态，如果容器进入不健康状态，可以通过重启来恢复。
    • 通过合理配置 livenessProbe，可以确保容器在运行过程中保持健康状态，并在出现问题时自动重启容器，从而提高应用的可靠性和可用性。

  • 以下是 livenessProbe 的常用参数及其说明：

    • httpGet: 使用 HTTP GET 请求进行探测。
    • path: 要探测的 HTTP 路径。
    • port: 要探测的端口。
    • scheme: 使用的协议（HTTP 或 HTTPS）。

    示例：

    httpGet:
  path: /
  port: 8080
  scheme: HTTP
    1. tcpSocket: 使用 TCP 检查进行探测。
    • port: 要探测的端口。

    示例：

    tcpSocket:
  port: 8080
    1. exec: 使用命令执行进行探测。
    • command: 要执行的命令及其参数。

    示例：

    exec:
  command:
    - cat
    - /etc/hosts
    1. initialDelaySeconds: 在容器启动后等待多长时间开始进行第一次检查。
    • 类型：整数
    • 默认值：0
    1. timeoutSeconds: 探针等待响应的时间。如果超过这个时间没有响应，则认为探针失败。
    • 类型：整数
    • 默认值：1
    1. periodSeconds: 探针之间的间隔时间，即每隔多少秒进行一次检查。
    • 类型：整数
    • 默认值：10
    1. successThreshold: 探针连续成功的次数，只有达到这个次数才认为探针成功。
    • 类型：整数
    • 默认值：1
    1. failureThreshold: 探针连续失败的次数，只有达到这个次数才认为探针失败，并触发容器重启。
    • 类型：整数
    • 默认值：3

示例配置

  • 以下是一个完整的 livenessProbe 配置示例：
livenessProbe:
  httpGet:
    path: /
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 10
  timeoutSeconds: 1
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3

参数解释

  • httpGet: 使用 HTTP GET 请求检查 / 路径，端口为 8080，使用 HTTP 协议。
  • initialDelaySeconds: 10: 容器启动后等待10秒再开始进行探测。
  • timeoutSeconds: 1: 探针等待1秒以获取响应。如果超过1秒没有响应，则认为探针失败。
  • periodSeconds: 10: 每10秒进行一次探测。
  • successThreshold: 1: 探针只需一次成功就认为探测通过。
  • failureThreshold: 3: 探针需要连续三次失败才认为探测失败，并触发容器重启。

使用场景说明

  • 使用场景如下
    • 检测应用崩溃：如果应用进程崩溃或挂起，livenessProbe 可以检测到并触发容器重启。
    • 检测死锁：如果应用进入死锁状态，livenessProbe 可以检测到并触发容器重启。
    • 检测资源耗尽：如果应用耗尽了资源（如内存、CPU），livenessProbe 可以检测到并触发容器重启。

实例——题目要求：如果发现业务4秒后无响应，杀死对应容器，并进行重启

  • 题目要求：如果发现业务4秒后无响应，杀死对应容器，并进行重启
  • 最终如下
    这种配置确保了探针能够每秒检查一次服务状态，并且在服务无响应时更准确地将容器标记为不健康。探针等待2秒以获取响应，如果超过2秒没有响应，则认为探针失败。探针需要连续两次失败才会触发容器重启，同时在服务恢复响应时能够快速将容器标记为健康。
livenessProbe:
  httpGet:
    path: /
    port: 8090
    scheme: HTTP
  initialDelaySeconds: 10
  timeoutSeconds: 2
  periodSeconds: 1
  successThreshold: 1
  failureThreshold: 2

工作流程说明

liveness【整个生命周期存在】——检测状态，失败就kill
	#用于检测容器是否处于健康状态。如果探针失败，Kubernetes 会杀死容器并根据策略进行重启。
    #适用于检测容器是否需要重启的情况。
	tcpSocket:  过尝试建立 TCP 连接来检查应用的健康状况。
	  port: 8090  要连接的端口。
	`initialDelaySeconds 10` 用于指定在容器启动后多长时间开始进行首次健康检查。
		它的作用是让容器有足够的时间来完成初始化操作，避免在容器还未完全启动时就进行健康检查，从而导致误判。
		例如，如果将 `initialDelaySeconds` 设置为 `30`，那么 Kubernetes 会在容器启动后的 30 秒才开始进行第一次 `startupProbe` 检查。
	`timeoutSeconds 2`: 探测的超时时间（秒）。默认值是 1 秒。
	`periodSeconds 1`: 执行探测的周期（秒）。默认值是 10 秒。
	`successThreshold 1`: 探测成功的阈值。连续成功达到这个阈值后，容器被认为已经成功启动。默认值是 1。如果设置为 1，只要有一次成功的探测，容器就会被认为启动成功。
	`failureThreshold 2`: 探测失败的阈值。在达到这个阈值之前，容器不会被认为启动失败。默认值是 3。

  • 参数解释

    • httpGet: 使用 HTTP GET 请求进行探测。

    • path: /，这是探针将要检查的路径。

    • port: 8090，这是探针将要检查的端口。

    • scheme: HTTP，使用 HTTP 协议进行探测。

    • initialDelaySeconds: 在容器启动后等待多长时间开始进行第一次检查。

      • 在你的配置中，initialDelaySeconds: 10 表示容器启动后等待10秒再开始进行探测。

    • timeoutSeconds: 探针等待响应的时间。如果超过这个时间没有响应，则认为探针失败。

      • 在你的配置中，timeoutSeconds: 2 表示探针等待2秒以获取响应。如果超过2秒没有响应，则认为探针失败。

    • periodSeconds: 探针之间的间隔时间，即每隔多少秒进行一次检查。

      • 在你的配置中，periodSeconds: 1 表示每1秒进行一次探测。

    • successThreshold: 探针连续成功的次数，只有达到这个次数才认为探针成功。

      • 在你的配置中，successThreshold: 1 表示探针只需一次成功就认为探测通过。

    • failureThreshold: 探针连续失败的次数，只有达到这个次数才认为探针失败，并触发容器重启。

      • 在你的配置中，failureThreshold: 2 表示探针需要连续两次失败才认为探测失败。

  • 工作流程

      1. 容器启动后，探针会等待10秒再开始进行探测（initialDelaySeconds: 10）。
      1. 每1秒，探针会对 http://<容器IP>:8090/ 发起一次 HTTP GET 请求（periodSeconds: 1）。
      1. 如果探针在2秒内没有收到响应（timeoutSeconds: 2），则认为探针失败。
      1. 探针需要连续两次失败（failureThreshold: 2）才会触发容器重启。
      1. 探针只需一次成功（successThreshold: 1）就会将容器标记为健康。

  • 适用场景

    • initialDelaySeconds: 10：适用于希望容器启动后等待一段时间再开始探测的场景。
    • timeoutSeconds: 2：适用于希望快速检测到服务无响应的情况。
    • periodSeconds: 1：适用于希望频繁检查服务健康状态的情况。
    • successThreshold: 1：适用于希望探针只需一次成功就认为服务健康的情况。
    • failureThreshold: 2：适用于希望探针需要连续两次失败才认为服务不健康的情况，避免偶发性故障导致不必要的重启。

  • 满足需求

    • 10秒后开始探测：容器启动后等待10秒再开始进行探测。
    • 2秒无响应：探针等待2秒以获取响应，如果超过2秒没有响应，则认为探针失败。
    • 每1秒检查一次：探针每1秒检查一次服务状态。
    • 连续两次失败：探针需要连续两次失败才会触发容器重启。

readnessProbe探针

readnessProbe说明

  • readinessProbe 是 Kubernetes 中的一种探针，用于检测容器是否已经准备好接受流量。

    • 如果探针失败，Kubernetes 会将容器从服务的端点列表中移除，但不会杀死容器。
    • 这主要用于确保只有健康且准备好处理请求的容器才会接收流量。
    • 通过合理配置 readinessProbe，可以确保只有健康且准备好处理请求的容器才会接收流量，从而提高应用的可靠性和可用性。

  • readinessProbe 参数说明
    以下是 readinessProbe 的常用参数及其说明：

    1. httpGet: 使用 HTTP GET 请求进行探测。
    • path: 要探测的 HTTP 路径。
    • port: 要探测的端口。
    • scheme: 使用的协议（HTTP 或 HTTPS）。

    示例：

    httpGet:
  path: /
  port: 8080
  scheme: HTTP
    1. tcpSocket: 使用 TCP 检查进行探测。
    • port: 要探测的端口。

    示例：

    tcpSocket:
  port: 8080
    1. exec: 使用命令执行进行探测。
    • command: 要执行的命令及其参数。

    示例：

    exec:
  command:
    - cat
    - /etc/hosts
    1. initialDelaySeconds: 在容器启动后等待多长时间开始进行第一次检查。
    • 类型：整数
    • 默认值：0
    1. timeoutSeconds: 探针等待响应的时间。如果超过这个时间没有响应，则认为探针失败。
    • 类型：整数
    • 默认值：1
    1. periodSeconds: 探针之间的间隔时间，即每隔多少秒进行一次检查。
    • 类型：整数
    • 默认值：10
    1. successThreshold: 探针连续成功的次数，只有达到这个次数才认为探针成功。
    • 类型：整数
    • 默认值：1
    1. failureThreshold: 探针连续失败的次数，只有达到这个次数才认为探针失败，并将容器标记为不就绪。
    • 类型：整数
    • 默认值：3

示例配置

以下是一个完整的 readinessProbe 配置示例：

readinessProbe:
  httpGet:
    path: /
    port: 8080
    scheme: HTTP
  initialDelaySeconds: 10
  timeoutSeconds: 1
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3

参数解释

  • httpGet: 使用 HTTP GET 请求检查 / 路径，端口为 8080，使用 HTTP 协议。
  • initialDelaySeconds: 10: 容器启动后等待10秒再开始进行探测。
  • timeoutSeconds: 1: 探针等待1秒以获取响应。如果超过1秒没有响应，则认为探针失败。
  • periodSeconds: 10: 每10秒进行一次探测。
  • successThreshold: 1: 探针只需一次成功就认为探测通过。
  • failureThreshold: 3: 探针需要连续三次失败才认为探测失败，并将容器标记为不就绪。

使用场景说明

  • 检测应用是否准备好接受流量：在应用启动过程中，可能需要进行一些初始化操作（如加载配置、连接数据库等），readinessProbe 可以确保应用在完成这些操作后才开始接收流量。
  • 动态调整服务流量：在运行过程中，如果应用暂时无法处理请求（如进行内部维护或资源不足），readinessProbe 可以将容器从服务的端点列表中移除，待应用恢复后再重新加入。

实例——如果发现业务3秒后无响应，访问流量将不会传值该容器，5秒内如果回复响应，访问流量将继续转发至该容器

  • 题目要求：如果发现业务3秒后无响应，访问流量将不会传值该容器，5秒内如果回复响应，访问流量将继续转发至该容器
  • 最终用下面参数
    这种配置确保了探针能够每秒检查一次服务状态，并且在服务无响应时更准确地将容器标记为不就绪。探针等待3秒以获取响应，如果超过3秒没有响应，则认为探针失败。探针只需一次失败就会将容器标记为不就绪，同时在服务恢复响应时能够在5秒内检测到并将容器标记为就绪。
readinessProbe:
  httpGet:
    path: /
    port: 8090
    scheme: HTTP
  initialDelaySeconds: 10
  timeoutSeconds: 3
  periodSeconds: 1
  successThreshold: 1
  failureThreshold: 1

工作流程说明

readness【整个生命周期存在】——检测业务，失败就不转发业务【不会kill掉容器】
	#用于检测容器是否准备好接受流量。如果探针失败，Kubernetes 会将容器从服务的端点列表中移除，但不会杀死容器。
	#适用于检测容器是否可以接受流量的情况。
	httpGet: 通过发送 HTTP GET 请求来检查应用的健康状况。
	  path: / 要访问的 HTTP 路径。
	  port: 8090 要访问的端口。
	  scheme: HTTP 指定 HTTP 请求的协议，常见的值为 HTTP 和 HTTPS。
	`initialDelaySeconds 10` 用于指定在容器启动后多长时间开始进行首次健康检查。
		它的作用是让容器有足够的时间来完成初始化操作，避免在容器还未完全启动时就进行健康检查，从而导致误判。
		例如，如果将 `initialDelaySeconds` 设置为 `30`，那么 Kubernetes 会在容器启动后的 30 秒才开始进行第一次 `startupProbe` 检查。
	`timeoutSeconds 3`: 探测的超时时间（秒）。默认值是 1 秒。
	`periodSeconds 1`: 执行探测的周期（秒）。默认值是 10 秒。
	`successThreshold 1`: 探测成功的阈值。连续成功达到这个阈值后，容器被认为已经成功启动。默认值是 1。如果设置为 1，只要有一次成功的探测，容器就会被认为启动成功。
	`failureThreshold 1`: 探测失败的阈值。在达到这个阈值之前，容器不会被认为启动失败。默认值是 3。

  • 参数解释

    • httpGet: 使用 HTTP GET 请求进行探测。

      • path: /，这是探针将要检查的路径。
      • port: 8090，这是探针将要检查的端口。
      • scheme: HTTP，使用 HTTP 协议进行探测。

    • initialDelaySeconds: 在容器启动后等待多长时间开始进行第一次检查。

      • 在你的配置中，initialDelaySeconds: 10 表示容器启动后等待10秒再开始进行探测。

    • timeoutSeconds: 探针等待响应的时间。如果超过这个时间没有响应，则认为探针失败。

      • 在你的配置中，timeoutSeconds: 3 表示探针等待3秒以获取响应。如果超过3秒没有响应，则认为探针失败。

    • periodSeconds: 探针之间的间隔时间，即每隔多少秒进行一次检查。

      • 在你的配置中，periodSeconds: 1 表示每1秒进行一次探测。

    • successThreshold: 探针连续成功的次数，只有达到这个次数才认为探针成功。

      • 在你的配置中，successThreshold: 1 表示探针只需一次成功就认为探测通过。

    • failureThreshold: 探针连续失败的次数，只有达到这个次数才认为探针失败，并将容器标记为不就绪。

      • 在你的配置中，failureThreshold: 1 表示探针只需一次失败就认为探测失败。

  • 工作流程

      1. 容器启动后，探针会等待10秒再开始进行探测（initialDelaySeconds: 10）。
      1. 每1秒，探针会对 http://<容器IP>:8090/ 发起一次 HTTP GET 请求（periodSeconds: 1）。
      1. 如果探针在3秒内没有收到响应（timeoutSeconds: 3），则认为探针失败。
      1. 探针只需一次失败（failureThreshold: 1）就会将容器标记为不就绪。
      1. 探针只需一次成功（successThreshold: 1）就会将容器标记为就绪。

  • 适用场景

    • initialDelaySeconds: 10：适用于希望容器启动后等待一段时间再开始探测的场景。
    • timeoutSeconds: 3：适用于希望快速检测到服务无响应的情况。
    • periodSeconds: 1：适用于希望频繁检查服务健康状态的情况。
    • successThreshold: 1：适用于希望探针只需一次成功就认为服务就绪的情况。
    • failureThreshold: 1：适用于希望探针只需一次失败就认为服务不就绪的情况，能够快速响应服务的异常状态。

  • 满足需求

    • 10秒后开始探测：容器启动后等待10秒再开始进行探测。
    • 3秒无响应：探针等待3秒以获取响应，如果超过3秒没有响应，则认为探针失败。
    • 每1秒检查一次：探针每1秒检查一次服务状态。
    • 一次失败即标记为不就绪：探针只需一次失败就会将容器标记为不就绪。
    • 一次成功即标记为就绪：探针只需一次成功就会将容器标记为就绪。

一个完整的包含3个探针的实例yaml文件

可以直接通过下面内容创建一个负载的
在这里插入图片描述

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mfbz.cn/a/788351.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

生产者消费者模型和线程同步问题

生产者消费者模型和线程同步问题

文章目录 线程同步概念生产者消费者模型条件变量使用条件变量唤醒条件变量 阻塞队列 线程同步概念 互斥能保证安全,但是仅有安全不够,同步可以更高效的使用资源 生产者消费者模型 下面就基于生产者消费者来深入线程同步等概念: 如何理解生产消费者模型: 以函数调用为例: 两…
阅读更多...
LNMP搭建Discuz和Wordpress

LNMP搭建Discuz和Wordpress

1、LNMP L:linux操作系统 N&#xff1a;nginx展示前端页面web服务 M&#xff1a;mysql数据库&#xff0c;保存用户和密码&#xff0c;以及论坛相关的内容 P&#xff1a;php动态请求转发的中间件 数据库的作用&#xff1a; 登录时验证用户名和密码 创建用户和密码 发布和…
阅读更多...
存储产品选型策略 OSS生命周期管理与运维

存储产品选型策略 OSS生命周期管理与运维

最近在看阿里云的 云存储通关实践认证训练营这个课程还是不错的。 存储产品选型策略、对象存储OSS入门、基于对象存储OSS快速搭建网盘、 如何做好权限控制、如何做好数据安全、如何做好数据管理、涉及对象存储OSS的权限控制、使用OSS完成静态网站托管、对OSS中存储的数据进行分…
阅读更多...
ubuntu使用kubeadm搭建k8s集群

ubuntu使用kubeadm搭建k8s集群

一、卸载k8s kubeadm reset -f modprobe -r ipip lsmod rm -rf ~/.kube/ rm -rf /etc/kubernetes/ rm -rf /etc/systemd/system/kubelet.service.d rm -rf /etc/systemd/system/kubelet.service rm -rf /usr/bin/kube* rm -rf /etc/cni rm -rf /opt/cni rm -rf /var/lib/etcd …
阅读更多...
压缩感知2——算法模型

压缩感知2——算法模型

采集原理 其中Y就是压缩后的信号表示(M维)&#xff0c;Φ表示采集的测量矩阵&#xff0c;可以是一个随机矩阵&#xff0c;X代表原始的数字信号&#xff08;N维&#xff09;。 常见的测量矩阵——随机高斯矩阵 随机伯努利矩阵 稀疏随机矩阵等&#xff0c;矩阵需要满足与信号的稀…
阅读更多...
57、基于概率神经网络(PNN)的分类(matlab)

57、基于概率神经网络(PNN)的分类(matlab)

1、基于概率神经网络(PNN)的分类简介 PNN&#xff08;Probabilistic Neural Network&#xff0c;概率神经网络&#xff09;是一种基于概率论的神经网络模型&#xff0c;主要用于解决分类问题。PNN最早由马科夫斯基和马西金在1993年提出&#xff0c;是一种非常有效的分类算法。…
阅读更多...
OpenCV MEI相机模型（全向模型）

OpenCV MEI相机模型（全向模型）

文章目录 一、简介二、实现代码三、实现效果参考文献一、简介 对于针孔相机模型，由于硬件上的限制（如进光量等），他的视野夹角往往有效区域只有140度左右，因此就有研究人员为每个针孔相机前面再添加一个镜片，如下所示： 通过折射的方式增加了相机成像的视野，虽然仍然达不…
阅读更多...
精讲：java之多维数组的使用

精讲：java之多维数组的使用

一、多维数组简介 1.为什么需要二维数组 我们看下面这个例子&#xff1f;“ 某公司2022年全年各个月份的销售额进行登记。按月份存储&#xff0c;可以使用一维数组。如果改写为按季度为单位存储怎么办呢&#xff1f; 或许现在学习了一维数组的你只能申请四个一维数组去存储每…
阅读更多...
修改服务器挂载目录

修改服务器挂载目录

由于我们的项目通常需要挂载一个大容量的数据盘来存储文件数据&#xff0c;所以我们每台服务器都需要一个默认的挂载目录来存放这些数据&#xff0c;但是由于我们的误操作&#xff0c;导致挂载目录名字建错了&#xff0c;这时候后端就读不到挂载目录了&#xff0c;那我们我们的…
阅读更多...
公司内部配置GitLab，通过SSH密钥来实现免密clone、push等操作

公司内部配置GitLab，通过SSH密钥来实现免密clone、push等操作

公司内部配置GitLab&#xff0c;通过SSH密钥来实现免密clone、push等操作。以下是配置SSH密钥以实现免密更新的步骤&#xff1a; 1.生成SSH密钥 在本地计算机上打开终端或命令提示符。输入以下命令以生成一个新的SSH密钥&#xff1a;ssh-keygen -t rsa -b 4096 -C "your…
阅读更多...
AGE Cypher 查询格式

AGE Cypher 查询格式

使用 ag_catalog 中的名为 cypher 的函数构建 Cypher 查询&#xff0c;该函数返回 Postgres 的记录集合。 Cypher() Cypher() 函数执行作为参数传递的 Cypher 查询。 语法&#xff1a;cypher(graph_name, query_string, parameters) 返回&#xff1a; A SETOF records 参…
阅读更多...
高铁站客运枢纽IPTV电视系统-盐城高铁站西广场IP电视系统应用浅析

高铁站客运枢纽IPTV电视系统-盐城高铁站西广场IP电视系统应用浅析

高铁站客运枢纽IPTV电视系统-盐城高铁站西广场IP电视系统应用浅析 由北京海特伟业科技有限公司任洪卓于2024年7月9日发布 随着科技的飞速发展&#xff0c;特别是“互联网”战略的深入推进&#xff0c;高铁站客运枢纽的信息化建设成为提升服务质量、增强乘客体验的重要手段。盐…
阅读更多...
FTP与TFTP

FTP与TFTP

1、TFTP&#xff08;简单文件传输协议&#xff09; TFTP是TCP/IP协议族中一个用来在客户机与服务器之间进行简单文件传输的协议&#xff0c;提供不复杂、开销不大的文件传输服务。 基于UDP协议 端口号&#xff1a;69 特点&#xff1a;简单、轻量级、易于实现 传输过程&…
阅读更多...
20240710 每日AI必读资讯

20240710 每日AI必读资讯

&#x1f916;微软&#xff1a;不会像 OpenAI 一样阻止中国访问 AI 模型 - OpenAI 将于周二&#xff08;7 月 9 日&#xff09;开始阻止中国用户访问其 API。 - 微软发言人表示&#xff1a;Azure OpenAI API服务在中国的提供方式没有变化。 - 公司仍然通过部署在中国以外地区…
阅读更多...
uniapp——银行卡号脱敏

uniapp——银行卡号脱敏

样式 代码 {{bankNumber.replace(/(\d{4})(?\d)/g, "●●●● ").replace(/(\d{2})(?\d{2}$)/, " $1")}} 将银行卡号按照每四位一组的方式进行处理&#xff0c;前面的变成 剩下的正常显示
阅读更多...
谷粒商城-个人笔记(集群部署篇三)

谷粒商城-个人笔记(集群部署篇三)

前言 ​学习视频&#xff1a;​Java项目《谷粒商城》架构师级Java项目实战&#xff0c;对标阿里P6-P7&#xff0c;全网最强​学习文档&#xff1a; 谷粒商城-个人笔记(基础篇一)谷粒商城-个人笔记(基础篇二)谷粒商城-个人笔记(基础篇三)谷粒商城-个人笔记(高级篇一)谷粒商城-个…
阅读更多...
昇思MindSpore25天学习打卡Day17：K近邻算法实现红酒聚类

昇思MindSpore25天学习打卡Day17：K近邻算法实现红酒聚类

昇思MindSpore25天学习打卡Day17&#xff1a;K近邻算法实现红酒聚类 1 实验目地2 K近邻算法(KNN)原理介绍2.1 分类问题2.2 回归问题2.3 距离的定义 3 实验环境4 数据处理4.1 数据准备4.2 数据读取与处理4.2.1 导入MindSpore模块和辅助模块 5 模型构建--计算距离6 模型预测 及 打…
阅读更多...
java算法day9

java算法day9

232.用栈实现队列 用队列实现栈 有效的括号 删除字符串中的所有相邻重复项 逆波兰表达式求值 解决栈和队列的基本数据结构 Queue&#xff08;队列&#xff09; 在java中是一个接口。定义的方法&#xff1a; //boolean add(E e): 将指定的元素插入此队列&#xff08;如果…
阅读更多...
软考高级里《系统架构设计师》容易考吗？

软考高级里《系统架构设计师》容易考吗？

我还是22年通过的架构考试。系统架构设计师属于软考高级科目&#xff0c;难度比初级和中级都要大&#xff0c;往年的通过率也比较低&#xff0c;一般在10-20%左右。从总体来说&#xff0c;这门科目确实是不好过的&#xff0c;大家如果想要备考系统架构设计师的话&#xff0c;还…
阅读更多...
【界面态】霍尔效应表征氮化对SiC/SiO2界面陷阱的影响

【界面态】霍尔效应表征氮化对SiC/SiO2界面陷阱的影响

引言 引言主要介绍了硅碳化物&#xff08;SiC&#xff09;金属-氧化物-半导体场效应晶体管&#xff08;MOSFETs&#xff09;作为新一代高压、低损耗功率器件的商业化背景。SiC MOSFETs因其优越的电气特性&#xff0c;在高电压和高温应用领域具有巨大的潜力。然而&#xff0c;尽…
阅读更多...
最新文章

Copyright @ 2022~2023