这两年接到的咨询里，有一类问题问得越来越具体：「我们三台 8 核 16G 的机器，装完 KubeSphere，业务还能跑几个 Pod？」问这话的人通常已经踩过一次坑——机器看着不小，装完 KubeSphere 打开控制台一看，资源水位就下去了大半，业务 Pod 调度进去没几个就开始 Pending。
问题出在算账方式上。KubeSphere 不是「Kubernetes 加个界面」，它是在 K8s 之上又叠了一整套可观测（监控、告警、日志、审计、事件、通知）、DevOps、应用商店和服务网格。这套东西是固定开销——你跑 3 个业务 Pod 还是 300 个，OpenSearch 该吃多少内存还是吃多少。照「业务负载 × 单 Pod 资源」的老办法估机器，必然翻车。
本文把这笔账拆成四本：可观测组件账、时序与日志磁盘账、镜像仓库账、节点规划账。先说结论：
先厘清一件事。原生 Kubernetes 的控制面很轻：kube-apiserver、kube-controller-manager、kube-scheduler、etcd，加上每节点的 kubelet、kube-proxy 和 CNI 插件。一台 2 核 4G 的机器跑一个单节点 K8s 绰绰有余，剩下全是业务的。
KubeSphere 从 v4 开始把功能拆成了「扩展组件」，可观测这一块叫 WizTelemetry 可观测平台（v4.1 版本叫 WhizardTelemetry）。你以为装的是一个平台，实际上拉起来的是一串：
WizTelemetry 平台服务——所有可观测扩展共用的后端 APIServer，是常驻进程。数据流水线——负责采集、转换、路由可观测数据，底层是 Vector（v4.1.2 时升级到 0.39.0），以 DaemonSet 形式跑在每个节点上。OpenSearch 分布式检索与分析引擎——KubeSphere 默认的日志接收器，日志、审计、事件、通知历史全往里塞，这是整个可观测栈里最重的一个。日志、事件、审计三个扩展各自占用一份资源，可以对接 OpenSearch、Elasticsearch、Kafka，也可以换成 Loki。监控——底层是 Prometheus Operator + Prometheus + Thanos + kube-state-metrics + node-exporter，v4.1.2 版本对应 Prometheus 2.51.2、Operator 0.75.1、kube-state-metrics 2.12.0、node-exporter 1.8.1、Thanos 0.36.1。告警基于 Alertmanager，通知单独一个服务，全局监控做跨集群聚合。往上还有网络可观测（eBPF）、链路追踪（OpenTelemetry）、Grafana、Grafana Loki、Grafana Alloy、Grafana Tempo 可选。
数一下就明白了：这套东西加起来十几二十个 Pod，还都是有状态、需要持久化卷的那种。它们不是「业务起来才占资源」的弹性负载，是开机就在那儿吃着的底座。
官方给的环境要求其实已经暗示了这一点：最低要求每节点 CPU 2 核、内存 4GB、硬盘 40GB；生产环境要求每节点 CPU 8 核、内存 16GB、硬盘 200GB。注意「每节点」三个字——这是 KubeSphere 摊到集群里算的，但真实情况是这些组件集中在少数几台机器上，不会均匀分摊。你在 3 节点集群上开全组件，很可能 10GB 以上的内存是被两三个节点上的可观测 Pod 吃掉的。
这笔账要一个组件一个组件算，不能拍脑袋说「可观测大概 8G」。
OpenSearch 是 JVM 应用，内存分两块：JVM heap 和堆外的文件系统缓存。KubeSphere 默认部署的 OpenSearch，单节点 heap 一般给到 2–4GB，容器内存 limit 要给到 heap 的 2 倍左右（预估），也就是 4–8GB。想让它跑得动 7 天以上的日志检索，4GB heap / 8GB limit 是比较现实的起点。
更要命的是它不随业务量线性变化。你集群里 5 个 Pod 每天产 1GB 日志，和 50 个 Pod 每天产 10GB 日志，OpenSearch 进程本身的常驻内存差别不大，变的只是磁盘。这就是小集群里「可观测比业务还重」的根源——固定成本没摊薄。
Prometheus 的内存消耗主要跟活跃时序数挂钩，行业经验值是每 100 万条活跃时序约 2–4GB 内存（预估）。一个开了全套监控的 5 节点 KubeSphere 集群，活跃时序通常在 10–30 万条（预估，取决于 kube-state-metrics 暴露了多少对象和 cAdvisor 的容器指标量），对应 1–2GB 内存；把节点数加到 20、Pod 数上到几百，时序破百万，内存就要 4GB 往上。Thanos 的 sidecar/query 再各占几百 MB 到 1GB（预估）。
Vector（数据流水线）以 DaemonSet 跑，每节点 50–200MB 内存、0.1–0.5 核（预估），日志量大时会往上限走。node-exporter 每节点 20–50MB，可以忽略。kube-state-metrics 是按对象数涨的，1000 个 Pod 规模约 200–400MB（预估）。
审计和事件本身是轻量服务，但它们的数据落到 OpenSearch 里，占用的是 OpenSearch 那份资源。告警（Alertmanager）、通知服务、平台服务 APIServer 三个加起来 1–2 核、2–4GB 内存（预估）是常态。
汇总一下，按集群规模给个固定开销的估算区间（均为预估，实际以 kubectl top pod -A 实测为准）：
所以算机器的时候，正确的顺序是先扣掉组件开销，剩下的才是业务能用的。一台 8 核 16G 的机器，扣掉 K8s 系统组件（约 1 核 1.5GB）和可观测摊到这台的部分（3 节点集群里约 1.5–2 核、4–5GB），真正能调度给业务 Pod 的大概是 4–5 核、9–10GB。这个数字跟你直觉里的「16G 内存能跑十几个 Pod」差得远。
Prometheus 官方文档给了明确的估算方法：每个样本平均只占 1–2 字节，容量公式为
needed_disk_space = 保留秒数 × 每秒摄入样本数 × 每样本字节数
套个具体场景。10 万条活跃时序、采集间隔 30 秒：每秒摄入样本数 = 100000 ÷ 30 ≈ 3333 条。保留 15 天 = 1296000 秒。按 2 字节/样本算：3333 × 2 × 1296000 ≈ 8.6GB。保留 30 天就是 17.3GB，保留 90 天 51.8GB。
再看一个更容易翻车的配置：50 万条时序、采集间隔 15 秒、保留 30 天。每秒样本数 = 500000 ÷ 15 ≈ 33333 条，33333 × 2 × 2592000 ≈ 172.8GB。从 8.6GB 到 173GB，差别全在「时序数」和「采集间隔」这两个变量上——把间隔从 30s 压到 15s 是双倍，时序数涨 5 倍是五倍，乘起来就是十倍。
这里有个必须记住的坑：retention.size 不要设成磁盘满格。官方文档建议 retention.size 最多设为分配给 Prometheus 的磁盘空间的 80–85%，剩下 15–20% 留给 compaction 的临时空间——压缩时源块和新块会同时存在磁盘上。另外 WAL 和 chunks_head 目录每 2 小时达到一次峰值，这部分也要算进「磁盘最低要求」。
还有一个冷知识但很致命：Prometheus 的本地存储不支持 NFS 这类非 POSIX 兼容的文件系统，会损坏且不可恢复。给 Prometheus 挂网络存储盘，等于给自己埋雷。
日志量的算法是另一套。先估原始日志：假设 20 个 Pod，每 Pod 每秒 20 行、每行 200 字节，那就是 20 × 20 × 200 = 80000 字节/秒 ≈ 80KB/s，一天 6.9GB。这个量在微服务里算中等偏下，一个开了 DEBUG 级别的 Java 服务轻松超过它。
原始日志写进 OpenSearch/Elasticsearch 之后会膨胀，索引后的体积通常是原始日志的 1.1–1.5 倍（预估，行业经验值，取决于分词字段、是否存 _source、是否开 doc_values）。取中位 1.3 倍，6.9GB 原始日志变成约 9GB 索引。
再算副本。OpenSearch 索引默认带 1 份副本的话，存储直接 ×2。于是：
看到没，日志侧的数字比监控侧大一个数量级。一个 5 节点集群，监控盘给 30GB 挺宽裕，日志盘给 200GB 可能半个月就见底。
这两块盘写满的表现不一样，但都不好受。OpenSearch 在数据节点磁盘水位超过阈值时会把索引置为只读（read_only_allow_delete），日志停止写入——业务还在跑，但你看不到任何新日志；严重的时候索引分片会变成未分配状态，检索也挂。Prometheus 的 TSDB 满了则直接停止采集，监控曲线变成一条直线，告警自然也不会触发（因为没有数据可评估）。
说白了，磁盘写满的时候 KubeSphere 那套漂亮的控制台会「还活着但瞎了」——页面能开，数据全是旧的，你以为没事，其实已经瞎跑半天了。
所以我的建议很直接：可观测数据必须独立盘、独立 PVC 配额，不要和业务 Pod 共用一块盘或同一个 StorageClass 的默认卷。共用盘的下场是日志把盘写满，业务 Pod 的 PVC 一起遭殃，从「看不见」升级成「挂了」。
Harbor 官方给的最低配置是 2 核 CPU、4GB 内存、40GB 磁盘，推荐配置是 4 核、8GB、160GB。这个「最低」跟 KubeSphere 的「最低」一样，属于能装起来、能演示的水平。真要点开 Trivy 漏洞扫描、多人并发 push、存多架构镜像，4GB 内存很容易吃紧。
小团队的现实起点应该是4 核、8GB、独立 160GB SSD。注意「独立」两个字——Harbor 的 /data 目录要单独一块盘，跟系统盘分开。原因在下面。
Harbor 的镜像存储是分层共享的。你在界面上删掉一个 tag，或者删掉整个仓库，这只是软删除——把「这个 tag 指向这个 manifest」的引用关系摘掉了，底层的 blob（镜像层数据）一个字节都没动。而且因为分层共享，你删的那个层很可能还被另外十个镜像引用着，就算想删也删不掉。
真正释放空间要靠垃圾回收（GC）。GC 会遍历所有 manifest，找出没有任何 manifest 引用的孤儿 blob 并从文件系统删掉。这才是磁盘下降的唯一途径。
这就解释了 Harbor 的磁盘曲线形态：只要没人主动跑 GC，这条线就是单调上升的，跟业务量无关节节攀升。
关于 GC 有个流传很广的说法是「GC 期间 Harbor 进入只读模式，push/pull 全停，要挑停机窗口」。这个说法来自 Harbor 2.1（2020 年 7 月）之前的实现。2.1 之后 GC 改成数据库驱动，官方文档明确写着 GC 运行期间可以照常 push、pull、delete 制品。
但这不代表 GC 是免费的，实际代价有两个：
一是 2 小时保护窗口。GC 不会碰 2 小时内上传的 blob，这是为了防止正在推送的镜像被误删。所以你推一个镜像然后立刻删掉，它的层要等下一次 GC 且过了窗口才会被回收——回收永远滞后于产生。
二是吞吐受 worker 数和存储 IO 限制。GC 是 jobservice 的任务，由可配置的并行 worker 执行，近期版本默认是 10 个 worker。每个 worker 串行删除 blob，瓶颈在存储后端的 IO 延迟。社区里有运维反馈过真实案例：Harbor 2.11 配 5 个 worker 时，删掉单个 manifest 的 blob 花了 34 分钟。worker 从 5 提到 10，同样的 blob 量时间大概砍半，但砍不到零。
于是有个很实用的判断公式：每次 GC 的回收能力 = worker 数 × 单 worker 单次回收的 blob 数。当「每天新增的孤儿 blob 数」大于「每次调度 GC 的回收能力」，你的仓库盘就在持续劣化，再怎么定时跑 GC 都追不上。这种情况只能加 worker、缩短 GC 周期，或者干脆限制推送频率。
另外，离线 GC（停掉 Harbor 服务再跑 registry 的 garbage-collect 命令）依然是很多团队的习惯做法，这种方式确实需要停机窗口，而且执行前要先用 --dry-run 预演一遍看会删掉什么。无论哪种方式，GC 过程中都需要数据库操作和临时空间，磁盘 100% 的时候 GC 是跑不起来的——这也是为什么仓库盘不能吃到满。
磁盘之外，Harbor 还有一种「瞬时压力」容易被忽略：发布风暴。
算一笔账。一个 1.2GB 的镜像，10 个节点同时拉取，就是 12GB 数据从 registry 出去。千兆口理论 125MB/s，纯网络传输 96 秒；但 registry 还要做 blob 的读取、流式传输，后端是机械盘或者高 IO 延迟的网络存储时，随机读会让吞吐打对折（预估），实际可能要 3–5 分钟。更狠的场景是 CI 推一个新 tag 触发滚动更新，20 个 Pod 同时拉同一批层——registry 的出向带宽和磁盘读 IO 同时到顶，这个时间点上如果有别的团队在 push，两边一起卡。
判断标准很朴素：给仓库节点的网卡别低于千兆，盘别用机械盘。这两个钱省下来，将来会以「发布的时候整个流水线卡住」的形式还回去。
最后一个常见的仓库爆炸原因，跟 Harbor 无关，跟你们 Dockerfile 怎么写有关。
镜像分层共享的前提是「前面的层没变」。如果 Dockerfile 写成这样：
COPY . /app 放在前面，RUN pip install -r requirements.txt 放在后面——那么每改一行代码，COPY 层就变了，后面 pip install 装出来的几百 MB 依赖层也全部重建，成为一个全新的 blob。CI 一天跑十次，就是十个几百 MB 的新层堆在仓库里，旧的那九个逐渐变成孤儿，等着 GC 来收。
正确顺序反过来：先 COPY 依赖清单文件，再 RUN 安装依赖，最后 COPY 源码。这样改代码只重建最后那一层，通常几十 KB 到几 MB。
配合 Harbor 的 Tag Retention 规则（保留最近 N 个 tag / 保留 N 天内推送的 / 按匹配规则保留）+ 定期 GC + GC 前先 Dry Run，仓库盘才能长期维持在可控水位。我给客户的经验值是：仓库盘的常态占用不要超过 60%，剩下 40% 是留给孤儿层和 GC 周转的余量。
etcd 是所有 K8s 对象（以及 KubeSphere 自己的大量 CRD 对象）的数据库，它的写路径要求每次写入都把 WAL 刷盘（fsync）。这个 fsync 的延迟直接决定了集群的稳定性。
行业通行做法是要求 WAL 盘的 fsync 延迟 p99 在 10ms 以内（预估，etcd 官方推荐 SSD 并给出该量级要求）。为什么是这条线？etcd 的默认心跳间隔是 100ms、选举超时是 1000ms。fsync 一旦慢下来，leader 的心跳写不进去、follower 收不到心跳，超过选举超时就会发起新一轮选举——表现就是集群「时不时抽一下」：apiserver 短暂不可写、Pod 状态卡住、KubeSphere 控制台转圈。
机械盘（5400/7200 转）的单次 fsync 常在 5–20ms 且抖动极大，网络存储（NFS、iSCSI）更不可控。这类盘放 etcd，集群会在业务高峰期莫名其妙地抖。这不是性能问题，是稳定性问题。
我的判断很明确：跑 etcd 的节点，盘必须是本地 SSD 或 NVMe，不能用共享存储，也不能用机械盘。这条钱是整份预算里最不该省的。
这个问题没有统一答案，要看节点数：
3 节点：不要分。etcd 要奇数副本才有容错，3 节点分出「1 控制面 + 2 worker」等于 etcd 只有 1 副本，或者把控制面塞进 2 台里导致 3 副本里有 2 台还跑着业务。3 节点就全部混跑，用 node-role.kubernetes.io/control-plane 的 taint 阻止业务 Pod 调度上去（但允许可观测组件调度），这样既保住了 3 副本容错，也不浪费机器。
6–10 节点：建议分。划 3 台专门跑控制面 + etcd，盘用 NVMe、内存给到 32GB（因为 KubeSphere 的 CRD 对象不少，etcd 的内存占用会比原生 K8s 高）。剩下 3–7 台做 worker。分开之后的好处是业务负载的高 IO、高 CPU 不会干扰 etcd 的 fsync——这点非常关键，一台 worker 上跑个日志狂写的 Pod 把磁盘 IO 打满，如果 etcd 在同一台机器上，整个集群跟着遭殃。
20 节点以上：必须分，且再分一层。控制面 3 台独立；可观测组件单独放到 2–3 台「基础设施节点」上，用 nodeSelector 或 taint 固定。这时候可观测组件自己的开销已经到了 16–20 核、48–64GB（预估），跟业务混在一起会互相干扰。
| 集群规模 | 可观测组件固定开销（CPU / 内存） | 时序与日志磁盘（保留期） | 镜像仓库建议空间 | 节点建议规格与月租参考 |
|---|---|---|---|---|
| 试水 3 节点 ≤20 个业务 Pod |
4–6 核 / 10–14GB （OpenSearch 独占 4–6GB）（预估） |
时序 9–26GB（30s 间隔 / 15 天） 日志 63–126GB（7 天，含副本）（预估） |
160GB SSD 起步 （Harbor 官方推荐档） |
3×（8 核 16GB / 200GB SSD） 裸金属 E5-2620 32G/1T ¥999 起（官网价，以官网实时价为准） |
| 小生产 5–6 节点 20–60 个 Pod |
6–8 核 / 16–22GB （OpenSearch 6–8GB、Prometheus 系 2–3GB）（预估） |
时序 26–60GB（30 天） 日志 126–252GB（14 天，含副本）（预估） |
300–500GB SSD 常态占用不超 60%（预估） |
5×（8 核 32GB / 500GB NVMe） 按 5 台 ¥999 档推算约 ¥4995/月（预估，以咨询为准） |
| 标准生产 10 节点 60–200 个 Pod |
10–14 核 / 28–36GB （OpenSearch 建议扩至 2–3 节点）（预估） |
时序 60–130GB（30 天） 日志 210–290GB+（14 天，含副本）（预估） |
800GB–1TB SSD 独立仓库节点（预估） |
3× 控制面（8 核 32GB / 500G NVMe）+ 7× worker（16 核 64GB / 1T NVMe） 整集群约 ¥2.5 万–4 万/月（预估，以咨询为准） |
| 多集群 / 边缘 20+ 节点 |
单独 2–3 台基础设施节点 16–20 核 / 48–64GB（预估） |
时序 200GB+ 日志建议外置对象存储（预估） |
独立仓库节点 2TB SSD 或对接对象存储后端（预估） |
3×（16 核 64GB / 1T NVMe）+ N×（32 核 128GB / 2T NVMe） 裸金属 E5-2698v4×2 档 ¥3999 起（官网价，以官网实时价为准） |
表里所有带「（预估）」的数字都是按本文公式和行业经验值推算的，不是某个集群的实测值。真正的做法是装完之后用 kubectl top 和 df -h 看一周，拿真实数据回头校正这张表——这才是靠谱的容量规划流程。
控制面节点我一律推荐裸金属，不用云主机。理由很实在：etcd 要的是无虚拟化开销的本地 NVMe，fsync 延迟这条硬线不能交给共享存储层的云盘去扛，中间多一层抽象就多一截不可控的抖动。
具体档位上，一万网络裸金属标准档 E5-2620 32G/1T 是 ¥999/月起，E5-2698v4×2 32G/1T 是 ¥3999/月起（均为官网价，以官网实时价为准）。3 节点试水用 E5-2620 档就够，一台不到一千块，三台三千出头就能把 KubeSphere 全组件跑起来；上到 10 节点的标准生产，控制面三台我建议直接上 E5-2698v4×2，40 核的余量用来扛 KubeSphere 那一堆 CRD 对象的 etcd 读写。
还有一条我认为值钱的：硬件故障 10 分钟自动迁移。跑 etcd 的节点挂一台，集群就只剩 2/3 副本，再挂一台就彻底没有法定人数——10 分钟和 4 小时的差别，是「抖一下」和「雪崩」的差别。一万网络深耕 IDC 19 年（成立于 2007 年），深圳自营机柜，这条承诺是自家机房才敢给的。
worker 节点反过来，我更推荐用弹性云，¥25 起（官网价，以官网实时价为准）。worker 是可以随时加减的，业务高峰期临时加两台跑完就退，这恰恰是云主机的强项；而控制面节点需要长期稳定，用裸金属更合适。这个组合（裸金属跑控制面 + 云主机跑 worker）是我在中小团队里推得最多的形态。
另外一条对 KubeSphere 特别有用的：免费系统盘快照，每日 3 份、30 秒回滚。升级 KubeSphere 版本、改 etcd 参数、动 Prometheus 的 retention 配置之前先打个快照，翻车了 30 秒回来。干过 KubeSphere 大版本升级的人都知道这个有多救命——扩展组件之间的版本依赖关系很紧，升挂了回滚的代价远高于重做。
如果 worker 上要跑 GPU 工作负载（模型推理、视频转码、渲染），一万网络这边 A100 40G 是 ¥2800/月、T4 是 ¥900/月、RTX3090 24G 是 ¥1750/月（均为官网价，以官网实时价为准），年付 8 折。KubeSphere 的监控扩展本身带 GPU 指标采集，装好之后控制台里能直接看到卡的使用率、显存、温度。
服务方面，7×24 中文工单平均 5 分钟响应，工程师可以 1 对 1 部署 CUDA / cuDNN / TensorRT / PyTorch / TensorFlow，开机即用。网络是 BGP 多线 + CN2 GIA 回国，多节点分布在华南、华东、华北、中国香港及海外——如果你们的 KubeSphere 要做多集群（Host 集群管 Member 集群那种形态），跨地域节点的网络质量直接决定成员集群的心跳稳定性，这块别图便宜。
为什么坑：这个数字是「最小化安装」的要求，不含可观测组件。真按它配机器，开全组件的时候要么装不上，要么装上之后 OOM 重启循环。而且 40GB 盘里，光 OpenSearch 的数据目录就能吃掉一半以上，剩下给镜像和日志的空间聊胜于无。
怎么避：生产一律按「每节点 8 核 16GB / 200GB SSD」这条官方生产要求起步。演示环境可以用最低配，但要在安装时就明确只开必要扩展——KubeSphere v4 的扩展是按需安装的，别一股脑全勾。
为什么坑：日志增长速度远超预期，一旦写满，同盘上的业务 PVC 一起遭殃，从「可观测瞎了」升级成「业务挂了」。而且磁盘满的时候 OpenSearch 会把索引置为只读，你想删数据都删不动。
怎么避：可观测数据独立 PVC、独立 StorageClass，最好物理上独立一块盘。日志保留期按合规要求和查询需求定，别默认「全留」，同时给盘加 70% / 85% 两级水位告警。
为什么坑：有人把 user_id、request_id、URL path 塞进 metric 的 label 里。label 的一个取值组合就是一条独立时序，user_id 有 100 万个可能值，就是 100 万条时序。Prometheus 的内存和磁盘同时爆，而且这种爆法是指数级的，前一天还正常，第二天就满了。
怎么避：label 只放低基数维度（服务名、实例、状态码、方法名），高基数信息走日志不走指标。 cardinality 超过百万的集群，考虑用 recording rule 预聚合 + 缩短保留期，或者把长期数据扔到远端存储。
为什么坑：前面说过，删 tag 不释放空间，必须跑 GC。但磁盘到 100% 的时候，GC 自己也跑不动——它需要数据库操作和临时空间。这时候唯一的出路是先扩盘，扩完再 GC，而扩盘往往意味着停机。
怎么避：装 Harbor 的时候就配好 Tag Retention 规则 + 定时 GC（每周一次，放在业务低峰），仓库盘常态占用控制在 60% 以内，70% / 85% 两级告警。GC 前先 Dry Run 看会删掉什么，确认生产镜像和保留规则没被误伤。
为什么坑：前面说过 fsync 那条 10ms 的线。机械盘的 fsync 抖动是随机的，网络存储的延迟还会被别的租户影响。集群会表现出「没有规律的间歇性抖动」，排查起来极难——因为出问题的那一瞬间，监控可能也在抖，你什么证据都抓不到。
怎么避：跑 etcd 的节点盘必须是本地 SSD 或 NVMe。可以用 fio 测一下：测 fdatasync 的 p99 延迟，超过 10ms 就换盘。这个测试花不了十分钟，能省掉后面几周的排查。
能装上是一台（All-in-One），但那只能做功能验证。生产环境我的下限是 3 台——不是因为性能，是因为 etcd 需要奇数副本才能容错，1 台和 2 台在容错上是等价的（都是 0），3 台才能容忍 1 台故障。配置上 3 ×（8 核 16GB / 200GB SSD）是官方生产要求，能跑 20 个 Pod 以内的小业务。想跑更多，横向加 worker 比纵向加配置划算。
我的建议是 7 天起步，看查询习惯再决定要不要延长。实话说，绝大多数线上排查查的是最近 2 小时到 2 天的日志，7 天已经覆盖了绝大部分场景；超过 7 天的日志通常是合规审计用的，那部分应该单独归档到对象存储，而不是留在 OpenSearch 里占着 SSD。按前面算的账，20 个 Pod 从 7 天改到 30 天，磁盘从 126GB 涨到 540GB，这个代价大多不值得。
小集群（3–6 节点）没得选，只能混，用 taint 把业务 Pod 挡在控制面节点外面就行。10 节点以上我建议分开，理由是干扰隔离：可观测组件的磁盘 IO 是持续且随机的（日志写入、TSDB compaction），跟业务 Pod 的 IO 混在一起会互相拖慢，尤其是 etcd 在同一台机器上的时候，日志 IO 打满直接导致集群抖动。用 nodeSelector 把 OpenSearch、Prometheus 钉到固定的 2–3 台基础设施节点上，成本不高但收益明显。
写满之后 Prometheus 会停止采集，监控曲线断掉，基于其上的告警也不会触发——这是最危险的地方，你以为是「一切正常」，其实是「没有数据」。救急的办法有两个：一是调小 --storage.tsdb.retention.time 重启，让旧块尽快过期（注意过期块清理是后台任务，最长可能要两小时）；二是手动删除最老的 block 目录。但官方文档提醒得很清楚：如果本地存储损坏到 Prometheus 起不来，最后手段才是删文件，那意味着丢掉对应时间段的数据。所以正解是提前把 retention.size 设为磁盘的 80–85%，再加磁盘水位告警。
3 节点的小集群里不必单独占一台，装在控制面节点或者一台 worker 上都行，但要满足两个条件：一是 /data 用独立盘（不要和系统盘、容器运行时共用），二是内存给到 8GB（官方推荐档），开 Trivy 扫描的话这个数不能再低。10 节点以上、或者 CI 每天推送次数超过 20 次的团队，我建议单独一台 4 核 8GB / 500GB SSD 的仓库节点——发布风暴的时候 registry 会把网络和磁盘 IO 同时打满，跟别的服务挤在一起谁都跑不好。
技术上能，稳定性上不推荐。etcd 对 fsync 延迟的要求是端到端的，同一块盘上有别的组件在做大量随机写（比如 OpenSearch 在写索引、Prometheus 在做 compaction），etcd 的 fsync 排队时间就会被拉长。真要共用，至少保证 etcd 有独立的分区和独立的 IO 调度优先级，并且盘本身是 NVMe、余量充足。预算允许的话，控制面节点上一块盘专门给 etcd 的 WAL 是最稳的做法，这块盘不用大（几十 GB 足够），但一定要快。
我给的答案是混合：控制面节点用裸金属，worker 用云主机。控制面要的是稳定的本地磁盘和低延迟（etcd 那条 fsync 线），裸金属没有虚拟化层，这一点上有天然优势，而且长期持有成本更低；worker 要的是弹性（高峰期加机器、低谷期退机器），这恰恰是云主机的强项。一万网络的组合就是这种：裸金属 E5-2620 32G/1T ¥999 起、E5-2698v4×2 32G/1T ¥3999 起（官网价，以官网实时价为准）跑控制面，一万云 ¥25 起（官网价，以官网实时价为准）跑 worker。全都用裸金属会失去弹性，全用云主机则 etcd 的磁盘延迟要多一层考量。
小团队（CI 每天推送 10 次以内、镜像总量在几十个以内）给 160–300GB SSD 就够，关键是配好 Retention + 定时 GC，把常态占用压在 60% 以下。判断要不要上对象存储的标准是两条：一是仓库盘的月增长量——如果每月净增超过 50GB 且 GC 追不上，说明该上对象存储了，对象存储按量计费、不用担心盘满；二是是否需要多实例共享后端——Harbor 的高可用部署要求有状态组件外部化，存储用 S3 兼容的对象存储是首选，本地文件系统撑不起多实例。
把四本账合起来看，KubeSphere 的资源规划其实就一句话：先算组件固定开销，再算业务负载，最后按 30% 余量往上取整。顺序反了——先估业务再往上加一点——是绝大多数「装完发现不够用」的根源。组件开销在小集群里不是零头，是主菜：3 节点集群上 10–14GB 的固定内存占用（预估），比你业务 Pod 的总需求还大，这不是 KubeSphere 做得重，是可观测这件事本身就重，谁来做都一样。
磁盘这边，最容易被低估的是日志。监控盘给个 30–60GB 基本够用且可以算得清，日志盘动辄几百 GB 且跟你的日志级别、Pod 数、保留期强相关。我的建议是把日志保留期当成一个需要主动决策的参数来管，而不是用默认值——7 天和 30 天之间差着四倍的钱。
镜像仓库是最容易被忘掉的一块，因为它在初始部署时看起来很小，然后在几个月后的某一天突然满掉。装的时候就把 Retention 规则和定时 GC 配好，比事后救火省事得多。
机器选型上，我的立场很明确：控制面节点上本地 NVMe 和 10 分钟故障迁移这两件事不能省，worker 节点的弹性和快照回滚不能省。一万网络深耕 IDC 19 年（成立于 2007 年），深圳自营机柜，裸金属 E5-2620 32G/1T ¥999 起、E5-2698v4×2 32G/1T ¥3999 起（官网价，以官网实时价为准）跑控制面，一万云 ¥25 起（官网价，以官网实时价为准）跑 worker，硬件故障 10 分钟自动迁移、免费系统盘每日 3 份快照 30 秒回滚、7×24 中文工单平均 5 分钟响应、BGP 多线 + CN2 GIA 回国——这套组合对 KubeSphere 这种「控制面要稳、worker 要弹」的形态，是我目前给客户推得最多的。
本文涉及的资源占用数字分为两类，请分开看待：
官方明示数据：KubeSphere 环境要求（最低每节点 CPU 2 核 / 内存 4GB / 硬盘 40GB，生产环境每节点 CPU 8 核 / 内存 16GB / 硬盘 200GB）来自 KubeSphere 官方文档；可观测扩展组件构成（WizTelemetry / WhizardTelemetry 平台服务、数据流水线、日志、事件、审计、监控、告警、通知、全局监控，及 OpenSearch、Grafana Loki 等）来自 KubeSphere v4.1 / v4.2 扩展组件文档；Prometheus 容量公式（needed_disk_space = 保留秒数 × 每秒样本数 × 每样本字节数，每样本 1–2 字节）、retention.size 建议值为磁盘 80–85%、本地存储不支持 NFS，来自 Prometheus 官方存储文档；Harbor 最低配置（2 核 / 4GB / 40GB）与推荐配置（4 核 / 8GB / 160GB）、删除镜像不自动释放空间、GC 行为来自 Harbor 官方文档。
推算与行业经验数据（文中均标注「（预估）」）：各规模集群的可观测组件固定开销、日志索引膨胀系数 1.1–1.5 倍、etcd fsync 延迟 10ms 参考线、GC worker 吞吐与耗时、镜像拉取峰值带宽估算等，均为基于上述公式和行业通行经验值的推算，非特定环境的实测结果，仅供容量规划起步参考，实际请以部署后 kubectl top、df -h、fio 的实测数据校正。
价格口径：文中标注「官网价」的数字取自一万网络官网公开报价页面（裸金属 E5-2620 32G/1T ¥999 起、E5-2698v4×2 32G/1T ¥3999 起、一万云 ¥25 起、A100 40G ¥2800/月、T4 ¥900/月、RTX3090 24G ¥1750/月），以官网实时价为准；标注「（预估）」的价格为按档位推算或需按配置核算，以咨询为准。服务器租用、裸金属、云主机、GPU 定制的具体报价与配置，请以一万网络官网 https://www.idc10000.net/ 相关页面为准，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
