基础设施架构：容器构建第四平面

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

传统网络基础设施通常包含三个架构平面：数据平面、控制平面和管理平面。

这些平面的确切定义可能因基础设施的类型和具体实现方式而异，但这些典型划分基本适用于大多数网络基础设施。

• 数据平面
  
  • 在现代术语中，数据平面有时也称为数据路径，是数据包（数据）传输所经过的路径。数据平面负责接收数据包并将其转发到正确的目的地。
• 控制平面
  
  • 通常，控制平面决定数据的转发位置。路由协议是控制平面功能的典型示例，如今可能更具动态性的高层决策也是如此。具体实现方式各不相同，既可以由数据平面将数据传递给控制平面进行决策，也可以由控制平面以透明方式观察数据，并在特定条件触发时采取行动。控制平面通常还负责监控设备的运行状况并收集统计信息。
• 管理平面
  
  • 管理平面是三个平面中最直观的，因为我们通过它与控制平面交互。传统管理平面使用命令行界面（CLI），而现代管理平面更倾向于使用应用程序编程接口（API）。无论采用哪种方式，操作人员都可以通过管理平面设置由控制平面实施的策略，其中包括负载均衡算法等配置选项，以及基于IP地址和设备类型等特征的允许或拒绝策略。

但还有另一种编排在底层运行，操作人员基本无法察觉。它与管理无关，只是接管了人工操作人员的部分职责。

这里的区别在于，这些操作是在执行期间由环境变化自动触发的，而不是由部署事件触发的。但有关具体变化的信息至关重要，因此必须从某处获取。

在传统运维模式中，这些信息通常来自变更工单或请求。在现代运维模式中，尤其是容器环境下，这些信息通过发现机制从服务注册中心获取。

服务注册表与发现

容器环境的一个固有假设是，IP地址对应用环境实际上并不重要。但IP地址对基础设施至关重要，因为数据仍需在设备之间进行路由和转发，才能通过客户端与应用之间的路径。在现代环境中，这些IP地址通常只会短暂存在（即容器或服务的生命周期）。

请看DataDog的以下研究结果（重点为后加）：

编排器的快速普及（参见事实4）似乎正在进一步缩短容器的生命周期，因为容器的自动启动和停止会导致更高的更替率。在运行编排器的组织中，容器的典型生命周期约为12小时。在未使用编排的组织中，容器的平均生命周期为6天。

_{来源：<https://www.datadoghq.com/docker-adoption>}

试想一下，作为运维人员，如果每6天就必须更新一次路由表或负载均衡池，更不用说每12小时更新一次，您几乎无暇处理其他工作。配置错误的可能性会很高，而且被迫以手动方式管理容器集群变更的时间越长，这种可能性就越大。

服务注册中心（例如Consul）会成为容器部署中的关键组件。服务注册中心会跟踪实例和服务及其关联的IP地址。从这个角度来看，可以将其比作“容器和服务的DNS”。

因此，服务注册中心会跟踪集群中容器的当前特征。服务发现是连接到服务注册中心（通过API或订阅消息队列），将实例与IP地址进行匹配的过程。

这意味着，需要将流量路由到容器集群内特定服务或实例的基础设施必须能够获取IP地址。虽然容器对应用隐藏了网络，但仍需依靠网络将数据从一处传输到另一处。

第四个平面：编排

这会在基础设施中引入一个与容器编排环境交互的新架构层。该层称为编排层，它与容器环境集成，并利用服务发现等功能，自动发现服务和实例。这意味着负载均衡器可以自动发现池成员，并根据环境变化持续更新成员信息。这样可以减轻运维人员手动更新负载均衡池的负担；当容器的平均生命周期不足一周时，这项工作会变得愈发繁琐。

该平面不用于与运维人员交互。配置、监控和操作仍通过管理平面完成。服务注册表的位置通过管理平面配置，但由编排平面使用，以连接控制平面并向其传达变更。

我们可以将编排平面定义如下。

• 编排平面是基础设施架构中最不易察觉的平面之一。与编排平面的交互通过管理平面完成，管理平面的主要职责是将编排平面指向适当的服务注册表。编排平面负责更新控制平面中的动态组件，以确保容器化资源得到正确转发并保持可用。

目前仍有一个问题：该平面是应与控制平面和数据平面一起集成到设备中，还是仅仅作为管理平面的上层封装（这会使示意图略有变化，但不会影响平面与组件之间的交互）。许多传统设备已通过提供可与容器环境集成并经由管理平面实施变更的扩展，来支持这一新兴平面。这是重构传统架构以将功能扩展到现代环境的一个典型示例，但最终可能并非理想的解决方案。

为什么这很重要？

乍看之下，为基础设施引入第四个平面似乎无关紧要。毕竟，它的作用是减轻运维人员处理繁琐任务的部分负担，这并非坏事。

这并非坏事，但必须认识到，从静态配置转向动态配置会影响控制平面的一些关键功能。服务发现变得至关重要，因此必须确保其可用性和安全性。实际上，它会成为整个应用基础设施所依赖的单点故障源。

服务注册中心与大多数现代应用基于相同的前提构建，即能够应对故障。可能会出现这种情况：刚发现的IP地址在流量转发到相应实例之前就已消失。此时，大多数基础设施都能重新传输，但这一过程需要时间。在数字经济中，微秒也至关重要。因此，对于依赖服务发现的现代架构，超时和发现间隔等传统选项会产生显著影响。监控也变得更加关键，因为能否尽快确定运行状况和可用性，可能会影响用户是感到满意还是停止使用。这两方面都是业务层面的重要事项，现代组织中的每个人都应予以关注，并将其纳入各自的指标和预期。

在决定采用何种技术时，基础设施中编排平面的实施方式以及服务注册中心的选择都会成为重要考量因素。请慎重选择，因为这些因素会影响通过容器化架构交付的应用的可用性和性能。

关于作者

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

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

Lori Mac Vittie 的更多博客文章