2026 OpenCost 与 Kubecost 服务器租用配置手册：K8s 成本分摊采集量与留存怎么算 + 避坑全解

2026 OpenCost 与 Kubecost 服务器租用配置手册：K8s 成本分摊采集量与留存怎么算 + 避坑全解

决定磁盘的不是集群数，是每分钟样本数乘以留存天数

给成本分摊平台配服务器，绝大多数人先算的是「有多少个集群」，但真正决定磁盘和内存的是另外两个数——每分钟采集多少样本，以及这些样本要留多久；而「要留多久」又被财务口径而非技术口径决定。

这个错位在采购清单上表现得特别直白：需求栏写的是「3 个集群、每集群 200 个 pod、要看到每个 namespace 花了多少钱」，而配置栏的磁盘一项往往只能靠拍脑袋填。集群数在这条公式里几乎不出现，pod 数也只是间接变量，真正进公式的是抓取产生的样本速率与留存分钟数。集群数多只意味着这套东西要重复部署几份，它放大的是总量，不是单份的规格。

更要紧的是第二个数。留 15 天还是留 2 年，不是运维能单独拍板的事——它取决于财务要不要拿这些数据去做审计和对账。一旦留存被财务口径锁死在年这个量级，磁盘就从「一块盘」变成「一套存储架构」，选型逻辑完全变了。

本篇只围绕这一条链：把集群规模换算成每分钟样本数，把样本数乘以留存分钟数换算成磁盘，再按这个结果决定用单块持久卷还是走长期存储。它不是 FinOps 方法论科普，不是 OpenCost/Kubecost 的安装教程，也不是跟其他成本优化产品的横向对比。涉及的成本数字都给出假设条件与口径来源，口径不一致的地方会明确标出来。

OpenCost 在做什么：取单价、取分配、在 9003 端口暴露 Prometheus 指标

OpenCost 是开源的 Kubernetes 成本监控规范，2024 年 10 月 31 日进入 CNCF Incubating，开源核心由 IBM Kubecost 与社区维护。它的工作方式可以拆成三步：从云厂商价格 ConfigMap（或直接调用云账单 API）读取节点价格数据，从 kubelet 与 Kubernetes API Server 读取资源分配情况，然后在 9003 端口以 Prometheus 格式暴露指标。

这三步的开销差别很大。读价格是查表或偶尔调一次账单接口，读分配是访问本地 kubelet 与集群内的 API Server，两者都不是吃资源的活。真正开始吃资源发生在第三步之后：这些指标一旦被 Prometheus 抓走，就落进 TSDB，就开始按秒累积样本、按天累积磁盘。所以给这套系统配服务器，本质上是在给「它暴露出去的那些指标」配服务器。

分摊模型分三类：compute（CPU 加内存）、storage（PVC）、network（出向字节）。每个工作负载按资源请求量分摊节点成本，空闲成本按可配置规则分摊到活跃工作负载，或者归到专门的 __idle__ 命名空间。私有化环境则用自定义的「美元/CPU-小时」与「美元/GB 内存-小时」价格——这一条对自建机房的部署尤其关键，因为没有云账单 API 可调，单价必须自己填进 ConfigMap。

OpenCost 本身不保存数据，状态留在你自己的 Prometheus TSDB 里，公开资料称因此它的安全风险画像最低。这句话对容量规划的含义是：它没有自己的存储层，所以磁盘账不由它决定，而由承载它的那个 Prometheus 决定。你选多大一块盘，取决于那个 Prometheus 抓多少、留多久，而不是取决于装了哪个版本的 OpenCost。

由此可以得到本篇的第一个结论：成本分摊平台的服务器配置问题，落到硬件上是一个标准的时序数据库容量问题，只不过留存的时长被财务要求钉死了，不能像普通监控那样「留两周够了」。

核心指标清单与标签基数：几条序列是怎么被乘成几十万条的

OpenCost 暴露的关键指标包括 opencost_namespace_cost_total、opencost_workload_cost_total、opencost_cpu_cost、opencost_ram_cost、opencost_network_cost、opencost_storage_cost、opencost_load_balancer_cost、opencost_cluster_management_cost。

