📚 课程目录第2章 Kubecost部署架构与安装规划

2. Kubecost部署架构与安装规划

Kubecost 并不是一个“装完就能看账单”的单体应用，它本质上是一套围绕 Prometheus 指标构建的成本可观测系统。理解它的部署架构，是后续做成本分摊、预算告警和资源优化建议的前提。如果架构关系没理清，常见的结果是：前端能打开，但成本数据为空；或者成本模型组件反复重启，导致分摊结果时有时无。

一、四个核心组件与数据流向

Kubecost 的部署可以拆成四个角色，它们之间是明确的“采集—存储—计算—展示”链路：

Prometheus（指标存储）：Kubecost 自身不采集容器指标，它依赖 Prometheus 抓取 kube-state-metrics、cAdvisor、node-exporter 等指标。Kubecost 通过 PromQL 查询这些指标来计算 CPU、内存、GPU、存储和网络成本。因此 Prometheus 是整条链路的“数据底座”。
Kubecost 前端（Frontend / cost-analyzer）：提供 Web UI 和 API，负责展示成本总览、命名空间分摊、工作负载明细、节省建议等。它本身不存储原始指标，而是向 Prometheus 发起查询，并结合成本模型组件的结果做聚合。
成本模型组件（cost-model）：这是 Kubecost 的计算核心。它周期性地从云厂商账单 API（如 AWS CUR、GCP Billing、Azure Cost Management）或自定义价格表拉取真实价格，再与 Prometheus 中的资源用量做匹配，生成每小时、每天的成本分摊结果。它还会计算节点价格、PV 价格、网络出流量价格等。
Kubecost 自身存储（可选）：用于保存成本模型的历史结果、预算配置、告警状态等。小规模场景可用内置的 SQLite 或本地 PV；生产环境建议使用外部 PostgreSQL 或对象存储，避免 Pod 重建后历史数据丢失。

四者的关系可以用下面的架构图表示。注意箭头方向代表数据或查询的流向，而不是简单的调用顺序。

二、网络与存储要求

Kubecost 对网络的要求集中在“出站访问”和“集群内互通”两方面。出站方面，cost-model 需要访问云厂商账单 API（如 AWS Cost Explorer、GCP Cloud Billing API），如果集群出站受限，需要配置 NAT 网关或代理，否则只能使用自定义价格表，成本精度会下降。集群内互通方面，前端需要访问 Prometheus 的 Service（通常是 prometheus-server 或 prometheus-kube-prometheus-prometheus 的 9090 端口），cost-model 也需要访问同一地址。如果 Prometheus 部署在独立命名空间，要确保 NetworkPolicy 允许跨命名空间访问。

存储方面，Kubecost 自身需要持久化三类数据：成本模型的历史结果、预算与告警配置、以及前端的一些状态。默认安装会使用一个较小的 PVC（约 32Gi）配合 SQLite。但在生产环境中，建议做两点调整：第一，将 Kubecost 的存储后端切换为外部 PostgreSQL，避免 Pod 重建导致历史成本丢失；第二，如果集群规模较大（节点数超过 50 或 Pod 数超过 5000），Prometheus 的存储和内存需求会显著上升，需要单独规划 Prometheus 的 PVC 大小和 retention 周期。一个常见的经验值是：每 1000 个活跃 Pod，Prometheus 每天约产生 2～4GB 的指标数据，retention 设为 15 天时，PVC 至少预留 60GB。

三、Helm 安装与验证

Kubecost 官方推荐使用 Helm 安装。以下是一个面向自建 Prometheus 场景的示例 values 片段，假设 Prometheus 已存在于 monitoring 命名空间，Service 名为 prometheus-server，端口 9090：

# kubecost-values.yaml（示例，需按实际环境调整）
global:
  prometheus:
    enabled: false          # 不安装内置 Prometheus
    fqdn: http://prometheus-server.monitoring.svc.cluster.local:9090

prometheus:
  server:
    retention: 15d

costModel:
  # 云厂商账单集成，以 AWS 为例
  aws:
    enabled: true
    accessKey: ""
    secretKey: ""
    # 建议使用 IRSA 或服务账号，而非静态密钥

persistentVolume:
  enabled: true
  size: 32Gi
  storageClass: "standard"

# 若使用外部 PostgreSQL
# kubecostProductConfigs:
#   postgresql:
#     enabled: true
#     host: "pg.example.internal"
#     port: 5432
#     database: "kubecost"
#     username: "kubecost"
#     password: "<secret>"

安装命令如下：

helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm repo update

helm upgrade --install kubecost kubecost/cost-analyzer \
  --namespace kubecost --create-namespace \
  -f kubecost-values.yaml

安装完成后，验证分三步。第一步，检查 Pod 状态：

kubectl get pods -n kubecost

正常情况下应看到 kubecost-cost-analyzer-xxx、kubecost-prometheus-server-xxx（若启用内置 Prometheus）、kubecost-cluster-controller-xxx 等处于 Running 状态。第二步，检查 cost-model 日志中是否成功拉取价格：

kubectl logs -n kubecost deploy/kubecost-cost-analyzer -c cost-model | grep -i "price\|billing"

如果日志中出现 failed to fetch pricing 或 no cloud integration，说明账单 API 未配置成功，此时成本数据会回退到默认价格表，精度下降。第三步，访问前端并检查数据：

kubectl port-forward -n kubecost svc/kubecost-cost-analyzer 9090:9090

浏览器打开 http://localhost:9090，进入 Cost Allocation 页面。如果能看到按命名空间或工作负载拆分的成本曲线，且数值随时间变化，说明整条链路已打通。如果页面显示 “No data” 或成本为 0，优先检查 Prometheus 中是否存在 container_cpu_usage_seconds_total 和 kube_pod_container_resource_requests 这两类指标。

验证时建议先看“集群总成本”是否非零，再看“命名空间分摊”是否有数据。如果总成本为零，问题通常出在价格拉取或 Prometheus 查询；如果总成本正常但分摊为空，问题通常出在 kube-state-metrics 的标签缺失或命名空间过滤配置。

四、安装规划中的常见取舍

在实际规划时，有三个决策点值得提前确认。第一，是否复用现有 Prometheus。复用可以节省资源，但要求现有 Prometheus 的 retention 和抓取配置满足 Kubecost 的查询需求；独立部署则更可控，但会增加约 2～4GB 内存和相应存储开销。第二，是否启用云厂商账单集成。启用后成本精度最高，但需要配置访问凭证和网络出站；不启用则只能依赖默认价格表，适合测试环境。第三，存储后端选 SQLite 还是 PostgreSQL。单集群、小规模场景用 SQLite 足够；多集群或需要长期保留历史数据时，PostgreSQL 是更稳妥的选择。

把这些关系理清后，Kubecost 的安装就不再是“跑一条 Helm 命令”，而是一次有明确输入、明确依赖和明确验证标准的部署工程。后续做成本分摊和优化建议时，也能快速定位问题出在采集、计算还是展示环节。