2026 每个 Pod 都挂一个 Sidecar：服务网格的资源开销到底算在谁头上

集群明明还有一半资源没分配，调度却开始 Pending

某平台团队把集群从 40 个节点扩到 60 个之后，监控面板上的 CPU 分配率还停在 45% 上下，新发的 Deployment 却一批批卡在 Pending。用 kubectl describe pod 拉出来看，Events 里是那句很熟悉的话：0/60 nodes are available: 60 Insufficient cpu。负责调度的同学直觉反应是节点不够，于是继续加机器；加到 70 个节点，Pending 少了一些，但扩容响应越来越慢，HPA 一触发总有几分钟空窗，业务侧已经开始投诉。

问题的根子不在节点数上。把任意一个业务 Pod 的 spec 展开看，containers 里除了业务容器，还多了一个 istio-proxy，它带着自己那份 resources.requests。集群里 900 多个 Pod，等于凭空多出 900 份 CPU 请求和 900 份内存请求，这些请求一分不少地记在调度器的账上。而面板上的「资源分配率」用的往往是节点 capacity 口径，或者只看业务容器的请求量，压根看不到这一层，于是出现了「面板说还有一半空闲，调度器说一个核都挤不出来」的怪象。

更隐蔽的是节点上的另外几笔固定支出：kubelet 预留（kube-reserved）、系统预留（system-reserved）、驱逐阈值（eviction threshold），以及 CNI 插件、日志采集、节点监控这些 DaemonSet 一成不变的占用。新加一台节点带来的可分配增量，先被这几项削掉一块，再被每个 Pod 的代理请求摊薄，剩下的往往是零散的小块，装不下任何一个完整的新 Pod。

先把结论摆出来，后面逐条展开：

• 代理容器的开销按 Pod 数线性叠加，加节点不改变量，只改变它被摊在哪台机器上。
• 调度器看的是 requests 之和，不是监控面板上的分配率，两者口径不一致是误判的源头。
• 控制面是一笔固定的小支出，数据面才是真正的成本大头，预算要分开记。
• 小规格高密度集群吃亏最明显，因为固定成本、代理成本、业务请求挤在很小的可分配空间里，装箱效率崩得最快。
• 正确的规划顺序是先算峰值 Pod 数，再倒推节点规格与节点数。

开销是按 Pod 数算的，不是按节点数算的

把这笔账算清楚只需要一次乘法。假设网格给每个代理容器设定的请求是 c 毫核 CPU、m 兆内存（社区发行版的常见默认大致在 100m CPU 与 128Mi 内存这一量级，具体数值以官方文档对应版本为准），集群里有 N 个注入了代理的 Pod，那么网格带来的额外请求就是 N×c 与 N×m，与集群有多少个节点完全没有关系。

换成具体数字更直观：900 个 Pod、每代理 100m CPU 请求，就是 90 个核；每代理 128Mi 内存请求，就是约 112Gi 的常驻内存占用。这个总量不会因为节点从 60 台加到 120 台而变小，也不会因为节点规格从 8 核换成 64 核而变化。节点数只决定这些开销被摊在哪几台机器上，不决定它有多大。

反过来，Pod 数一旦翻倍，开销立刻翻倍。很多团队在做微服务拆分时把原来的单体拆成 40 多个服务，每个服务 6 到 10 个副本，Pod 数从两三百涨到七八百，网格开销跟着线性上涨，而业务真实承载的请求量并没有同比例增长。这就是「服务拆得越细，网格越贵」这句话的真实含义——代价不落在调用链的深度上，落在 Pod 的副本数上。每拆出一个独立部署单元，就多一批常驻代理。