从类型上看，带 _total 后缀的两个是累计型口径，反映的是一段时间内的成本累计；cpu、ram、network、storage、load_balancer 这几个是分项成本，对应前面说的 compute / storage / network 三类分摊模型各自的结果；cluster_management_cost 是集群管理这一层的成本。加在一起，单个分摊对象大概对应六到八条序列。

序列数真正被放大的地方在标签维度上。namespace、workload、controller_kind 这三个维度构成一个笛卡尔积：假设 40 个命名空间、平均每个命名空间 6 个工作负载，就是 240 个 workload 组合，乘以每个组合六到八条序列，得到约 1,400 到 1,900 条。这个数字还不大，但自定义标签是纯乘数——每引入一个取值为 N 的新标签（比如 team、env、cost-center），最坏情况就把序列数乘以 N。加了两个各取 10 个值的自定义标签，1,900 条就变成 19 万条量级的上界。__idle__ 命名空间还会额外贡献一组序列。

还有一个判断值得写在这里：撑大样本量的往往不是这几个 OpenCost 指标本身，而是同一套 Prometheus 顺带抓取的节点与容器指标、以及 OpenCost 依赖的 kube-state-metrics 序列。这是基于 Prometheus 典型部署形态的判断，不是官方给出的比例，实际占比要用抓取指标自己量。

基数对磁盘的作用路径只有一条：序列数乘以每分钟抓取次数等于每分钟样本数，每分钟样本数乘以留存分钟数再乘以每样本字节数等于磁盘。标签基数管的是最左边那一项，它不直接吃内存，但它把后面两项一起放大了。

采集量怎么估：用 scrape_samples_post_metric_relabeling 量出每分钟样本数

Kubecost 官方给出的磁盘估算公式是 needed_disk_space = retention_time_minutes × ingested_samples_per_minutes × bytes_per_sample。三个变量里，留存分钟数是自己定的，每样本字节数官方给了区间，唯一需要现场度量的是中间那个「每分钟采集样本数」。

官方给出的度量口径是这一类表达式：sum(avg_over_time(scrape_samples_post_metric_relabeling[24h]))。这里有个容易算错的地方必须讲清楚：这个表达式度量的是「每次抓取落地的样本数」——对每个抓取目标在 24 小时窗口内取平均，再求和，得到的是单轮抓取的样本总量，不是每分钟的样本量。

要换算成公式需要的每分钟样本数，还要再乘一个系数：每分钟抓取次数，即 60 除以抓取间隔秒数。抓取间隔 60 秒时系数是 1，间隔 30 秒时系数是 2，间隔 15 秒时系数是 4。写成完整形式就是：每分钟样本数 ≈ sum(avg_over_time(scrape_samples_post_metric_relabeling[24h])) × 60 / 抓取间隔秒数。

如果集群里不同 job 配了不同抓取间隔，这个 sum 不能直接乘单一系数，要按 job 分组分别算再相加。混在一起算会把高频 job 的样本数按低频系数缩小，最后磁盘估小，是最常见的一种低估来源。

用 post_metric_relabeling 这个指标而不是抓取前的样本计数，也是刻意的选择：它统计的是 relabel 之后真正写进 TSDB 的样本，跟磁盘实际占用对得上。抓取前计数会把被丢弃的序列也算进去，拿它算磁盘会偏大。

抓取间隔还有一个配套的约束容易被忽略：抓取超时必须短于间隔，否则上一轮没结束下一轮就已经发起，抓取目标会被堆积的连接拖慢，样本速率反而失真。第三方示例里给出的 ServiceMonitor 配置是 interval 30s 配 scrapeTimeout 20s，超时占到间隔的三分之二；这是第三方示例配置，不是官方推荐值，但它说明了一个通用原则——间隔压短的时候，超时必须跟着压，否则压间隔换来的不是精度，是一堆超时样本。

度量还要挑对时间窗。用 24 小时窗口求平均，能抹平白天与夜间的差异，但也会把发布窗口那种短时峰值抹掉。而磁盘是按写入量算的，写入量看的是总量不是峰值，所以用日均反而是对的；内存和 CPU 才需要看峰值。这也是为什么本篇在磁盘这条链上一直用平均速率，在内存那条链上才谈峰值。

需要声明口径：上面所有数字都是换算方法与假设，不是实测值。真实集群的序列数取决于你启用了哪些 exporter、保留了哪些标签、有没有开网络计费采集，必须先量再算。量出来的数如果跟后面 32 GB 那个锚点对不上，以量出来的为准。

