Flux 架构基础：核心组件及其在节点池管理中的作用

Flux v2 采用 多控制器、关注点分离 的架构设计。每个控制器负责 GitOps 工作流中的一个独立环节，通过标准的 Kubernetes 自定义资源（CRD）进行协作。在节点池配置变更与版本回滚场景中，理解这四个核心控制器的职责与交互是制定巡检策略的前提。

2.1 核心组件总览

2.2 Source Controller：配置的“源头”

Source Controller 是 Flux 流水线的起点。它持续监视配置仓库（Git 或 OCI），当检测到新的提交或 Tag 时，拉取制品并更新本地的 Artifact 对象。

• 节点池场景： 节点池的 YAML 配置（如 cluster.x-k8s.io/v1beta1 的 MachineDeployment、ClusterClass 的补丁）通常存储在 Git 仓库的特定路径下。Source Controller 确保集群中缓存的版本与仓库一致。
• 巡检要点：
  • 检查 GitRepository 的 status.conditions 是否为 Ready=True。
  • 检查 status.artifact.revision 是否指向预期的 commit SHA。
  • 检查 status.artifact.lastUpdateTime 是否在合理时间范围内。

# 检查 Source 状态示例
kubectl get gitrepository node-pool-config -n flux-system -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# 输出应为 True
kubectl get gitrepository node-pool-config -n flux-system -o jsonpath='{.status.artifact.revision}'
# 输出示例: main@sha1:9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b

2.3 Kustomize Controller：配置的“渲染器与应用器”

Kustomize Controller 是 Flux 中最核心的控制器。它从 Source Controller 获取制品，根据 Kustomization 资源定义的路径和补丁策略进行渲染，然后将最终清单应用到集群。

• 节点池场景： 节点池配置通常采用 Kustomize overlay 结构（base + 环境补丁）。Kustomize Controller 负责将 base 层的通用配置与特定节点池的补丁（如调整 kubelet 参数、添加 taints/labels）合并，生成最终的 MachineDeployment 或 ClusterClass 实例。
• 巡检要点：
  • 检查 Kustomization 的 status.conditions 是否为 Ready=True。
  • 检查 status.lastAppliedRevision 是否与 Source 的 revision 一致。
  • 检查 status.inventory 中列出的资源是否与预期一致（特别是 MachineDeployment 的 spec 字段）。

# 检查 Kustomization 应用状态
kubectl get kustomization node-pool-prod -n flux-system -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# 检查最后应用的版本
kubectl get kustomization node-pool-prod -n flux-system -o jsonpath='{.status.lastAppliedRevision}'

2.4 Helm Controller：节点池附加组件的“版本管家”

Helm Controller 负责管理 Helm Chart 的完整生命周期。它根据 HelmRelease 资源中的定义，从 Helm 仓库拉取 Chart，渲染 values，然后执行安装、升级或回滚。

• 节点池场景： 节点池通常依赖一些附加组件，例如：
  • CNI 插件： Cilium、Calico。
  • 节点特性发现： Node Feature Discovery (NFD)。
  • GPU 驱动： NVIDIA Device Plugin。
  这些组件的版本和 values 通过 HelmRelease 声明式管理。节点池配置变更（如启用 DSR 模式）可能需要同步更新 Cilium 的 values。
• 巡检要点：
  • 检查 HelmRelease 的 status.conditions 是否为 Released=True。
  • 检查 status.lastAppliedRevision 和 status.lastReleaseRevision。
  • 检查 status.history 中的版本记录，确认没有意外的回退。

# 检查 HelmRelease 状态
kubectl get helmrelease cilium -n flux-system -o jsonpath='{.status.conditions[?(@.type=="Released")].status}'
# 查看当前部署的 Chart 版本
kubectl get helmrelease cilium -n flux-system -o jsonpath='{.status.lastAppliedRevision}'

2.5 Notification Controller：变更的“感知与通知”

Notification Controller 负责将 Flux 集群内部的事件（如 Source 更新、Kustomize 应用成功/失败、Helm 发布完成）转发到外部系统（Slack、Teams、PagerDuty、Webhook 端点）。它也支持通过 Receiver 接收来自 Git 仓库的 Webhook 事件，实现近实时的触发。

• 节点池场景：
  • 变更通知： 当节点池配置被成功应用后，自动发送通知到运维群。
  • 巡检告警： 当 Kustomize 应用失败（如 YAML 格式错误、资源冲突）时，立即触发告警。
  • 回滚验证： 回滚操作完成后，通过通知确认回滚是否成功。
• 巡检要点：
  • 检查 Alert 资源是否已配置并指向正确的 Provider。
  • 检查 Provider 的 status.conditions 是否为 Ready=True。
  • 检查 Receiver 的 Webhook 端点是否可达。

2.6 组件协作流程（节点池配置变更场景）

2.7 组件职责对比与巡检关注点