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

news2024/11/6 7:29:08

文章目录

  • 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.coloradmin.cn/o/1912971.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

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

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

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

RequestContextHolder多线程获取不到request对象

RequestContextHolder多线程获取不到request对象&#xff0c;调用feign接口时&#xff0c;在Feign中的RequestInterceptor也获取不到HttpServletRequest问题解决方案。 1.RequestContextHolder多线程获取不到request对象 异常信息&#xff0c;报错如下&#xff1a; 2024-07-0…
阅读更多...
光学传感器图像处理流程（一）

光学传感器图像处理流程（一）

光学传感器图像处理流程&#xff08;一&#xff09; 1. 处理流程总览2. 详细处理流程2.1. 图像预处理2.1.1. 降噪处理2.1.2. 薄云处理2.1.3. 阴影处理 2.2. 辐射校正2.2.1. 辐射定标2.2.2. 大气校正2.2.3. 地形校正 2.3. 几何校正2.3.1. 图像配准2.3.2. 几何粗校正2.3.3. 几何精…
阅读更多...
深入了解线程锁的使用及锁的本质

深入了解线程锁的使用及锁的本质

文章目录 线程锁的本质局部锁的使用 锁的封装及演示线程饥饿问题 线程加锁本质可重入和线程安全死锁问题 根据前面内容的概述, 上述我们已经知道了在linux下关于线程封装和线程互斥,锁的相关的概念, 下面就来介绍一下关于线程锁的一些其他概念. 线程锁的本质 当这个锁是全局的…
阅读更多...
5.更多

5.更多

发现一个项目与 MkDocs 类似的项目 PyMdown 拓展文档 &#xff0c;等待探索。 1.排版模仿 以下网站使用 MkDocs 构建 Material for MkDocs 的美化 - Charles Les Notebook (charleschile.com) Documentation - Home Assistant (home-assistant.io) Godot Docs – master bra…
阅读更多...
什么是数据同步服务RSYNC？

什么是数据同步服务RSYNC？

大家好呀&#xff01;这里是码农后端。今天来介绍一下数据同步服务RSYNC&#xff0c;作为Linux/Unix系统中远程或本地复制同步&#xff08;复制&#xff09;文件和目录最常用的命令&#xff0c;相比于scp命令&#xff0c;其具有增量备份、数据同步时保持文件的原有属性等优点。…
阅读更多...
[激光原理与应用-102]：南京科耐激光-激光焊接-焊中检测-智能制程监测系统IPM介绍 - 6 - 激光焊接系统的组成

[激光原理与应用-102]：南京科耐激光-激光焊接-焊中检测-智能制程监测系统IPM介绍 - 6 - 激光焊接系统的组成

目录 一、激光焊接系统的组成概述 1.1、核心部件 1.2、焊接执行部件 1.3、辅助系统 1.4、控制系统 1.5、其他辅助设备 二、激光器 2.1 按出光类型分 1. 脉冲激光器 2. 连续激光器 3. 准连续激光器&#xff08;QCW&#xff09; 4. 其他常见激光器 5. 应用领域 2.2…
阅读更多...
CentOS6禁止锁屏

CentOS6禁止锁屏

在电源中设置后还是会锁屏, 原因是有屏幕保护程序 电源管理都 “从不” 一些AI的回答 在CentOS 6系统中&#xff0c;如果你想要禁用锁屏功能&#xff0c;可以编辑/etc/kbd/config文件。这个文件通常包含了键盘相关的设置&#xff0c;包括密码策略和屏幕锁定选项。 首先打开终…
阅读更多...
昇思14天

昇思14天

ResNet50图像分类 1. ResNet50图像分类概述 ResNet50是一种用于图像分类的深度卷积神经网络。图像分类是计算机视觉的基本应用&#xff0c;属于有监督学习范畴。ResNet50通过引入残差结构&#xff0c;解决了深层网络中的退化问题&#xff0c;使得可以训练非常深的网络。 2. …
阅读更多...
List、Map、Set 接口在Java中的存取元素特点

List、Map、Set 接口在Java中的存取元素特点