由此能推出一条很实用的规则：评估网格成本时，最先要确定的参数不是节点数、也不是总核数，而是峰值 Pod 数。峰值 Pod 数大致等于「服务数 × HPA 最大副本数」加上「批处理任务的峰值并发 Pod 数」。用这个数字乘上单位代理开销，得到的才是网格真正要向集群申请的资源额度，也是做容量规划时应该写进表格的开头一行。这里还有一层容易被忽略的对比：把 800 个 Pod 从 100m 降到 50m 单位请求，省下的是 40 个核；而加 10 台 4 核节点，扣除系统预留之后可能只多出 30 个核可分配，且每台机器还要再付一次 DaemonSet 与系统预留的固定成本。两相对照，调单位请求和降 Pod 数的收益，往往比加节点更直接。

控制面其实很便宜，贵的是每个 Pod 旁边那个容器

把控制面和数据面拆开看，两笔支出的量级差得很远。

控制面（以 Istio 为例就是 istiod）做的事情是把服务、端点、路由规则翻译成 xDS 配置，通过 gRPC 长连接推给所有代理。它的实例数量是固定的，通常两三个副本就够用，占用多少资源与「集群有多少节点」没有直接关系，主要与「网格里有多少服务、端点、规则」以及「配置变更有多频繁」相关。这意味着控制面是一笔可以预估、可以提前规划的固定支出，波动也相对可控。

数据面完全是另一回事。每个注入代理的 Pod 里那个容器，跟着 Pod 一起生一起死。Pod 起一份它就占一份请求，业务从 50 个副本扩到 500 个，它就占 500 份，而且这多出来的 450 份不会给业务带来任何额外吞吐——它只是把同一套代理逻辑复制了很多遍。业务弹性越大，这笔账涨得越快，且涨的部分全部落在集群的可分配资源里。

所以做预算时要分两行记：控制面按「固定几台小规格实例」规划，数据面按「峰值 Pod 数 × 单位代理开销」规划，后者通常占据网格资源占用的绝大部分（具体占比需按实际集群实测）。一个常见的误判是团队为了控制面高可用，把 istiod 开到 5 个副本、每个给 8 核 16G，结果控制面花掉的资源还不到数据面的一半，钱花在了不疼的地方，真正挤爆调度的那部分一个核都没省下来。

控制面副本数该怎么定，判断依据是故障窗口而不是资源占用。副本数影响的是某个 istiod 实例重启或节点驱逐期间，代理能否持续拿到配置、能否完成新端点下发。生产环境建议至少 2 个副本并配置 PodDisruptionBudget，避免节点升级时被一次性清掉；规模更大、发布更频繁时可以加到 3 个，并把控制面放到独立节点池上，不要和数据面的启动峰值抢同一份 CPU。

每节点 Pod 密度：小规格高密度集群为什么最吃亏

同样的 Pod 总数，放在不同规格的节点上，调度结果可能完全相反。

原因在于每台节点的可分配量并不等于它的标称规格。可分配量 = 节点容量 − kubelet 预留 − 系统预留 − 驱逐阈值。这部分是固定成本，跟节点大小关系不大。一台 4 核 8G 的机器，扣完预留可能只剩 3 核出头；一台 32 核 64G 的机器，扣完还有 29 核以上。同样的固定支出，在小规格节点上占的比例明显更高，可用空间被压得更扁。

再叠加代理开销，差距会被进一步放大。假设每节点放 20 个 Pod，每个代理请求 100m CPU，光代理就要 2 核：在 4 核节点上这是可分配量的六成以上，业务容器只能用剩下的零头，稍微来一个请求 0.5 核的服务就装不下，剩下的 0.3 核彻底变成碎片；在 32 核节点上，2 核只占不到 7%，业务容器有充足空间，装不下的碎片比例也小得多。两种情况下集群总资源可能是一样的，但前者会先一步出现 Pending。

这就是「小规格高密度集群最吃亏」的由来。不是小节点跑不动代理，而是小节点上「每节点固定成本 + 每 Pod 代理固定成本 + 业务请求」三者挤在很小的可分配空间里，装箱效率急剧下降，最后变成总量够、却处处装不下。此外还要留意 kubelet 的 maxPods 上限（社区默认值为 110，以官方文档对应版本为准），密度规划不能越过这条线，否则会出现资源还有富余、Pod 却因为数量上限起不来的情况。

