容器编排环境如何影响健康监测

可用性的核心是监控。 每个负载均衡器在选择目标资源之前必须知道该资源是否实际可用。 否则，还有什么意义呢？

在资源的生命周期可能以分钟而不是小时或天来衡量的环境中，在决定向资源发送请求之前了解资源的状态变得更加重要。

健康监测是负载均衡器和代理的重要组成部分。 在容器化环境中这也是正确的（或者应该是正确的）。 随着这些环境不断（快速）成熟，我们看到新的监控模型出现，以应对与这种高度不稳定的分布式系统相关的独特挑战。

传统的健康监测当然是其中的一部分，但容器环境内的一些可用性和规模模型给传统的健康监测带来了压力，必须加以解决。 例如，预计在正向代理模型中部署的代理能够在所有可能的服务中选择一个健康（可用）的目标。 反向代理（如果您愿意的话，可以称为传统的负载均衡器）仅负责跟踪单个应用的一组特定服务的状态，而正向代理负责了解环境中每个应用的每个服务的状态。 因为向已经停止服务的容器发送请求是不好的，好吗？

传统健康监测

传统上，健康监测通过两种方式由代理完成：

• 主动监控： 向容器发送探测或健康检查请求并评估其响应。
• 被动监控： 观察自然的客户请求及其反应。

你可以想象，每个服务的每个转发代理的主动监控将会大大增加本地网络上的流量并不必要地消耗资源。 有用的监控至少发生在 TCP 层，理想情况下发生在 HTTP 层。 毕竟，网络连接并不是服务健康或可用性的指标。 随着节点数量（以及转发代理数量）的增加，消耗 TCP 连接并需要 HTTP 处理将很快给容器带来负担。 您不希望因为容器监控不堪重负而不得不扩大规模。

在这种情况下，被动监控是一个更好的选择，因为它不会给被监控的系统带来负担，但在某些容器环境中确实有其局限性。 许多都是建立在覆盖网络原理之上的，这使得确保每个代理都能看到每个服务响应并跟踪它变得非常具有挑战性。 这并非不可能，但是在网络层面上具有挑战性。

这两种模型也给代理本身带来了负担，要求将资源专用于监控环境，而不是用于执行的任务：扩展服务。

容器化健康监测 

容器环境并非不知道这些挑战。 作为回应，我们看到两种新模型的出现，这肯定有助于确保采用前向代理实现可用性和规模的架构中的可用性。

这两个模型是：

• 环境监测： 通过来自容器编排环境 (COE) 的有关容器健康状况的信息，代理可以了解健康状况/可用性。
• 共享监控： 因为一个环境中可能存在很多代理，所以可以将监控工作划分到各个代理之间并共享结果。

环境监控通常与服务注册表相关，服务注册表会跟踪进入和离开系统的容器。 这意味着它通常是系统中最权威的容器可用性来源。 代理还可以订阅由容器创建和销毁触发的事件，以便跟踪这些资源本身（实际上，充当注册表）。

例如，如果为 Marathon 中的应用启用了健康监测，则代理可以使用“healthCheckResults”字段。 在 Kubernetes 中，代理可以使用活跃度和/或就绪度检查。 环境健康检查允许代理在编排系统重新启动不健康的端点之前开始选择更健康的端点。

在采用正向代理模型的系统中，共享监控非常有意义，特别是那些像Istio这样具有服务网格基础的系统。 与节点关联的代理当然可以设法监视它正在转发请求的那些容器的健康和可用性（与它在反向代理模型中跟踪服务的方式非常相似）。 但您肯定不希望每个代理都主动探测这样的系统中的每个端点。 因此，通过与其他代理（或更好的是与环境）共享本地健康信息，所有代理都可以获得系统的整个已知状态，而无需对每个服务进行过多的健康检查。

在应用服务（如负载平衡）以及它们如何交互以满足容器化等新模型的需求和要求方面，“网络”正在发生很多变化。 这些要求不断给代理人带来适应压力。 这是因为代理是过去二十年里开发的最灵活的技术之一，并且继续成为应用服务设计、开发和部署的重要基础。