适用于Kestrel .NET Core Web API的适当的Kubernetes准备和活动探测器

Question

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

看起来我们可以通过配置Kestrel的关闭超时来优雅地处理pod的终止,所以现在我们正在研究如何探测应用程序以确定准备和活跃度.

仅使用HTTP请求探测Web API是否足够？如果是这样,创建一个新的健康检查控制器以处理这些探测请求是一个好主意,还是探测在正常使用中消耗的实际端点更有意义？

在区分活跃度和准备度探测时,我们应该考虑什么？

Answer 1

我建议通过单独的端点执行运行状况检查.一般来说,这样做的原因有很多,例如:

1. 检查应用程序是否正常/准备就绪,或者更一般地说,处于健康状态不一定与向Web服务发送用户请求相同.执行运行状况检查时,您应该定义使Web服务健康的原因:例如,可以检查对外部资源(如数据库)的访问.
2. 通过端点控制谁可以实际执行运行状况检查更容易.
3. 更一般地说,您不希望弄乱实际的服务功能:否则您需要在维护服务功能时重新考虑健康检查的方式.例如,如果您的服务与数据库交互,则在运行状况检查上下文中,您要验证与数据库的连接是否正常,但您实际上并不关心服务在内部操作的数据.
4. 如果您的Web服务不是无状态,事情会变得更加复杂:在这种情况下,您需要确保数据保持一致,与您的健康检查无关.

正如您所指出的,避免上述任何一种情况的好方法可能是设置一个单独的Controller来处理健康检查.

作为替代选项,ASP.NET Core中提供了一个标准库,用于在Web服务上启用运行状况检查:在撰写本答案时,它不是ASP.NET Core的正式部分,也没有可用的NuGet包,但是有一个计划在未来的版本中发生这种情况.现在,您可以轻松地从官方存储库中提取代码,并将其包含在您的解决方案中,如Microsoft文档中所述.目前计划将其包含在ASP.NET Core 2.2中,如ASP.NET Core 2.2路线图中所述.

我个人觉得它很优雅,因为你将通过Startup.cs和配置所有内容,Program.cs并且不需要显式创建一个新的端点,因为库已经为你处理了这个.

我一直在一些项目中使用它,我肯定会推荐它.存储库包含一个特定于ASP.NET Core项目的示例,您可以使用它来快速加快速度.

活力与准备

在Kubernetes中,您可以通过HTTP设置活动和准备探测:如Kubernetes文档中所述,虽然两者的设置几乎相同,但Kubernetes根据探测采取不同的操作:

来自Kubernetes文档的活动探测:

许多运行很长时间的应用程序最终会转换到损坏状态,除非重新启动,否则无法恢复.Kubernetes提供活体探测器来检测和纠正这种情况.

来自Kubernetes文档的准备情况探测:

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

因此,虽然对活体探测器的不健康响应将导致Pod(以及应用程序)被杀死,但对准备探测的不健康响应将导致Pod在其恢复到健康状态之前不接收任何流量.

在区分活跃度和准备度探测时应该考虑什么？

对于活跃性探测:我建议定义什么使您的应用程序健康,即用户消费的最低要求,并基于此实施健康检查.这通常涉及作为单独进程运行的外部资源或应用程序,例如数据库,Web服务等.您可以使用ASP.NET Core Health Checks库或使用单独的Controller手动定义运行状况检查.

准备工作探测:您只是想加载您的服务以验证它实际上是否及时响应,因此允许Kubernetes相应地平衡流量.平凡(并且在大多数情况下,如Lukas在另一个答案中所建议的那样),您可以使用与活跃度相同的完全终点但设置不同的超时,但这实际上取决于您的需求和要求.

Answer 2

区分活性探针和就绪探针时我们应该考虑什么

我的建议是/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，同时保持默认的活动超时。