在这种场景下，节点规格的选择标准要从「核数够不够」换成「内存和装箱余量够不够」。代理是常驻进程，它的内存请求会一直占着不放，节点内存请求一旦被占满，新的 Pod 同样 Pending，而且内存不像 CPU 可以靠限流硬撑。一万网络深耕 IDC 19 年（成立于 2007 年），给这类高密度集群做配置时，通常建议把数据面节点的内存按「每节点 Pod 密度 × 单代理常驻内存 × 冗余系数」往上抬一档，而不是单纯堆核数；对应官网在售的裸金属档位，从 E5-2620 32G/1T ¥999 起，到双路 E5-2698v4×2 32G/1T ¥3999 起，都可以按这个口径往上加内存（以上为官网明示档，以官网实时价为准）。

配置推送量与连接数：规模上去之后第二个瓶颈

规模再往上走，瓶颈会从「资源够不够」转移到「配置和连接扛不扛得住」。

代理与控制面之间是一条常驻的 gRPC 双向流，用来接收 LDS、RDS、CDS、EDS 几类配置。任何一次服务变更、端点增减、规则调整都会触发一轮推送；一次大范围滚动发布意味着成百上千个端点同时变化，控制面要在很短时间内把更新推给全部代理。推送高峰时控制面 CPU 明显抬升，代理侧要重新编译监听器与路由表，这段时间内存也会上一个台阶，如果 limits 卡得紧，就会出现启动慢、就绪慢甚至被杀掉重启。

规模变大之后还有第二个效应容易被忽略：单个代理持有的配置体积，取决于它「知道」多少服务和端点。默认配置下，代理收到的往往是网格内相当大范围的配置（具体范围与发行版及配置项有关，以官方文档对应版本为准），服务数越多，每个代理的内存占用越高，启动时加载配置的耗时也越长。这就解释了一个反直觉的现象——大规模网格里代理内存是随服务数增长的，而不是随流量增长的。一批跟它毫无调用关系的服务，也在默默占用它的内存。

缓解思路有四条。其一是用 Sidecar 资源做配置裁剪：在 egress.hosts 里显式声明某个命名空间的工作负载只需要知道哪些服务，控制面就只推这部分，代理内存和配置体积都会明显下降。其二是减少无谓的端点抖动：就绪探针配置不当、Pod 反复重启，会让端点集合频繁变化，把推送量放大好几倍。其三是给发布留窗口：把大批量的滚动更新拆成小批次，配合控制面的合并推送机制（相关 debounce 类参数的默认值以官方文档对应版本为准），避免瞬时堆积。其四是把控制面放在独立节点池并留出 CPU 余量，让推送高峰时它不被数据面拖慢。

跨可用区部署会把这两类压力再放一层。控制面与代理之间的长连接跨越可用区边界时，故障切换会让一批代理同时重连、同时拉取全量配置，形成一次集中的重连风暴；如果多个可用区的服务还互相调用，代理持有的端点集合也会更大，配置体积与连接数同步上升。规划时通常按可用区均分节点与代理数量，并让控制面在每个可用区都有实例，避免一次网络抖动就引发全网格重连。 连接数也是一个需要单独看管的对象。代理之间、代理与控制面、代理与后端之间都是长连接，节点上 Pod 密度越高，连接数与文件句柄的占用就越集中。把「每节点代理数量」当成一条硬约束写进密度规划，比等连接失败、端口耗尽之后再补救要省事得多。

三类减负做法：注入范围、资源规格、采样率

一、收窄注入范围，只给真正需要网格能力的负载挂代理

最直接的减负是干脆少注入几个代理。注入通常靠命名空间的 istio-injection=enabled 标签触发，也可以在 Pod 模板上用 sidecar.istio.io/inject 注解做例外。合理做法是反过来做白名单：先给基础设施类命名空间（系统组件、监控、日志、存储、批处理）显式关闭注入，只对真正需要 mTLS、灰度、细粒度可观测的服务打开。