磁盘账两次演算：官方 10 万样本/分钟 × 15 天 ≈ 40 GB 的完整展开

先看官方给的两个数：Prometheus 平均每样本约 1.5 到 2 字节；每分钟采集 10 万个样本、留存 15 天，大约需要 40 GB。把这两个数代进同一个公式会发现它们对不上，而这个对不上恰恰是最值得算清楚的一件事。

演算一，按每样本 1.5 到 2 字节的口径。15 天等于 21,600 分钟，乘以每分钟 10 万个样本，总样本数是 2.16 × 10⁹ 个。按 1.5 字节算是 3.24 × 10⁹ 字节，约 3.0 GiB；按 2 字节算是 4.32 × 10⁹ 字节，约 4.0 GiB。也就是说，按压缩后的裸样本口径，这个量级只需要 3 到 4 GiB。

演算二，按官方 40 GB 例子反推的口径。40 GB 除以 2.16 × 10⁹ 个样本，反推出每样本的有效成本约 18.5 字节（若按 GiB 计则接近 20 字节）。这比 1.5 到 2 字节高出一个数量级，差额来自索引、block 元数据、compaction 期间的双重占用、head block 与 WAL 这些裸样本之外的开销。两次演算差 10 倍上下。

选型时该用哪个？用演算二。原因是磁盘估小的代价是 Prometheus 直接写满、抓取停止、账单断档，估大的代价只是多付一块盘的钱。前面提到的 20 到 30% 余量就是在这个基础上再叠加的，官方明确说这部分留给 headroom 与 WAL：WAL 是崩溃恢复用的预写日志，进程异常退出时要靠它回放出没落进 block 的数据；headroom 则要覆盖 compaction 合并期间新旧 block 同时存在的那段时间，以及查询时的临时空间。40 GB 乘以 1.2 到 1.3，实际采购口径是 48 到 52 GB。

再往下推一个具体场景，把两个杠杆的量级摆出来。假设某集群相关序列共约 12 万个（这是假设值，需按上一节的方法实量）：抓取间隔 60 秒时每分钟 12 万样本，15 天留存按 18.5 字节算是约 48 GB，加余量 58 到 62 GB；间隔压到 30 秒，样本速率翻倍，15 天就是约 96 GB，加余量 115 到 125 GB。留存从 15 天提到 30 天，同样翻倍。抓取间隔和留存天数这两个数，对磁盘的作用是等比例相乘的。

如果按第三方口径把成本数据留到 2 年，2 年等于 1,051,200 分钟，是 15 天的约 48.7 倍。同样 12 万序列、60 秒间隔，磁盘需求从 48 GB 推到约 2.3 TB；30 秒间隔则接近 4.7 TB。这个量级已经不是「换块大盘」能解决的了，这就是官方那条 30 天上限的由来。

三套部署形态的资源画像与选型确认项

同一套成本分摊逻辑，在不同部署形态下压在服务器上的资源完全不同。下面这张表按维度横向对比，左边三列是官方产品对比页给出的口径，右边两列是把这些口径翻译成资源与选型动作之后的判断。

留存的架构分界：30 天这条线，以及主集群与从集群的资源画像

Kubecost 官方有一条说得很硬的口径：较大的集群不应在 Prometheus 里存超过 30 天的数据，长期留存要走启用持久存储的 Kubecost（Thanos 一类方案）。这条线的背后不只是磁盘大小的问题。单实例 TSDB 上的数据越多，compaction 要处理的 block 就越多，崩溃后的 WAL 回放时间越长，跨长时间范围的成本聚合查询要扫的数据量也越大——磁盘只是最先到的那个瓶颈，不是唯一的一个。

30 天这条技术上限跟财务口径的冲突，是这套系统最典型的一处结构性矛盾。有一份第三方技术资料提出：成本数据的留存要求与指标、日志、追踪不同，后者通常 30 到 90 天，而成本数据因财务审计需要通常要 2 年；该资料还引用 FinOps Foundation 的 Inform、Optimize、Operate 三阶段，指出 Inform 阶段本质上是一个可观测性问题。必须写明：这是第三方口径，不是 OpenCost 或 Kubecost 的官方要求，是否适用要以你自己所在主体的财务与审计要求为准。

