2. 核心概念：节点池（Node Pool）定义、配置漂移（Configuration Drift）与 GitOps 原则

在云原生基础设施管理中，节点池（Node Pool）是承载工作负载的基本计算单元集合。当节点池配置与声明式期望状态不一致时，便产生了配置漂移（Configuration Drift）。本章将明确节点池的定义、剖析配置漂移的成因，并阐述 GitOps 原则如何从根本上解决这一问题。

2.1 节点池（Node Pool）定义与关键属性

节点池是集群中一组具有相同配置的节点（虚拟机或物理机）的逻辑分组。在托管 Kubernetes 环境（如 AKS、EKS、GKE）中，节点池通常对应一组虚拟机规模集或实例组。其核心属性包括：

2.2 配置漂移（Configuration Drift）的成因与危害

配置漂移是指节点池的实际运行状态与 Git 仓库中定义的期望状态之间产生偏差。这种偏差通常由以下原因引起：

• 手动热修复（Hotfix）： 运维人员通过 SSH 登录节点或使用云控制台直接修改节点池属性（如扩缩容、升级 kubelet），而未同步更新 Git 仓库。
• 自动恢复操作： 云提供商自动替换故障节点时，可能使用了与原始配置略有不同的默认镜像或版本。
• 第三方工具干预： 集群自动缩放器（Cluster Autoscaler）或节点自动修复工具在调整节点池时，可能引入未预期的配置参数。
• 版本滞后： 节点池的 Kubernetes 版本或操作系统补丁未及时跟随 Git 仓库中的定义更新。

2.3 GitOps 原则：以声明式 Git 仓库为单一事实来源

GitOps 是一套以 Git 仓库作为基础设施和应用程序配置的单一事实来源的运维模式。其核心原则直接对抗配置漂移：

1. 声明式描述（Declarative Description）： 整个节点池的期望状态（包括实例类型、数量、标签、污点等）必须完整地以声明式文件（如 YAML）存储在 Git 仓库中。
2. 不可变基础设施（Immutable Infrastructure）： 任何节点池的变更都应通过修改 Git 仓库中的声明式文件来触发，而非直接操作运行中的节点。节点应被视为可替换的“牲畜”，而非需要手动维护的“宠物”。
3. 自动同步（Automated Sync）： 部署在集群中的 Operator（如 Argo CD）持续监控 Git 仓库中的声明式状态，并自动将节点池的实际状态收敛到期望状态。
4. 可审计与可回滚（Auditable & Rollback）： 所有节点池配置的变更历史都记录在 Git 提交日志中。一旦发生漂移或故障，可以快速回滚到任意历史版本。

2.4 节点池配置漂移与 GitOps 收敛流程

下图展示了节点池配置从期望状态到实际状态，以及漂移发生后被 GitOps 自动修复的完整流程：

2.5 节点池配置漂移的典型场景对比

下表对比了传统运维模式与 GitOps 模式在处理节点池配置变更时的差异：