判断标准只有一条：这个工作负载是否需要网格提供的能力。需要双向 TLS、需要按版本切流量、需要调用级指标与追踪的，注入；跑定时任务的 Job、做数据搬运的批处理、已经自带加密与鉴权的中间件，注入了只是白付一份固定开销，还额外拉长了启动时间。实践中把这一类关掉，往往能砍掉相当比例的代理数量（具体比例需按实际集群实测）。

二、把 requests 和 limits 分开调，别用同一个数字

resources.requests 决定调度，limits 决定上限，两个方向都会出问题。requests 设高了，节点提前装满，Pod 数上不去；limits 设低了，代理在加载配置和启动阶段的 CPU 峰值被限流，就绪时间从几十秒拖到几分钟，一次滚动发布被整体拉长，内存 limits 设太低则直接 OOMKilled，Pod 反复重启，反过来又把端点抖动传导给控制面，形成恶性循环。

比较稳的做法是分层设置：requests 贴近稳态实测值，保证调度账算得准；limits 留出启动与推送高峰的余量，不要按稳态去卡死。同一份配置还要乘上副本数一起看——HPA 从 10 个副本扩到 50 个，代理开销同比例放大，这部分容量要在集群里预先留出。调整过程建议用监控数据做闭环：取一段时间的 CPU 与内存 P95 或 P99，再回写 requests，比拍脑袋定数字可靠得多。另外一个容易漏掉的细节是注入方式本身也有开销——以 init 容器方式改写 iptables 规则，会在 Pod 启动路径上多出一段初始化时间；改用 CNI 模式的发行版可以把这段开销从 Pod 启动里挪走，对大量短生命周期 Pod 的场景尤其划算（具体支持情况以官方文档对应版本为准）。

三、采样率按链路分层，别全网一个比例

追踪采样率、访问日志开关、指标采集维度，这三项共同决定代理额外付出的 CPU 与网络开销，也决定后端存储成本。采样率与后端存储近似线性：采样率翻倍，span 量与存储量大致翻倍，代理为生成和上报 span 付出的 CPU 也同步上升。所以采样率既是一个可观测性问题，也是一条实打实的资源账。

常见的配置入口是网格的 Telemetry 资源与代理级配置项（具体字段与默认值以官方文档对应版本为准）。务实做法是分层采样：核心链路保持较高比例方便排障，边缘链路降到很低甚至只保留错误采样，访问日志按命名空间开关，指标标签不要无节制地加高基数维度——把用户 ID 之类打进标签，基数一上来，时间序列数量会失控，存储与查询开销都会跟着爆。

还有一个结构性选项值得放进评估清单：无 sidecar 模式（以 Istio 的 ambient 模式为代表）把「每 Pod 一个代理」改成「每节点一个共享组件 + 按需部署的 waypoint 代理」，从结构上把按 Pod 线性增长变成按节点加少量按服务账号增长，大规模场景下能显著降低常驻开销。但它的功能覆盖与成熟度必须按版本核实（以官方文档对应版本为准），mTLS、策略、可观测的行为差异要在灰度环境验证充分之后再动生产。

网格规模与资源规划对照表

一万网络上的两组节点方案

对照上面这张表，落到「具体租什么」时，一万网络上可以组合出两套思路完全不同的方案，适合不同的 Pod 规模与密度目标。

方案一：大规格裸金属集中承载数据面

适用于峰值 Pod 数在 300 以上、每节点密度要往 50 个以上走、且需要全量注入做 mTLS 与灰度的生产集群。选型要点是内存而不是核数：先按「每节点 Pod 密度 × 单代理常驻内存」算出代理常驻量，再加上业务容器请求与冗余，反推内存规格。双路 E5-2698v4×2 32G/1T ¥3999 起这一档（官网明示价，以官网实时价为准）可以作为起步，内存按上面的口径往上加；节点间建议走内网高带宽互联，跨可用区部署时按可用区均分节点数，避免单个可用区故障把控制面和数据面一起带走。配套上，硬件故障 10 分钟内自动迁移、免费系统盘每日 3 份快照与 30 秒回滚，对控制面这类有状态组件比较实用。

