asp.net-core - 适用于Kestrel .NET Core Web API的适当的Kubernetes准备和活跃性探针

Question

我们的目标是使用Kubernetes横向扩展.NET Core 2.0 Web API。 Web API应用程序将由Kestrel提供。

看起来我们可以通过配置Kestrel的关闭超时来优雅地处理Pod的终止，因此现在我们正在研究如何探查应用程序以确定就绪状态和活跃性。

仅使用HTTP请求探测Web API就足够了吗？如果是这样，那么创建一个新的运行状况检查 Controller 来处理这些探测请求是一个好主意，或者探测一个正常使用时会消耗的实际端点是否更有意义？

在区分 Activity 性和就绪性探针时，我们应该考虑什么？

Answer 1

我建议通过单独的端点执行运行状况检查。
通常，这样做的原因很多，例如:

检查应用程序是否已就绪/就绪，或更普遍地说，处于健康状态，不一定与将用户请求发送到您的Web服务相同。执行运行状况检查时，您应该定义使您的Web服务保持健康的原因:例如检查对外部资源(例如数据库)的访问。

通过端点可以更轻松地控制谁可以实际执行运行状况检查。

通常，您不想弄乱实际的服务功能:否则，您将需要重新考虑在维护服务功能时进行运行状况检查的方式。例如。如果您的服务与数据库进行交互，则在运行状况检查上下文中，您想验证与数据库的连接是否正常，但是实际上您并不关心服务内部在操作的数据。

如果您的Web服务不是无状态的，事情会变得更加复杂:在这种情况下，您将需要确保数据独立于运行状况检查而保持一致。

正如您所指出的，避免上述情况的一种好方法是设置一个单独的Controller来处理运行状况检查。

作为一种替代选择，ASP.NET Core中提供了一个标准库，用于在您的Web服务上启用 Health Checks:在撰写此答案时，它不是ASP.NET Core的正式组成部分，并且尚无NuGet软件包，但是有一个计划在将来的版本中实现。现在，您可以轻松地从 Official Repository中提取代码并将其包含在解决方案中，如 Microsoft documentation中所述。
如 ASP.NET Core 2.2 Roadmap中所述，当前计划将其包含在ASP.NET Core 2.2中。

我个人觉得它非常优雅，因为您将通过 Startup.cs和 Program.cs配置所有内容，并且无需显式创建新的终结点，因为该库已经为您处理了。

我已经在一些项目中使用过它，我肯定会推荐它。
该存储库包含特定于ASP.NET Core项目的 example，您可以使用它来快速入门。

活力与准备

然后在Kubernetes中，您可以通过Http设置 Activity 性和就绪性探针:如 Kubernetes documentation中所述，虽然两者的设置几乎相同，但Kubernetes会根据探针采取不同的操作:

Kubernetes documentation的 Activity 探针:

Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted. Kubernetes provides liveness probes to detect and remedy such situations.

Kubernetes documentation中的 准备情况调查:

Sometimes, applications are temporarily unable to serve traffic. For example, an application might need to load large data or configuration files during startup. In such cases, you don’t want to kill the application, but you don’t want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. A pod with containers reporting that they are not ready does not receive traffic through Kubernetes Services.

因此，尽管对 Activity 性探针的不健康响应将导致Pod(因此是应用程序)被杀死，但对就绪性探针的不健康响应将仅导致Pod在恢复到健康状态之前不接收流量。

区分 Activity 性和就绪性探针时应考虑什么？

对于活力探针:
我建议定义什么使您的应用程序保持健康，即用户消耗的最低要求，并基于此进行运行状况检查。
这通常涉及作为独立进程运行的外部资源或应用程序，例如数据库，Web服务等
您可以通过使用ASP.NET Core健康检查库或通过单独的Controller手动定义健康检查。

对于准备情况调查:
您只需要加载服务以验证其是否及时响应，从而允许Kubernetes相应地平衡流量。琐碎的(在大多数情况下，是Lukas在另一个答案中建议的)，您可以使用与 Activity 相同的确切端点，但是设置不同的超时时间，但这实际上取决于您的需求和要求。