对于许多基础设施工程师来说，Kubernetes 可能看起来像是一层不必要的复杂性。然而，一位系统工程师最近的技术深度剖析表明，要理解该平台的效用，最好的方法是跳出 Pod、Node 和 Service 等单个组件，去关注其底层“控制循环”的机制。这些循环充当系统的引擎：它们持续观察特定变量（传感器），将其与期望状态进行比较，并执行操作（控制元件）以弥补差距。例如，如果用户定义了特定延迟的期望状态，控制循环将监控后端指标，并自动启动新的 Pod 来处理需求。
此图展示了作为系统引擎的控制循环的运作机制。
网络模型，特别是“kube-proxy”的作用，提供了一种独特的架构权衡。通过更新每个 Node 上的 netfilter 规则以将流量转发到 Service 的虚拟 IP，Kubernetes 确保每个 Node 都充当负载均衡器。这种设计消除了单点故障，并允许转发能力随集群规模扩展。然而，这也带来了特定的成本：每个 Node 必须维护所有 Service 的规则，这可能导致庞大的规则集，并且由于在某些情况下流量可能会被多次转发，可能会增加集群的负载。这种设计优先考虑高可用性和代理的简单实现，而非规则评估的绝对效率。
此图表可视化了文章引言中讨论的核心架构概念。
虽然核心引擎非常稳健，但围绕 Kubernetes 的生态系统引入了显著的摩擦，特别是在配置管理方面。作者强调了在 Helm 等工具中“字符串类型”和文本插值的普遍存在，在这些工具中，结构化的 YAML 是通过手动操作模板中的空格和缩进生成的。对于更倾向于强类型配置的开发者来说，这种方法可能不符合直觉。虽然 Pkl 或 KCL 等一些替代方案旨在提供更结构化的配置语言，但目前文本模板的主导地位仍然是那些寻求避免在基础设施即代码工作流中进行手动字符串操作复杂性的用户争论的焦点。