2. Kubecost 架构解析：Agent 模式与 Prometheus 集成、成本分配引擎、告警与洞察模块
Kubecost 的架构设计围绕“数据采集 → 成本分配 → 洞察与告警”三条主线展开。理解其内部组件关系，是进行安全基线水位压测与容量预测的前提。本章重点解析 Agent 模式、Prometheus 集成、成本分配引擎以及告警与洞察模块的核心机制。
2.1 部署模式：Agent 模式 vs. 完整模式
Kubecost 提供两种部署模式，生产环境推荐使用 Agent 模式以降低运维复杂度与资源开销。
| 特性 | 完整模式 (Full Mode) | Agent 模式 (Agent Mode) |
|---|---|---|
| 数据存储 | 自带 Prometheus + Thanos | 复用集群已有 Prometheus |
| 网络要求 | 需开放大量端口 | 仅需出站到 Kubecost API |
| 资源占用 | 较高（约 2-4 核 / 8-16 GB） | 较低（约 0.5-1 核 / 2-4 GB） |
| 升级维护 | 需同步升级 Prometheus | 仅升级 Agent 容器 |
| 适用场景 | 测试环境、无现有监控栈 | 生产环境、已有 Prometheus |
生产建议：Agent 模式下，Kubecost 不会在集群内写入数据，所有成本指标通过 gRPC 流式传输到 Kubecost SaaS 或自建后端，避免对现有 Prometheus 产生写入压力。
2.2 Prometheus 集成与数据流
Kubecost 依赖 Prometheus 作为指标数据源。无论是 Agent 模式还是完整模式，其核心数据流均遵循以下路径：
- Kube-State-Metrics：暴露 Pod、Node、Namespace 等资源状态。
- cAdvisor / kubelet：提供容器级别的 CPU、内存、网络、磁盘用量。
- Kubecost 成本模型 (Cost Model)：从 Prometheus 拉取原始指标，结合云供应商定价（AWS/GCP/Azure 价目表）计算每小时成本。
- Kubecost 前端 & API：聚合成本数据，生成仪表盘与告警。
2.3 成本分配引擎 (Cost Allocation Engine)
成本分配引擎是 Kubecost 的核心计算模块，负责将原始资源用量映射为可归因的成本。其分配逻辑遵循以下层级：
- 第一层：集群成本 — 按 Node 类型（实例规格、预留实例、Spot 实例）聚合。
- 第二层：命名空间成本 — 按 Namespace 聚合，支持标签（Label）与注解（Annotation）自定义分摊规则。
- 第三层：控制器成本 — 按 Deployment、StatefulSet、DaemonSet 等控制器聚合。
- 第四层：Pod 成本 — 最细粒度，按单个 Pod 的 CPU、内存、GPU、存储请求与用量计算。
关键公式：Pod 成本 = (CPU 请求占比 × 节点 CPU 成本) + (内存请求占比 × 节点内存成本) + 存储成本 + 网络成本。未使用资源（闲置成本）会单独标记，不摊入 Pod。
2.4 告警与洞察模块 (Alerting & Insights)
告警与洞察模块将成本数据转化为可执行的动作。Kubecost 内置了预定义的告警规则与优化建议，同时支持自定义告警。
| 模块 | 功能 | 示例 |
|---|---|---|
| 成本告警 | 基于预算阈值触发通知 | 命名空间成本超过预算 120% |
| 效率告警 | 识别资源浪费 | Pod CPU 请求超过实际用量 3 倍 |
| 安全告警 | 检测异常成本波动 | 单 Pod 成本突增 500% |
| 洞察建议 | 提供优化方案 | 建议将 5 个低负载 Pod 合并 |
2.5 关键组件总结
下表汇总了 Kubecost 各核心模块的职责与依赖关系，便于在压测沙盘中进行组件级故障模拟。
| 组件 | 职责 | 依赖 | 压测关注点 |
|---|---|---|---|
| Cost Model | 计算每小时成本 | Prometheus、云价目表 | CPU 与内存消耗、API 响应延迟 |
| Allocation API | 提供成本分配查询 | Cost Model 数据 | 查询并发数、缓存命中率 |
| Alerting Engine | 评估告警规则 | Allocation API | 规则评估周期、通知延迟 |
| Insights Engine | 生成优化建议 | 历史成本数据 | 分析耗时、建议准确率 |
注意：在安全基线水位压测中，需重点监控 Cost Model 的 OOM 风险。当集群规模超过 500 个 Node 时，建议启用 Agent 模式并调整 Prometheus 的采集间隔（默认 60s 可调整为 90s 以降低负载）。