如果确实要往年这个量级走，架构就得换。Thanos 一类方案进来之后，Prometheus 本地只保留短周期数据，历史 block 上传到对象存储，查询侧再从对象存储拉回。这时候集群的角色第一次出现了分化。

主集群的资源画像是「重」的：它要拉取指标、要跑聚合、要承担跨集群的查询扇出，本地盘和内存都要按最大口径留。从集群的画像则轻得多——官方口径明确只有主集群拉取指标，Thanos sidecar 可以让从集群缩减资源。换句话说，从集群那台服务器不再需要为「留存」付磁盘的钱，只需要为「抓取后上传」付一段带宽和一小块本地缓冲。

这个分化给采购带来一个很实际的推论：多集群部署下，不要给每个集群按同一份规格下单。先定哪个是主集群，主集群按完整口径配，从集群按短留存加上传带宽配，总成本会明显低于「每个集群都配一份 15 天盘」的做法。

默认那块 32 GB 盘意味着什么，以及到什么点必须重算

Kubecost 默认安装是 32 GB 持久卷加 Prometheus 指标 15 天留存，官方称这个容量大约够留存约 300 个 pod，官方同时加了限定语：视具体节点数与容器数而定。这个 300 是本篇最有价值的一个锚点，因为它是官方唯一把「业务规模」和「磁盘容量」直接连起来的数字。

把它换算成样本速率，就得到一个可以跟实测量直接对比的阈值。按前面演算二反推出的每样本约 18.5 字节口径，32 GB 除以 21,600 分钟再除以 18.5 字节，约等于 8 万样本每分钟。这是按官方例子反推出来的推算值，不是官方给出的数字，但它给出了一个可操作的判断线：实测量接近 8 万样本每分钟时，那块 32 GB 盘就已经在边缘上了，还没算任何余量。

由此可以列出明确的重算触发点，命中任意一条就应该重新走一遍公式，而不是继续等告警：实测每分钟样本数接近或超过 8 万；pod 数达到或超过 300 这个官方锚点；抓取间隔被调短（从 60 秒到 30 秒等于样本速率翻倍，等效于 pod 数翻倍）；留存天数从 15 天往上调；引入新的自定义标签导致序列数成倍增长；开启网络计费采集这类高基数数据源。

这里还有一处容易忽略：官方说的「约 300 个 pod」带着「视具体节点数与容器数而定」这个限定语，意思是 pod 数只是代理指标，真正的自变量是序列数。两个 pod 数相同的集群，一个开了网络计费采集、一个没开，实际样本速率可以差出好几倍。所以触发点里凡是能实量的，都优先用实测量，别用 pod 数反推。

重算之后如果结论是「盘要加大」，还有一件事要顺带确认：持久卷能不能在线扩容，以及扩容过程中 Prometheus 是否需要停机。成本分摊平台的盘扩不上去，表现不是变慢，而是抓取直接失败、账单断档，且这段断档事后补不回来。把扩容窗口和恢复演练当成同一件事来准备，比单独挑一个深夜扩盘要稳妥得多。

内存与 requests/limits：为什么官方建议先跑满七天再调

官方的建议很具体：上生产规模前必须先设置或更新资源 requests 与 limits；具体取值取决于集群规模、可用性要求与产品用法，可以先在页面上查看建议值；最佳实践是先在生产集群跑满七天，再按实际消耗调整 requests/limits。

七天这个窗口长度不是随手定的，换成三天或一天都不够：七天覆盖了一个完整的周周期，工作日与周末的负载差异、批量任务的周期、发布窗口的峰值都能被包含在观测窗口里；同时这个长度也够 TSDB 完成若干轮 block 切分与 compaction，让内存占用从「冷启动爬坡」进入稳定态。在爬坡期取到的数值去配 limits，几乎一定会配小。

Prometheus 侧的内存占用主要由几块构成：常驻内存的 head block，它装的是最近一段时间尚未落 block 的数据，其大小随每小时新增序列数与样本速率增长（具体默认时长需以实际版本文档为准）；崩溃恢复用的 WAL；以及查询时的扇出——一次跨长时段的成本聚合查询会把大量数据点同时拉进内存。这三项决定了内存需求跟「留存天数」的关系不大，跟「样本速率」和「查询并发」的关系很大。这是本篇要强调的第二处错位：磁盘跟着留存天数走，内存跟着样本速率走。

