Asp.net core 适用于Kestrel.NET核心Web API的Kubernetes就绪性和活跃性探测器

我们的目标是使用Kubernetes水平扩展.NETCore2.0WebAPI。Web API应用程序将由Kestrel提供服务

看起来我们可以通过配置Kestrel的关机超时来优雅地处理POD的终止，所以现在我们正在研究如何探测应用程序以确定就绪性和活跃性

仅仅用HTTP请求探测Web API就足够了吗？如果是这样的话，创建一个新的healthcheck控制器来处理这些探测请求是一个好主意，还是探测一个在正常使用中使用的实际端点更有意义

当区分活跃度和准备度时，我们应该考虑什么？

当活跃度与准备度之间的差异探测

时，我们应该考虑什么？ 我的建议是在应用程序中提供一个独立于应用程序端点的

/health

端点。如果您想阻止消费者调用内部健康端点，这非常有用。然后，您可以配置Kubernetes来查询HTTP

/health

端点，如下面的示例所示

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - name: http
      containerPort: 8080
    readinessProbe:
      httpGet:
        port: http
        path: /health
      initialDelaySeconds: 60
    livenessProbe:
      httpGet:
        port: http
        path: /health

在

/health

端点内，您应该检查应用程序的内部状态，如果一切正常，则返回状态代码

200

，如果应用程序出现问题，则返回状态代码

503

。请记住，对于每个实例，通常每15秒执行一次运行状况检查，如果要执行昂贵的操作来确定应用程序状态，则可能会降低应用程序的速度

当活跃度与准备度之间的差异探测

时，我们应该考虑什么？

---

通常，活跃度和准备度探测之间的唯一区别是每个探测中的超时。也许您的应用程序需要60秒才能启动，那么您需要将就绪探测的初始超时设置为60秒，同时保持默认的活动超时

我建议通过单独的端点执行健康检查。 一般来说，这样做有很多好的理由，比如：

检查应用程序是否处于活动/就绪状态，或者更一般地说，是否处于健康状态，不一定与向web服务发送用户请求相同。在执行健康检查时，您应该定义使web服务健康的因素：例如，检查对外部资源（如数据库）的访问

更容易控制谁可以通过端点实际执行健康检查

更一般地说，您不希望弄乱实际的服务功能：否则，您需要重新考虑在维护服务功能时进行健康检查的方式。例如，如果您的服务与数据库交互，则在运行状况检查上下文中，您希望验证与数据库的连接是否正常，但实际上您并不太关心您的服务在内部操纵的数据

如果您的web服务不是无状态的，事情会变得更加复杂：在这种情况下，您需要确保数据与健康检查保持一致

正如您所指出的，避免上述任何情况的一个好方法是设置一个单独的控制器来处理健康检查

作为另一种选择，ASP.NET Core中有一个标准库可用于在web服务上启用：在编写此答案时，它还不是ASP.NET Core的正式部分，并且还没有可用的NuGet软件包，但计划在将来的版本中实现这一点。现在，您可以轻松地从中提取代码，并将其包含在解决方案中，如中所述。 目前计划将其包括在ASP.NET Core 2.2中，如中所述

我个人觉得它非常优雅，因为您将通过

Startup.cs

和

Program.cs

配置所有内容，并且不需要显式创建新端点，因为库已经为您处理了

我已经在一些项目中使用过它，我肯定会推荐它。 该存储库包含一个特定的ASP.NET核心项目，您可以使用它快速了解最新情况

活力与准备 在Kubernetes中，您可以通过HTTP设置活动性和就绪性探测：如中所述，虽然两者的设置几乎相同，但Kubernetes会根据探测采取不同的操作：

活性探针来自：

许多长时间运行的应用程序最终会转换为中断状态，除非重新启动，否则无法恢复。Kubernetes提供了活力探测器来检测和纠正这种情况

准备就绪探测来自：

有时，应用程序暂时无法为流量提供服务。例如，应用程序可能需要在启动期间加载大型数据或配置文件。在这种情况下，您不想终止应用程序，但也不想向其发送请求。Kubernetes提供准备就绪探测器来检测和缓解这些情况。容器报告未准备就绪的pod不会通过Kubernetes服务接收流量

因此，尽管对liveness探测器的不健康响应会导致Pod（以及应用程序）被终止，但对readiness探测器的不健康响应只会导致Pod在恢复正常状态之前不接收任何流量

<>强>区分活跃性和准备性时应考虑什么？< /强>

对于活性探针： 我建议您定义使应用程序健康的因素，即用户消费的最低要求，并在此基础上实施健康检查。 这通常涉及作为单独进程运行的外部资源或应用程序，例如数据库、web服务等。 您可以使用ASP.NET核心运行状况检查来定义运行状况检查