方案二：小规格裸金属跑常驻 + 弹性云承接波动

适用于 Pod 数在 300 以下、或者负载有明显波峰波谷的集群。做法是分层放置：控制面与常驻的在线服务放在物理机上，保证调度账算得清、不受邻居干扰，E5-2620 32G/1T ¥999 起（官网明示价，以官网实时价为准）这一档够用；灰度环境、临时压测、批处理峰值则交给一万云 ¥25 起（官网起步价，以官网实时价为准）的弹性实例，用完即释，不为短时峰值长期买资源。

如果业务已经明确要跨地域部署，比如生产放在大陆节点、灾备或海外接入放在中国香港或新加坡节点，两组方案还可以混着用：数据面按地域拆成多个集群，各自独立控制面，节点规格按本地 Pod 密度分别核算，不必强求统一。这种拆法对资源账最友好，因为每个集群的服务数与端点数都被控制住了，单个代理的内存占用和推送量都不会随全局规模一起膨胀；代价是多套控制面的运维成本，需要配套的发布与监控体系统一管理。 两套方案的取舍维度不一样：方案一买的是装箱余量与密度上限，适合 Pod 数持续增长的稳定业务；方案二买的是弹性与起步成本，适合规模还没定型的团队。判断标准还是回到 Pod 数——峰值 Pod 数一旦稳定在几百量级且还在涨，方案一的单位 Pod 成本更低；如果 Pod 数波动大、均值低，方案二更划算（具体成本对比需按实际集群实测后核算）。一万网络深耕 IDC 19 年（成立于 2007 年），在大陆华南、华东、华北、华西以及中国香港、美国洛杉矶、新加坡等节点均有资源，BGP 多线 + CN2 GIA 回国，配合 7×24 中文工单与平均 5 分钟响应，跨地域部署时可以按业务就近落节点。

四个容易踩的坑

坑一：只看集群整体分配率，不看 Pod 级请求

为什么坑：调度器判断能不能放下一个 Pod，用的是该节点已分配 requests 之和，而不是监控面板上的使用率或容量口径的分配率。面板通常看不到 sidecar 那份请求，也看不到系统预留和 DaemonSet 占用，于是出现了「面板显示还剩一半，调度器说一个核都没有」的错位，团队会顺着错误的方向一路加节点。

怎么避：以 kubectl describe node 输出的 Allocated resources 段落为准，看 requests 那一列；同时统计「注入了代理的 Pod 数 × 单代理请求」得到网格额外开销，把这两个数字一起放进容量表。监控面板上加一条「按 requests 口径的分配率」，与现有指标并列看。

坑二：给代理设一个很低的 CPU limit，以为这样能省资源

为什么坑：代理在启动和接收大批量配置推送时会有一段时间明显的 CPU 峰值，limit 卡得太低，这段时间被限流，Pod 就绪变慢，滚动发布整体拉长；内存 limit 卡太低则直接 OOMKilled，Pod 重启又把端点抖动传给控制面，把推送压力进一步放大，最后变成越省越慢。

怎么避：requests 贴稳态、limits 留峰值，两者不要用同一个数字；上线前在预发环境按真实服务数做一次启动耗时与峰值内存的实测，用实测值回写配置，而不是照搬别人的 YAML。

坑三：全量注入，把批处理、日志采集、中间件也一起挂上代理

为什么坑：短生命周期的 Job 每次执行都要付一次代理启动开销，执行时间可能只有几十秒，启动代理却占掉其中一大块；这些负载通常也不需要用网格做流量治理，等于纯支出。数量一多，代理数会远超实际需要治理的服务数。

怎么避：按命名空间做白名单注入，对 Job、CronJob、基础设施组件显式加 sidecar.istio.io/inject=false 注解；每次新增命名空间时，注入开关默认关闭，需要时再开。