有一份第三方部署示例给出了 OpenCost exporter 的资源边界：limits cpu 1000m、memory 1Gi，requests cpu 200m、memory 256Mi，并给出了 ServiceMonitor 的 interval 30s、scrapeTimeout 20s 这类抓取配置，以及自定义定价 ConfigMap 中的 CPU、RAM、storage、zoneNetworkCost、loadBalancerCost 等单价字段。必须写明：这是第三方示例配置，不是官方推荐值，只能当作量级参考，不能直接照抄进生产。真正该抄的是官方那条方法论：先跑七天，再按实际消耗调。

资源爆炸的几个常见来源值得单独列出来，因为它们都能在几天内把一台机器吃干净。网络计费采集是头号来源，出向流量按来源与目标维度展开，基数增长远快于 CPU 与内存指标；抓取间隔过密直接等比例放大样本速率与内存占用；标签基数过高把序列数乘以标签取值数；此外还有大范围聚合查询的扇出，以及重启后的 WAL 回放峰值。

还有一个部署层面的坑：集群里若已在默认端口运行 node exporter，Kubecost 捆绑的 node exporter 可能一直处于 Pending 状态，白白占着一份调度额度。官方给出的处置方式是通过 Helm 配置把 prometheus.nodeExporter.enabled 与 prometheus.serviceAccounts.nodeExporter.create 设为 false，复用既有 DaemonSet，前提是那个端点在 Kubecost 所在命名空间可见。

Prometheus pod 重启一次就清零：对演练与备份的要求

官方明确：可以用 Helm 参数关闭持久卷部署，但一旦 Prometheus server pod 重启，除非启用 Thanos 或其他长期存储，所有历史账单数据都会丢失。这句话对普通监控系统来说只是「图断了」，对成本分摊平台来说性质完全不同。

差别在于数据的可重建性。CPU 使用率丢一天，最多是排查问题时少一段曲线；成本数据丢一天，当月的部门分摊、对外的计费、跟财务的对账就都缺了一块，而且这部分数据无法从别处补回来——节点价格来自账单 API，分配来自当时的 API Server 状态，两者都不可能事后完整复现。成本数据是不可重建数据，这是它跟一般监控指标最本质的区别。

由此提出的演练要求就不是形式化的了。第一，必须做一次真实的重启演练来验证持久卷是否真的生效，而不是看一眼 Helm values 里有 persistence 就认为安全；常见的翻车点是实际落到了 emptyDir，yaml 上有配置、物理上没盘。第二，要确认持久卷所属的 StorageClass 与回收策略，避免节点或卷被回收时数据跟着走。第三，备份要覆盖 Prometheus 数据目录，而且必须是能做时间点恢复的备份，不是单纯拷文件。

第四点最容易被漏掉：备份范围里还要包含自定义定价 ConfigMap。私有化环境中单价是自己填的「美元/CPU-小时」与「美元/GB 内存-小时」，如果只恢复了指标而单价配置丢了，历史样本还在，但重算出来的金额跟当初报出去的对不上。第五，恢复演练的验收标准要定成「账单能回到同一时间点且金额一致」，而不是「进程起来了、页面能打开」。

把这些要求摆在一起看，结论其实很直接：如果财务口径要求留存超过 Prometheus 能舒服承载的范围，那么长期存储不是可选项，而是备份策略能否成立的先决条件。靠本机持久卷加定期快照去扛年量级的成本数据，演练成本会高得离谱。

什么时候该上带长期存储的方案，什么时候开源核心够用

开源核心够用的边界可以画得很清楚：集群数量少、且不需要跨集群统一视图；单个集群 pod 数在 300 这个官方锚点以内，或实测每分钟样本数明显低于 8 万；留存需求在 15 天以内，或者虽然超过 15 天但仍在官方说的 30 天以内且集群不算大；团队能自己维护 Prometheus 与 kube-state-metrics；不需要 SSO/SAML/RBAC/OIDC 这类访问控制；成本数据不进财务审计流程。这几条同时成立时，用开源核心加自建 Prometheus 是最省事的选择，多出来的运维成本低于企业级功能带来的收益。

