【云原生】恰当运用kubernetes中三种探针，确保应用程序在Kubernetes集群中保持健康、可用和可靠

✨✨ 欢迎大家来到景天科技苑✨✨

🎈🎈 养成好习惯，先赞后看哦~🎈🎈

🏆 作者简介：景天科技苑
🏆《头衔》：大厂架构师，华为云开发者社区专家博主，阿里云开发者社区专家博主，CSDN全栈领域优质创作者，掘金优秀博主，51CTO博客专家等。
🏆《博客》：Python全栈，前后端开发，小程序开发，人工智能，js逆向，App逆向，网络系统安全，数据分析，Django，fastapi，flask等框架，云原生k8s，linux，shell脚本等实操经验，网站搭建，数据库等分享。

所属的专栏：云原生K8S，零基础到进阶实战
景天的主页：景天科技苑

Kubernetes中三种探针的详细用法教程

在Kubernetes（简称k8s）中，探针（Probes）是一种非常重要的健康检查机制，用于监测Pod内容器的运行状况。通过合理配置探针，可以确保应用程序在Kubernetes集群中保持健康、可用和可靠。本文将结合实际案例，详细介绍Kubernetes中的三种探针：存活探针（Liveness Probe）、就绪探针（Readiness Probe）和启动探针（Startup Probe）的用法。

一、概述

Kubernetes中的探针主要用于检测容器内应用程序的健康状态，并根据检测结果采取相应的操作，如重启容器、从服务负载均衡中剔除等。这些探针通过PodSpec中的livenessProbe、readinessProbe和startupProbe字段进行配置。

二、存活探针（Liveness Probe）

存活探针主要用于检测容器内的主进程或服务是否仍然运行正常且响应健康检查。如果存活探针失败，Kubernetes将自动重启容器，以尝试恢复应用程序的健康状态。

1. 探针类型

存活探针支持三种类型：HTTP GET请求、TCP Socket检查和执行命令（Exec）。

• HTTP GET请求：通过向容器内指定的端口发送HTTP GET请求来检查应用的状态。如果收到的HTTP响应码在200-399范围内，则认为探测成功。
• TCP Socket检查：尝试与容器上指定的端口建立TCP连接。如果连接成功，则认为探测成功。
• 执行命令：在容器内部执行一个命令，并根据命令退出时返回的状态码判断容器是否正常运行。如果命令返回0，则表示成功。

2. 配置文件示例

以下是一个使用HTTP GET请求的存活探针配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-container
    image: my-image:latest
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3

在这个例子中，Kubernetes会向容器的8080端口发送HTTP GET请求，请求路径为/healthz。如果收到200-399范围内的响应码，则认为容器存活。探针会在容器启动后延迟30秒开始执行，每隔10秒执行一次，超时时间为1秒。如果连续失败3次，则认为容器不健康，Kubernetes将重启容器。

3. 实际应用案例

假设有一个Web应用程序，其主进程是一个HTTP服务器。如果服务器因为某种原因停止响应或崩溃，我们需要一种机制来自动重启它。此时，可以使用存活探针来定期检测服务器的健康状态。如果存活探针失败，Kubernetes将自动重启Pod，从而恢复服务的可用性。

三、就绪探针（Readiness Probe）

就绪探针用于检测容器是否已经准备好接收流量。如果就绪探针失败，Kubernetes将从服务的负载均衡池中删除该容器，直到探针再次成功。

1. 探针类型

与存活探针类似，就绪探针也支持HTTP GET请求、TCP Socket检查和执行命令三种类型。

2. 配置文件示例

以下是一个使用HTTP GET请求的就绪探针配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-container
    image: my-image:latest
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 3

在这个例子中，Kubernetes会向容器的8080端口发送HTTP GET请求，请求路径为/ready。如果收到200-399范围内的响应码，则认为容器已准备好接收流量。探针会在容器启动后延迟5秒开始执行，每隔10秒执行一次，超时时间为1秒。如果连续失败3次，则认为容器未就绪，Kubernetes将从服务负载均衡池中删除该容器。

3. 实际应用案例

假设有一个数据库应用程序，它在启动后需要执行一系列初始化操作（如加载数据、创建索引等）。在这些初始化操作完成之前，应用程序可能无法处理外部请求。为了避免在初始化过程中接收流量，可以使用就绪探针来检测应用程序是否已准备好接收请求。如果就绪探针失败，Kubernetes将不会将流量路由到该容器，直到就绪探针成功，表示应用程序已经准备好，Kubernetes才会将流量重新路由到该容器。

四、启动探针（Startup Probe）

启动探针是Kubernetes 1.16版本中引入的一种新类型的探针，用于处理容器启动过程中可能出现的延迟或临时故障。在某些情况下，应用程序可能需要较长时间来完成初始化过程（如加载大量数据、执行复杂的配置检查等），这可能导致存活探针过早地判断容器不健康并重启它。启动探针就是为了解决这个问题而设计的。

1. 探针类型

启动探针同样支持HTTP GET请求、TCP Socket检查和执行命令三种类型，与存活探针和就绪探针相同。

2. 配置文件示例

以下是一个使用执行命令的启动探针配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: my-long-starting-app
spec:
  containers:
  - name: my-container
    image: my-long-starting-image:latest
    startupProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 30
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 3
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      failureThreshold: 3
      periodSeconds: 10

在这个例子中，startupProbe 使用了一个执行命令的探针，该命令尝试读取 /tmp/healthy 文件。如果文件存在且命令成功执行（即返回状态码0），则认为容器启动成功。failureThreshold 设置为30，意味着如果探针连续失败30次（每次间隔10秒），Kubernetes才会认为启动失败。同时，该Pod还配置了存活探针和就绪探针，用于在容器启动后持续检查其健康状态和就绪状态。

