在容器领域，声明式配置占据主导地位

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

内部数字化转型是实现外部数字化转型不可或缺的一环。自动化是内部数字化转型的基础组成部分之一，而自动化在很大程度上依赖于控制平面。控制平面是实现自动化的核心。在早期计算时代，我们称其为“管理网络”，并使用SNMP等协议来实现监控、配置和控制。

如今，管理网络至少在理论上仍然存在，作为我们通过控制平面执行相同任务的媒介。控制平面是一个由API、主节点甚至消息队列交织而成的复杂领域，使复杂分布式系统中的各个组件能够（近乎）自动地进行自我管理。控制平面日益由事件驱动，这要求我们转变思维方式，不再沿用过去主要依赖命令式管理模型的集中式命令与控制模式。也就是说，中央系统通过特定的API调用向组件发出隐式指令，从而触发变更。相比之下，如今的环境依赖声明式模型，将自我变更的责任分配给各个组件。

这一点在容器化环境中体现得尤为明显。从外部看，这类系统几乎处于无序自治状态：消息和事件随意发布和触发，没有一个中央控制者来指示由谁或什么组件作出响应。控制平面的重点已不再是控制，而是在一个平面上实现分布式协作；这个平面更像网状结构，而非传统管理系统陈旧的中心辐射式架构。在传统环境中，我们使用API和协议将变更推送到组件。在数字化的容器化环境中，我们则使用API拉取组件实现自我变更所需的信息。

这一新环境采用响应式机制，不再沿用传统控制平面的命令式（API驱动）模型，而是依托更开放的声明式模型，实现所需的自动化最终状态。

这并不令人意外。随着我们越来越多地采用软件驱动的方法来处理一切事务（以DevOps、云和NFV为代表），我们也不得不同时应对庞大的运维规模。中心辐射式的命令式管理模型无法高效扩展，因为所有变更的负担都集中在中央控制器上，而该控制器需要通过一系列复杂的API与数量近乎无限的组件通信。这是一种“推送”模型，由管理器（控制器）将变更推送到每个受影响的组件。它会成为决定整个系统成败的瓶颈。

要实现规模扩展并减轻控制器的负担，需要采用事件驱动模型，由组件主动拉取信息。这也要求希望加入该控制平面的组件能够适应声明式配置模型。容器促使我们不再通过API推送变更（命令式），而是通过声明式配置拉取变更。组件提供商（无论是开源还是商业提供商）有责任正确订阅变更，并拉取立即实施相应变更所需的信息。

如果这听起来像基础设施即代码，那就对了。声明式配置本质上就是代码，至少也是代码制品。自动化越来越依赖这样一个前提：将配置与其服务解耦。在理想模型中，这些声明式配置完全不受特定产品或厂商限制。也就是说，任何支持该服务的厂商产品（无论是商业产品还是开源产品）都能读取这些配置。例如，一份描述相应服务（虚拟服务器）及构成其资源池的应用的声明式配置，可以由服务X或服务Y读取并实施。

Kubernetes资源文件是声明式配置模型的典型示例。在这种模型中，只描述期望实现的目标，而不规定具体的实现方式。这与依赖基础设施API的系统明显不同，后者要求实现方熟悉，有时甚至要深入了解如何实现预期结果。

声明式模型还支持将基础设施视为“牲畜”来管理。如果某个实例发生故障，只需将其终止并启动一个新实例。所需的全部配置都在资源文件中；这里没有“保存工作，否则工作将丢失”按钮，因为根本没有需要保存的工作。这种基础设施近乎不可变，并且可以随时弃用。对于每分钟甚至每秒都在变化的系统而言，这是最大限度降低故障影响的必要条件。

随着我们日益转向大规模自动化系统，甚至可以说是安全自动化系统，我们需要采用声明式模型来管理构成应用数据路径的众多设备和服务，否则，手动集成和自动化方法所积累的运维债务可能会让我们不堪重负。

关于作者

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

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

Lori Mac Vittie 的更多博客文章