坑四：把 Pending 一律当成「节点不够」，加机器解决

为什么坑：代理开销随 Pod 数增长，加节点只是把同样的总量摊到更多机器上，不改变总量；节点越多，每节点的系统预留与 DaemonSet 占用反而越多，可分配比例还会下降。结果是机器加了一轮又一轮，Pending 只缓解不消失，成本却实打实涨了。

怎么避：先算峰值 Pod 数，判断能不能通过合并服务、提高单副本规格、下调 HPA 最大副本数来减少 Pod 数；Pod 数降下来之后如果调度仍然紧张，再决定加节点或换更大规格的节点。

关于服务网格资源规划的七个高频疑问

多少 Pod 规模以下不值得上网格？

如果峰值 Pod 数在几十个以内、服务间调用关系稳定、也没有强制的双向 TLS 与细粒度灰度要求，网格带来的治理收益通常盖不过常驻开销与运维复杂度。这类规模用 Ingress 配合服务自身的重试、超时、鉴权就能覆盖大部分需求，等 Pod 数稳定在百级、调用关系开始复杂、需要按版本切流量时再上也不迟，届时投入产出比会明显更好。

什么时候该减少 Pod 数，什么时候该加节点？

判断依据是单 Pod 的规格是否合理。如果单个副本只请求了很小的 CPU 和内存，纯粹靠堆副本撑并发，那么代理开销占的比例会畸高，这种情况下应该先合并服务或抬高单副本规格，把 Pod 数降下来；如果单副本规格已经合理、业务确实需要这么多副本承载流量，那么代理开销是刚性成本，加节点或换更大规格节点才是对的解法。

控制面到底要不要多副本？

生产环境建议至少 2 个副本并配置 PodDisruptionBudget，目的不是分摊资源压力，而是保证节点升级、驱逐、实例重启期间代理仍能持续拿到配置。规模更大、发布频繁、配置推送量高的集群可以加到 3 个，并把控制面放在独立节点池上。超过 3 个副本通常收益递减，此时更应该考虑按网格或按集群拆分，而不是继续堆副本。

代理的 requests 应该设成多少？

没有放之四海皆准的数字，因为它跟服务数、配置体积、采样率、QPS 都有关。可行做法是先在预发环境用接近生产的服务规模跑起来，取 CPU 与内存的 P95 或 P99 作为 requests 基准，limits 在此基础上留出启动与推送高峰的余量。社区发行版的默认配置可以作为起步参考（具体数值以官方文档对应版本为准），但不要直接搬到生产。

追踪采样率设多少合适？

取决于排障需求与后端存储预算，而不是一个固定比例。常见做法是分层：核心交易链路保留较高比例，内部管理类与边缘链路降到很低或只保留错误采样。调整前先算一笔账——采样率翻倍，span 量、上报带宽与存储量大致同步翻倍。可以先设一个偏低的初始值，观察一段时间排障是否够用，再逐步上调。

全量注入和命名空间级注入，哪个更合理？

除非有统一的合规要求必须对所有东西向流量做双向 TLS，否则命名空间级注入更合理。全量注入的好处是策略一致、不会漏，代价是把大量不需要治理能力的负载也纳入开销。折中做法是先全量打开保证不漏，再用注解把明确不需要的负载逐个排除，最后把默认策略收敛成按命名空间白名单。

换成无 sidecar 模式能省多少？

结构上省的是「每 Pod 一份常驻代理」这部分，改成每节点一个共享组件加按需部署的少量 waypoint 代理，Pod 数越多省得越明显。但具体能省多少取决于服务账号数量、waypoint 的部署粒度与流量路径，需按实际集群实测。同时要注意功能覆盖与成熟度按版本核实（以官方文档对应版本为准），先在灰度环境验证再推广。

先算 Pod 数，再算节点数

把上面的分析收拢成一条可执行的规划顺序，做容量方案时按这个次序往下走，基本不会在南辕北辙的方向上浪费预算。