3. 实际应用案例

假设有一个大型Web应用程序，它在启动时需要进行复杂的初始化操作，如数据库迁移、配置加载等，这些操作可能需要几分钟甚至更长时间来完成。如果在此期间存活探针过早地判断容器不健康并重启它，将会导致初始化过程被中断。为了避免这种情况，可以使用启动探针来延迟存活探针的检查，直到容器完成初始化并准备好接受健康检查。

五、探针的协同工作

在Kubernetes中，存活探针、就绪探针和启动探针可以协同工作，以确保Pod的健康和可用性。通常，一个Pod会同时配置这三种探针，但它们的职责和触发条件各不相同：

• 启动探针：在容器启动后立即开始执行，用于检测容器是否处于启动过程中。如果启动探针成功，则允许存活探针和就绪探针开始工作。如果启动探针失败（达到failureThreshold指定的次数），则Kubernetes将重启容器。
• 存活探针：在容器启动且启动探针（如果有）成功后开始执行，用于检测容器是否仍然存活。如果存活探针失败，则Kubernetes将重启容器。
• 就绪探针：在容器启动且启动探针（如果有）成功后开始执行，用于检测容器是否已准备好接收流量。如果就绪探针失败，则Kubernetes将从服务的负载均衡池中删除该容器，直到就绪探针再次成功。

通过合理配置这三种探针，可以确保Kubernetes集群中的Pod始终保持在健康、可用和可靠的状态，从而提高整个系统的稳定性和可靠性。

六、探针配置的最佳实践

在配置Kubernetes中的探针时，遵循一些最佳实践可以帮助确保探针的有效性和准确性，从而优化Pod的行为和整个集群的稳定性。

1. 合理设置初始延迟时间：

   • initialDelaySeconds 参数定义了探针开始执行前的延迟时间。这个值应该足够长，以允许容器完成其初始化过程。过短的延迟时间可能导致探针在容器完全启动之前就执行，从而产生误报。

2. 调整检查频率和超时时间：

   • periodSeconds 参数定义了探针执行的频率。这个值应该根据应用程序的响应时间和健康检查的需求来设置。过低的频率可能导致问题发现不及时，而过高的频率则可能增加不必要的资源消耗。
   • timeoutSeconds 参数定义了探针等待响应的超时时间。这个值应该足够长，以允许应用程序在负载较高或响应较慢时也能成功响应探针请求。

3. 设置合理的成功和失败阈值：

   • successThreshold 和 failureThreshold 参数分别定义了探针成功和失败的连续次数阈值。这些值应该根据应用程序的稳定性和健康检查的可靠性来设置。过低的阈值可能导致探针过于敏感，而过高的阈值则可能延迟问题的发现。

4. 选择适当的探针类型：

   • 根据应用程序的特性选择最适合的探针类型。HTTP GET请求适用于Web应用程序，TCP Socket检查适用于基于TCP协议的服务，而执行命令则适用于需要运行特定检查脚本的场景。

5. 考虑探针的副作用：

   • 某些探针（尤其是执行命令的探针）可能会对应用程序的性能产生影响。确保探针的执行不会对应用程序的正常运行造成不必要的负担。

6. 日志和监控：

   • 配置适当的日志记录和监控，以便在探针失败时能够快速定位问题原因。这包括应用程序日志、Kubernetes事件和Prometheus等监控系统的数据。

7. 测试和优化：

   • 在生产环境部署之前，在测试环境中充分测试探针的配置。根据测试结果调整探针的参数，以优化其性能和准确性。

8. 利用Kubernetes的自动扩展和故障恢复机制：

   • 结合Kubernetes的Horizontal Pod Autoscaler（HPA）和自动故障恢复机制，可以进一步提高应用程序的可用性和扩展性。当探针检测到问题时，Kubernetes可以自动重启Pod、重新调度Pod或扩展Pod的数量来应对负载变化。

七、实际案例分析

假设你正在部署一个微服务架构的应用程序，其中包含多个相互依赖的服务。为了确保服务的可靠性和可用性，你决定为这些服务配置探针。

• 服务A：一个Web服务器，负责处理外部HTTP请求。你可以为服务A配置HTTP GET请求的存活探针和就绪探针。存活探针定期检查/healthz端点以确保服务器仍然运行。就绪探针检查/ready端点以确保服务器已准备好处理请求。

• 服务B：一个数据库服务，用于存储应用程序的数据。由于数据库启动可能需要较长时间来加载数据和初始化，你可以为服务B配置启动探针来延迟存活探针的检查。同时，你还可以配置TCP Socket检查的存活探针来检测数据库服务是否仍然运行。

• 服务C：一个消息队列服务，用于处理异步消息。由于消息队列服务在启动时通常会有一定的预热过程，你可以为服务C配置执行命令的启动探针来检查某个特定文件或目录是否存在，以判断服务是否已完全启动。

通过为这些服务配置合适的探针，你可以确保它们在Kubernetes集群中保持健康、可用和可靠。当探针检测到问题时，Kubernetes将自动采取相应的操作来恢复服务的正常运行。

八、总结

Kubernetes中的存活探针、就绪探针和启动探针是确保Pod健康运行的重要工具。通过合理配置这些探针，你可以实时监控容器的状态，并在发现问题时自动采取恢复措施。遵循最佳实践、测试和优化探针配置，可以进一步提高应用程序的可用性和稳定性。在实际应用中，根据应用程序的特性和需求选择合适的探针类型和参数，并结合Kubernetes的其他特性（如自动扩展和故障恢复）来优化整个集群的性能和可靠性。