List、Map、Set 接口在Java中的存取元素特点 1、List 接口2、Map 接口3、Set 接口4、总结 &#x1f496;The Begin&#x1f496;点点关注&#xff0c;收藏不迷路&#x1f496; 在Java中&#xff0c;List、Map和Set是三个最常用的集合接口。它们各自有不同的特点和用途&#xff…
阅读更多...
实践致知第12享：如何新建一个Word并设置格式

实践致知第12享：如何新建一个Word并设置格式

一、背景需求 小姑电话说&#xff1a;要新建一个Word文档&#xff0c;并将每段的首行设置空2格。 二、解决方案 1、在电脑桌面上空白地方&#xff0c;点击鼠标右键&#xff0c;在下拉的功能框中选择“DOC文档”或“DOCX文档”都可以&#xff0c;如下图所示。 之后&#xff0…
阅读更多...
【密码学】分组密码概述

【密码学】分组密码概述

一、分组密码的定义 分组密码和流密码都是对称密码体制。 流密码&#xff1a;是将明文视为连续的比特流&#xff0c;对每个比特或字节进行实时加密&#xff0c;而不将其分割成固定的块。流密码适用于加密实时数据流&#xff0c;如网络通信。分组密码&#xff1a;是将明文数据…
阅读更多...
D2D用户的功率优化算法研究

D2D用户的功率优化算法研究

D2D通信技术是指两个对等的用户节点之间直接进行通信的一种通信方式。在由D2D通信用户组成的分布式网络中&#xff0c;每个用户节点都能发送和接收信号&#xff0c;并具有自动路由(转发消息)的功能。网络的参与者共享它们所拥有的一部分硬件资源&#xff0c;包括信息处理、存储…
阅读更多...
【深度学习】第5章——卷积神经网络（CNN）

【深度学习】第5章——卷积神经网络（CNN）

一、卷积神经网络 1.定义 卷积神经网络&#xff08;Convolutional Neural Network, CNN&#xff09;是一种专门用于处理具有网格状拓扑结构数据的深度学习模型&#xff0c;特别适用于图像和视频处理。CNN 通过局部连接和权重共享机制&#xff0c;有效地减少了参数数量&#x…
阅读更多...
Prometheus 二进制文件与操作系统或架构不兼容

Prometheus 二进制文件与操作系统或架构不兼容

目录 检查架构 下载正确的二进制文件 验证文件类型 权限问题 文件损坏 “可执行文件格式错误”表明你试图执行的二进制文件与操作系统或架构不兼容。 检查架构 确保你下载的二进制文件与系统的架构相匹配&#xff08;例如&#xff0c;x86_64, arm64 等&#xff09;。 可…
阅读更多...
LabVIEW光谱测试系统

LabVIEW光谱测试系统

在现代光通信系统中&#xff0c;光谱分析是不可或缺的工具。开发了一种基于LabVIEW的高分辨率光谱测试系统&#xff0c;通过对可调谐激光器、可编程光滤波器和数据采集系统的控制&#xff0c;实现了高效、高精度的光谱测量。 项目背景 随着光通信技术的迅速发展&#xff0c;对…
阅读更多...
20240710 每日AI必读资讯

20240710 每日AI必读资讯

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

Mysql练习题目【7月10日更新】

七、Mysql练习题目 https://zhuanlan.zhihu.com/p/38354000 1. 创建表 创建学生表 mysql> create table if not exists student(-> student_id varchar(255) not null,-> student_name varchar(255) not null,-> birthday date not null,-> gender varchar(…
阅读更多...
思考：Java内存模型和硬件内存模型

思考：Java内存模型和硬件内存模型

前言 前一阵在看volatile的原理&#xff0c;看到内存屏障和缓存一致性&#xff0c;发现再往底层挖就挖到了硬件和Java内存模型。这一块是自己似懂非懂的知识区&#xff0c;我一般称之为知识混沌区。因此整理这一篇文章。 什么是内存模型&#xff08;Memory Model&#xff09;…
阅读更多...
46、lvs集群- 博客

46、lvs集群- 博客

1、lvs集群&#xff1a; lvs&#xff1a;linux virtual server----章文嵩发起的开源项目&#xff0c;阿里。linux的内核层面实现负载均衡的软件。 主要作用&#xff1a;将多个后端服务器组成一个高可用&#xff0c;高性能的服务器集群&#xff0c;通过负载均衡的算法将客户端的…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023