该上带长期存储方案的信号同样具体：需要统一的多集群视图，而官方口径里统一视图只在企业级套餐提供；留存要求超过 30 天，这是官方明确划的线；需要 SSO/SAML/RBAC/OIDC，官方口径里这些只在企业级套餐受支持；需要自定义定价；集群数量多且希望把从集群的资源压下来，官方口径里只有主集群拉取指标、Thanos sidecar 可让从集群缩减资源；成本数据要进审计与对账流程，丢失不可接受。命中任意一条，就该把长期存储当成架构的一部分来设计，而不是当成一个后续加装件。

前面提到的第三方口径可以作为留存的参考输入，但要摆对位置：那份资料提出指标、日志、追踪通常 30 到 90 天，成本数据因财务审计通常要 2 年，并引用 FinOps Foundation 的 Inform、Optimize、Operate 三阶段指出 Inform 阶段本质是可观测性问题。这是第三方口径，不是官方要求，引用它的正确方式是拿去跟自己的财务部门确认留存年限，而不是直接当成配置依据写进采购单。

把这两组边界叠起来会发现一个有用的判断顺序：先看留存要求，因为它决定架构；再看是否需要统一视图与访问控制，因为它决定套餐；最后才看样本速率，因为它决定具体的盘与内存规格。顺序反了容易出现在错误架构上精算磁盘的情况——算得很准，但架构从一开始就选错了。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。对这类成本分摊负载，我们会先把留存年限与样本速率这两个数问清楚，再谈机型，因为这两个数决定了该配一块大盘还是该配一套本地盘加对象存储的混合结构。

OpenCost 与 Kubecost 的采集账，贵在抓取还是贵在留存

把三个阶段的花费摆在一起看，答案偏向留存那一侧，而且偏向得很明显。抓取侧的成本可以压：放宽抓取间隔，样本速率按比例下降；用 relabel 丢掉不需要的标签，序列数直接减少；关掉网络计费这类高基数数据源，能砍掉一大块。这些手段的代价是精度下降，但精度是可以跟业务商量着让步的。

留存侧的成本压不动。留 2 年就是留 2 年，财务口径不会因为磁盘贵就改成留半年；而它对磁盘的作用是严格线性的，前面算过，15 天到 2 年是 48.7 倍。更麻烦的是留存不只吃磁盘，它还决定了架构：30 天以内可以留在单实例 TSDB，超过这条线就要引入对象存储、sidecar、压缩与查询聚合这一整套东西，复杂度跳了一级。

再精确一点说：抓取侧决定的是内存与 CPU 峰值，因为样本速率决定 head block 大小、WAL 写入速率和抓取时的解析开销；留存侧决定的是磁盘与架构，因为总样本量决定盘要多大、历史要不要下沉。两台配置相同的机器，一台因为抓取太密而 OOM，一台因为留存太久而磁盘写满，处置方式完全不同——前者调间隔与标签，后者换架构。

所以如果只能先算一个数，先算留存天数。它是这套系统里唯一一个不由技术团队决定、却决定技术架构的变量。样本速率可以上线后实测再调，集群数可以逐步增加，唯独留存年限在第一次跟财务开会时就已经被定死了，而它一个人就决定了后面所有的选型。

一万网络给成本分摊平台的存储配置口径

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。针对 Kubernetes 成本分摊这套负载，我们的配置口径是把磁盘的容量与 IO 排在第一位，其次才是核数与内存，并且优先确认历史数据是否要下沉到对象存储——因为这套负载最贵的一笔账不在算，而在存。

来沟通配置时，建议先把四个数字准备好：实测的每分钟样本数（用 sum(avg_over_time(scrape_samples_post_metric_relabeling[24h])) 量出来再乘以 60 除以抓取间隔秒数）、留存天数、pod 数与序列数、抓取间隔。有这四个数，按本篇的公式就能推出磁盘口径，机型选型就有了依据，而不是靠经验拍脑袋。机型、带宽与报价需实时询价，以官网实时信息为准。

最后提醒一句容易被忽略的事：这套平台的网络需求不在出口带宽上，而在承载它的服务器到被管集群、以及到对象存储这两段链路的稳定性上。抓取丢一轮，成本曲线上就是一个洞；上传断一段，对象存储里的历史 block 就缺一块。选型时该问的是这两段链路的时延与丢包，而不是带宽的数字大小。