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

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

监控是保障可用性的核心。每个负载均衡器在选择目标资源之前，都必须知道该资源是否确实可用。否则，负载均衡又有何意义？

在资源生命周期可能以分钟而非小时或天来衡量的环境中，在决定向资源发送请求之前了解其状态就显得尤为重要。

运行状况监控是负载均衡器和代理不可或缺的一部分。在容器化环境中也是如此（或者说理应如此）。随着这些环境不断快速成熟，新的监控模式正在涌现，以应对此类高度动态的分布式系统所特有的一些挑战。

传统健康监控当然是其中一环，但容器环境中的一些可用性和扩展模型会给传统健康监控带来必须解决的压力。例如，以正向代理模式部署的代理应能够从健康（可用）的所有可能的服务中选择目标。反向代理（也就是传统的负载均衡器）只负责跟踪单个应用的一组特定服务的状态，而正向代理则需要掌握环境中每个应用的每项服务的状态。毕竟，将请求发送到已经停止服务的容器可不是什么好事，对吧？

传统健康监控

传统上，代理通过以下两种方式执行健康监控：

• 主动监控：向容器发送探测或运行状况检查请求，并评估其响应。
• 被动监控： 观察自然产生的客户端请求及其响应。

可以想象，如果每项服务的每个正向代理都执行主动监控，本地网络流量将大幅增加，并造成不必要的资源消耗。有效的监控至少应在TCP层进行，理想情况下还应在HTTP层进行。毕竟，网络连通性并不能反映服务的运行状况或可用性。随着节点数量（以及正向代理数量）的增加，占用TCP连接和执行HTTP处理会迅速加重容器负担。应避免因监控导致容器不堪重负而不得不扩容。

在这种情况下，被动监控是更合适的选择，因为它不会给受监控的系统带来负担，但在某些容器环境中也存在局限性。许多容器环境基于覆盖网络原理构建，因此很难确保每个代理都能看到并跟踪每个服务响应。这并非无法实现，但在网络层面颇具挑战。

这两种模式也会给代理本身带来负担，需要将资源专门用于监控环境，而无法用于代理原本应执行的任务：扩展服务。

容器化健康监控

容器环境同样面临这些挑战。为此，两种新模式正在兴起，它们无疑有助于确保采用正向代理来提升可用性和扩展能力的架构保持可用。

这两种模型是：

• 环境监控： 代理可根据容器编排环境（COE）提供的容器运行状况信息，了解容器是否正常运行及是否可用。
• 共享监控：由于一个环境中可能存在多个代理，因此可由各代理分担监控工作并共享结果。

环境监控通常与服务注册表相关联，后者会跟踪容器进入和离开系统的情况。因此，服务注册表通常是系统中容器可用性方面较为权威的信息来源。代理还可以订阅容器创建和销毁时触发的事件，以便自行跟踪这些资源（实际上相当于自身充当注册表）。

例如，如果在Marathon中为某个应用启用了运行状况监控，代理可以使用“healthCheckResults”字段。在Kubernetes中，代理可以使用存活检查和就绪检查中的一种或两种。环境运行状况检查可让代理在编排系统重启运行状况不佳的端点之前，开始选择运行状况更好的端点。

在采用正向代理模型的系统中，共享监控非常合理，尤其是以服务网格为基础的系统，例如Istio。与节点关联的代理可以监控其所转发请求对应容器的运行状况和可用性（这与在反向代理模型中跟踪服务的方式大致相同）。但在此类系统中，显然不应让每个代理都主动探测每个端点。因此，通过与其他代理共享本地运行状况信息（更理想的方式是与环境共享），所有代理都能获取系统的全部已知状态，而无需对每项服务执行过多的运行状况检查。

在负载均衡等应用服务领域，“网络”正在发生诸多变化，这些服务的交互方式也在不断调整，以满足容器化等新模式的需求和要求。这些要求持续推动代理不断适应变化。这是因为，代理是过去20年间发展起来的灵活性较高的技术之一，并且仍是应用服务设计、开发和部署的重要基础。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章