步骤一，数清峰值 Pod 数。不是当前 Pod 数，而是峰值：服务数乘以每个服务的 HPA 最大副本数，再加上批处理任务的峰值并发数。滚动发布期间还会短暂多出一版副本，这部分冗余也要算进去。

步骤二，乘上单位代理开销，得到网格的额外请求总量。单位开销取实测值，没有实测条件时用发行版默认配置做估算（以官方文档对应版本为准），并把采样率、配置体积带来的差异考虑在内。这一步的结果就是网格向集群申请的 CPU 与内存额度。

步骤三，算每节点真实可分配量。用节点容量减去 kubelet 预留、系统预留、驱逐阈值，再减去 CNI、日志、监控这些 DaemonSet 的占用，剩下的才是能分给 Pod 的空间。密度规划同时不要越过 maxPods 上限（社区默认 110，以官方文档对应版本为准）。

步骤四，定 Pod 密度并倒推节点数。密度取决于装箱余量：小规格节点上代理占的比例高，密度要往下压；大规格节点可以往上提。节点数等于峰值 Pod 数除以密度，再向上取整。

步骤五，加冗余与可用区均分。在算出的节点数基础上留出 N+1 或 N+2 的余量，跨可用区部署时按可用区均分，保证单个可用区失效后剩余节点仍能承载峰值负载。最后再回头定控制面规格与副本数，并把它放到独立节点池上。

方案落地之前还有一步值得做：把算出来的数字回填到监控里做验证。选一个业务低峰，把某个服务的副本数调高一倍，观察节点 requests 口径的分配率、Pending 数量、控制面 CPU 与代理内存的变化曲线，确认实测与估算的偏差在可接受范围内，再把结论写进正式的容量表。估算与实测之间通常有偏差，偏差来源多半是配置体积和采样率，这两项在纸面上最难算准。 这套顺序的核心在于：代理开销是跟着 Pod 数走的，节点只是承载它的容器。先算 Pod 数，才知道网格要吃多少资源；先定密度，才知道要租多大规格的机器。反过来从「买几台机器」出发，几乎必然会在调度失败和反复扩容之间来回折腾。

这些数字从哪来

本文涉及的资源规划方法、调度口径与配置项说明，来源于 Kubernetes 与 Istio 社区公开文档中的通用机制描述，包括节点可分配量的计算方式、kubelet 预留与 maxPods 上限、sidecar 注入标签与注解、Sidecar 资源的配置裁剪能力、Telemetry 相关的采样配置等。涉及具体默认值（如代理默认 requests 与 limits、debounce 类参数、采样率默认值、maxPods 默认值）的部分，文中已标注「以官方文档对应版本为准」，实际取值请以所使用版本的官方文档为准。

资源占用量、成本占比、减负比例等结论性数字，均标注为「需按实际集群实测」，因为它们高度依赖集群的服务数量、配置体积、采样率与流量模型，不适合直接照搬。文中的集群规模区间与节点规格建议属于典型部署思路，用于说明规划方法，实际选型应结合业务负载特征核算。

服务器规格与价格信息来自一万网络官网公开页面，包括裸金属 E5-2620 32G/1T ¥999 起、E5-2698v4×2 32G/1T ¥3999 起、一万云 ¥25 起等明示档位，实际价格以官网实时价为准；标注「（预估）」「以咨询为准」的部分为非官网明示的推算值，不作为确定报价。一万网络为朗玥科技旗下 IDC 服务品牌，深耕 IDC 19 年（成立于 2007 年），总部位于深圳南山，具备增值电信业务经营许可证、国家高新技术企业、专精特新中小企业等资质，节点覆盖大陆华南、华东、华北、华西及中国香港、美国洛杉矶、新加坡、日本、韩国、德国等地，提供 7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟内自动迁移、免费系统盘每日 3 份快照与 30 秒回滚、可协助免费网站备案、5–20G 免费 DDoS 防护、BGP 多线 + CN2 GIA 回国等服务。