3. 平台架构总览：校准平台整体架构、核心模块划分、与Kubernetes API交互方式

资源配额校准平台并非一个单体应用，而是一套围绕 “声明式配额定义 → 持续差异检测 → 自动修正 → 审计闭环” 设计的微服务与控制器组合体。本章从宏观视角拆解平台的骨架、模块职责以及它与 Kubernetes API 的通信模式，为后续章节的模块级实战打下基础。

3.1 整体架构分层

平台采用经典的四层架构：接入层、控制层、数据层 和 Kubernetes 集群层。每一层职责清晰，层间通过 gRPC 或 RESTful API 解耦。

3.2 核心模块划分

平台内部按功能边界拆分为 6 个核心模块，每个模块可独立部署、独立扩缩容。下表列出模块名称、职责与关键依赖：

3.3 与 Kubernetes API 的交互方式

平台与 Kubernetes API 的交互遵循 “只读监听 + 条件写入” 原则，避免对集群造成不必要的写压力。具体采用以下三种模式：

1. List-Watch 模式（差异计算器）
   通过 client-go 的 Informer 机制，监听所有命名空间的 ResourceQuota 和 LimitRange 对象变化。本地维护一份增量缓存，差异计算器直接从缓存读取，不反复请求 API Server。
2. 条件写入模式（自动修正控制器）
   仅在差异计算器报告“期望值与实际值偏差超过阈值”时，才发起 PATCH 或 PUT 请求。写入前先通过 resourceVersion 做乐观锁校验，防止并发覆盖。
3. Webhook 模式（准入校验）
   平台可选部署 MutatingWebhookConfiguration，在 Pod 创建或 ResourceQuota 更新时拦截请求，校验配额声明是否与基线一致。此模式为“防御性”交互，非核心路径。

3.4 关键交互代码片段

以下代码展示差异计算器如何使用 client-go 的 Informer 监听 ResourceQuota 对象，并计算与基线配额的差异：

// 使用 Informer 监听所有命名空间的 ResourceQuota
factory := informers.NewSharedInformerFactory(clientset, 0)
informer := factory.Core().V1().ResourceQuotas().Informer()

informer.AddEventHandler(cache.ResourceEventHandlerFuncs{
    AddFunc: func(obj interface{}) {
        quota := obj.(*corev1.ResourceQuota)
        diff := calculateDiff(quota, baselineQuota)
        if diff.HasDeviation() {
            reportQueue.Add(diff)
        }
    },
    UpdateFunc: func(oldObj, newObj interface{}) {
        newQuota := newObj.(*corev1.ResourceQuota)
        diff := calculateDiff(newQuota, baselineQuota)
        if diff.HasDeviation() {
            reportQueue.Add(diff)
        }
    },
})

stopCh := make(chan struct{})
factory.Start(stopCh)
factory.WaitForCacheSync(stopCh)

3.5 架构设计决策总结