2026 服务器租用 eBPF 网络方案 Cilium 落地全解：内核版本门槛、可观测性与服务转发六维对比 + 避坑避雷手册

2026 服务器租用 eBPF 网络方案 Cilium 落地全解：内核版本门槛、可观测性与服务转发六维对比 + 避坑避雷手册

一个跑在自租物理机上的 Kubernetes 集群，节点二十余个，Service 数量从最初的一两百涨到三千上下之后，运维开始遇到一个说不清的毛病：每次发布一批服务，总有几秒钟时间，部分业务的建连请求会失败，重试一次又好了。抓包看不像网络问题，看应用日志也不像，最后定位到 kube-proxy 同步规则那一刻——规则是按表整体重建的，重建窗口里新来的连接找不到正确的转发项，于是被丢掉。这类抖动在小规模时完全感知不到，只有规模上去了才浮出来。这不是配置错误，而是 iptables 这套机制的固有代价。

把同样的场景搬到 Cilium 上，转发逻辑不再是一条条按顺序匹配的规则，而是挂在内核网络栈钩子上的 eBPF 程序加一张哈希表。目标查找从"逐条比对"变成"算一次哈希、查一次表"，规模再大也不会出现那种与规则条数正相关的匹配开销。听起来是一次纯粹的升级，但它换来的不是免费的午餐:Cilium 把转发路径挪进了内核可编程层，也就把可用性押在了内核版本、MTU 配置、eBPF map 容量和团队排障能力这四件事上。本文只论证一件事——在决定上 Cilium 之前，必须先核对内核版本、MTU 与封装开销、以及团队是否具备 eBPF 层面的排障能力，否则性能收益换不来可维护性。

下文的所有数字分两类:一类是协议层面的客观量(比如 VXLAN 头部长度)，一类是工程经验上的观察区间(比如"Service 数千、规则数万"这个量级)。后者一律标注为经验观察，要求你在自己的环境里实测确认。版本号同理，Cilium 的内核要求会随版本迭代变化，文中给出的是社区常见门槛区间，最终以官方文档的对应版本矩阵为准。

iptables 在规模上去之后慢在哪：线性匹配与连接跟踪表

iptables 的规则是按链组织的，一个包进入某条链之后，要从第一条开始往下比对，命中第一条匹配的规则才停下。这意味着单包的匹配成本与它前面有多少条不匹配的规则正相关。kube-proxy 的 iptables 模式下，每个 Service 会生成一串规则，每个 Service 背后的每个端点又会再生成一串规则，于是规则总量大致随"Service 数 × 后端 Pod 数"增长。Service 几百个时总量还在几千条，人眼还能看;Service 涨到数千、后端端点上万时，规则条数很容易进入数万量级。

比单包匹配更要命的是规则更新。iptables 的规则表在内核里是一块连续内存，增删一条规则在很多场景下会触发整表的重建与替换。单次重建的耗时随规则总量增长，而 kube-proxy 的同步循环又会周期性触发重建，于是就有了开头那个"每次发布抖几秒"的现象。这里给出的判断条件是经验观察:当 Service 数量达到数千、规则条数达到数万量级时，更新一条规则带来的全表重建开销会变得明显。是否在你这里"明显"，要用 `iptables-save` 数一下实际条数，再在变更窗口里测一次建连成功率，不要靠感觉下结论。

第二个瓶颈是连接跟踪(conntrack)。iptables 的 NAT 依赖 conntrack 表记录每一条连接的状态，表是有容量上限的。海量短连接场景——比如移动端高频心跳、HTTP 短轮询、爬虫式访问——会在短时间内灌进大量新建连接，把表打满。conntrack 表满之后的表现不是"变慢"，而是直接丢包，而且丢得相当隐蔽:应用侧看到的是偶发超时，网络侧看到的是正常，只有去查内核日志或者 conntrack 计数才能发现表已经满了。这也是为什么很多团队第一次遇到时会误判为应用问题。

还有一层是感知问题而非性能问题:iptables 模式下的规则是人可读的，但可读不等于可定位。数万条规则里找出"为什么这个包被丢"，需要顺着链一条条推演，还要理解 `-j` 跳转的走向。规模小的时候这件事很轻松，规模大的时候它会变成一项专门技能，而这项技能在出故障的深夜并不值钱——因为你真正需要的是三分钟内知道结论。这个痛点是 eBPF 方案出现的直接动因，也是理解后面所有取舍的起点。

eBPF 换掉了什么：从链式规则到哈希表查找

eBPF 的思路不是"把 iptables 规则写得更快"，而是换掉匹配这件事本身。它把一段经过内核校验器校验的程序挂到网络栈的特定钩子上，包经过钩子时执行这段程序，程序直接根据包头字段算哈希，去一张 eBPF map 里查目标，查到就转发。查找复杂度从随规则条数线性增长变成接近常数，因此规模越大优势越明显——一千条规则和五万条规则在它这里的差别，主要在 map 占用多少内存，而不在单包要花多长时间。

挂载点的选择决定了能力边界。XDP 位于网卡驱动层最早的位置，包还没进内核协议栈就能被处理，延迟最低，适合做丢弃和简单转发，但能拿到的信息有限;tc 的 ingress/egress 钩子在协议栈内，能拿到更完整的上下文，是 Cilium 做容器网络转发的主力挂载点;socket 层的钩子(包括 `sockops`、`sk_msg` 这类)则可以直接在套接字层面改写目标地址，让服务转发绕开一大段内核路径。Cilium 的不同特性分别用到了不同挂载点，这也是为什么"某个特性用不了"往往和内核版本、和挂载点支持情况同时相关。

换成哈希表带来的另一个变化是更新粒度。iptables 里加一条规则可能牵动整表;eBPF map 是一张键值表，加一个后端端点就是往表里写一个键，不需要重建别的东西。这正是前面那个"发布抖动"被根治的原因——同步从"重建一张大表"变成"增删改若干键"。理解这一点很重要，因为它解释了 Cilium 的性能故事到底讲的是什么:不是"eBPF 比 iptables 快十倍"这种口号，而是"规模增长时成本增长曲线的斜率变了"。

但把逻辑放进内核也意味着调试面变窄了。iptables 的规则可以用 `iptables -L -n -v` 打印出来逐条看，eBPF 程序在内核里跑，你看不到"规则"，只能看到 map 的内容和程序的状态。这就是本文反复强调的那件事:性能曲线的改善是确定的，可观测与排障方式的改变也是确定的，后者如果不提前准备，前者带来的收益会在第一次线上故障时被一次性还回去。

内核版本门槛：不达标会静默降级成半可用

这一节是全篇最需要你动手核对的部分。eBPF 不是内核的一项开关，而是十多年里逐步加入的一系列能力:早期内核只有基础的包过滤能力，后来的版本陆续加入了 map 类型的扩展、尾调用、以及各类挂载点。Cilium 的不同特性依赖不同批次的能力，于是形成了一个事实上的版本阶梯:基础的数据面转发需要的门槛较低，而要跑完整功能——尤其是替代 kube-proxy 的 socket 层负载均衡、Host-Replacement 这类要改写内核转发路径的特性——通常需要更高的内核版本，社区常见建议是 5.x 的较新版本。以下是常见门槛区间，具体版本请对照你所用 Cilium 版本的官方文档。

把这个阶梯讲清楚一点:一部分能力只要有基础 eBPF 支持就能工作，比如基于 tc 钩子的基本转发;一部分能力要求较新的内核才能开启，比如某些 map 类型、某些尾调用深度;还有一部分能力对内核版本的要求最高，因为它们要修改内核原本的行为路径。Cilium 在启动时会探测当前内核能支持什么，然后据此决定启用哪些特性。这个探测-降级机制本身是善意的:它保证了"装上就能跑"。问题出在降级是静默的。

静默降级的意思是，你在 A 环境验证过的行为，到了 B 环境可能完全不一样，而两份配置文件的 diff 是空的。举个典型例子:一个特性在低版本内核上不可用，Cilium 会退回到另一条转发路径，业务照常通，延迟高一些但不报错;另一个特性在探测时判定为不支持，直接不启用，你在配置里写了也没有任何警告级别的提示。结果是集群处于"半可用"状态——功能看起来都在，实际有一半走的是退路。这种状态最难排查，因为所有的健康检查、所有的连通性测试都会告诉你"没问题"。

所以对内核版本这件事，正确的做法不是问"最低支持多少"，而是问"我需要的每一个特性各自要求多少"。较老的 LTS 发行版是重灾区:它们的生命周期很长、稳定性很好，但内核版本可能停在几年前，正好卡在"能跑基础功能、缺高级功能"的区间里。如果因为合规或者运维习惯不能换发行版，那就必须接受功能缺失，并把缺失项写进设计文档，而不是假定它存在。

上线前必须逐项核对的功能矩阵怎么查

既然降级是静默的，最有效的办法就是把它变成显式的。Cilium 官方文档里有一份按特性排列的内核要求矩阵，做法很朴素:先把你打算用的特性列成一张表——是否替代 kube-proxy、是否开启 L7 策略、是否用覆盖网络封装、是否需要带宽管理或加密、是否依赖主机层的转发替换——然后逐条去矩阵里查它要求的内核版本，取其中的最大值作为你的实际门槛。注意是取最大值而不是取最小值，任何一个特性不达标都会影响整体设计。

第二步是在目标机器上实测，而不是照抄文档。`uname -r` 只能给你版本号，真正决定能不能用的是内核编译配置。重点看这些配置项是否被打开:BPF 与 BPF 系统调用、网络调度器对 BPF 的支持、cgroup 相关的 BPF 钩子、以及若干与 map 类型和校验器能力相关的编译开关。这些配置在发行版里通常可以在 `/boot` 下的配置文件或者 `/proc/config.gz` 里查到。配置没打开的后果和版本不够是一样的——静默降级。

第三步是跑起来之后看状态输出。Cilium 提供了命令行工具，可以打印出各组件的运行状态、当前启用了哪些特性、有没有被禁用的项以及禁用的原因。把这个输出在环境里存一份基线，每次升级内核或升级 Cilium 之后重新跑一遍做对比，比事后翻文档高效得多。特别注意输出里那些被标记为"禁用""不支持"的条目，它们就是静默降级的显形。

第四步是把核对做进流程，而不是做进记忆。建议的做法是在集群装机模板里加一条硬检查:内核版本低于门槛值就不允许加入集群，而不是等到部署网络插件时才报错。对于租用服务器的用户，这一点尤其重要——你在下单时就有权指定操作系统版本，等到机器交付之后再发现内核不达标，重装系统的成本远高于下单时选对版本。这一条同样适用于中国香港、中国台湾等地区的机房资源，操作系统模板通常是可选的，选之前先确认默认内核版本。

MTU 与封装开销：50 字节头部引发的大包异常

覆盖网络是容器网络最常见的形态:Pod 的 IP 在一个独立的网段里，跨节点通信时把原始包再套一层外层头和外层 IP，送到对端后解封装。VXLAN 和 Geneve 是两种常见封装协议，它们给每个包增加的头部长度在 50 字节量级——VXLAN 大约 50 字节，Geneve 与之相近。这是常见量级，实际字节数以你采用的具体封装模式和配置为准，比如是否带额外的选项字段、是否叠加了加密，都会改变最终值。

50 字节听起来微不足道，但它的影响方式是阶跃式的，不是线性的。以太网的标准 MTU 是 1500 字节，意味着一个不带封装的包最大可以承载 1500 字节。加了 50 字节封装头之后，如果这个包还要走一条 MTU 为 1500 的链路，它的总长就超了。超出之后的两种处理都不理想:一种是分片，把一个包拆成两个，带来的后果是吞吐下降、延迟抖动、部分中间设备对分片包处理异常;另一种是不分片但直接丢弃，表现为"小包通、大包不通"。

"小包通、大包不通"这个现象是识别 MTU 问题的关键指纹。它的迷惑性极强:Ping 是通的，因为默认 Ping 包很小;TCP 握手是通的，因为握手包也小;一旦开始传大块数据——文件下载、大响应体接口、数据库批量同步、镜像拉取——就卡住或者超时。很多团队第一次遇到时会去查应用、查带宽、查负载均衡，绕一大圈才回到 MTU。如果上完 Cilium 之后出现"部分业务异常且异常与数据量大小相关"，MTU 应该是排查列表里的第一项，不是第十项。

还要提醒一种特殊情况:即使 Pod 侧 MTU 设置正确，如果底层网络本身有更小的 MTU——比如经过了某种隧道、某种 overlay、或者上游链路限制了帧大小——问题会以同样的方式出现。所以判断 MTU 时要沿着整条路径看，而不是只看本机网卡。排查手段上，用指定包大小的 Ping 并禁止分片去逐档试探，是定位真实路径 MTU 最直接的办法;在容器里跑、在节点上跑、跨节点跑，三组结果对比，基本就能定位到瓶颈在哪一段。

巨帧与调小 Pod MTU：两条路各自的前提

解决封装开销的思路只有两条:让底层链路装得下更大的包，或者让 Pod 侧发出更小的包。第一条路是把底层网络的 MTU 调大，常见做法是开巨帧、把 MTU 设为 9000。这条路的性能最优，因为 Pod 侧可以保持较大的 MTU，封装后依然不超限，且不产生分片。但它有一个硬前提:全网设备必须一致。从服务器的网卡、到交换机的端口、再到中间任何一台转发设备，只要有一处没开巨帧，巨帧包到了那里就会被丢弃或者被强制分片，故障表现比小 MTU 时期更难定位。

这也是为什么在托管和租用环境里动巨帧要格外谨慎。物理机是你租的，交换机不是你管的。在自有机房里开巨帧是一次有计划的变更:逐台确认设备支持、逐段验证、留回滚方案。在租用环境里，需要提前向服务商确认整条链路是否支持巨帧、是否默认开启、跨机房或跨地域的链路是否也支持。如果拿不到明确答复，就不要假设它支持——巨帧的半通状态比不开更危险，因为它会让故障呈现出随机性。

第二条路是调小 Pod 侧 MTU，让它加上封装头之后不超过底层链路的 MTU。这条路不需要动网络设备，风险低、见效快，代价是 Pod 内实际可用的单包载荷变小，对大块传输场景会有轻微的吞吐损失。具体该调成多少，取决于你的封装模式和底层 MTU:底层是标准 1500 时，Pod 侧需要相应地减去封装开销，并留出余量。不同封装模式的开销不同，具体数值以你实际采用的封装协议和 Cilium 配置为准，不要照抄别人的数字。

怎么在两条路之间选?给一个直接的判断:如果你对整条网络链路有完全控制权(自有机房或明确承诺支持巨帧的租用环境)，并且业务里有大量大块传输，走巨帧;如果是租用环境、拿不到链路保证、或者业务以小包请求为主，走调小 Pod MTU，先保证正确性。还有一条常常被忽略:不管走哪条路，改完之后都要用大包实测验证，而不是改完就认为解决了。测的方法很简单——用禁止分片的大包，从 Pod 到 Pod、跨节点、跨网段各测一遍，全部通过才算闭环。

流日志的成本：全量采集与只留丢弃流的差距

Hubble 这类基于 eBPF 的流日志能力，是很多人决定上 Cilium 的直接理由。它能给出传统网络方案很难拿到的东西:每一个流是从哪个 Pod 到哪个 Pod、走的是什么协议、策略判定结果是允许还是丢弃、如果是丢弃那么是被哪条策略的哪一条规则拒的、甚至 HTTP 层的方法和路径。这些信息在排查网络策略问题时价值极高，因为过去的做法只能靠抓包和人肉推理，现在可以直接读出结论。

但流日志不是免费的，它的成本由三个变量决定:采样率、保留时长、存储后端。全量采集意味着每一个流都产生一条记录，在连接数高的集群里这个量级是惊人的;保留时长决定了存储总量;存储后端决定了写入本身会不会反过来影响集群。三者相乘的结果，可以从"几乎无感"到"显著占用资源"，跨度很大。所以这里没有标准答案，只有与你的规模和问题类型匹配的取舍。

一个实用的分档思路是这样的:如果你正在排查一个具体的连通性问题，临时开全量、短保留、用完即关，成本可控且信息最全;如果你要做长期的安全审计或者合规留存，那就要认真设计采样率和存储，不能默认全量;如果你只是想在网络出问题时知道"是谁被丢了"，那么只保留丢弃流(也就是策略判定为拒绝的那些流)就够了——丢弃流在总量里占比通常很低，但它恰恰包含了绝大部分排障所需的信息。

把这两者做个直接对比:全量采集适合短期的深度排查和取证，代价是资源占用与存储压力，且在高连接数集群上可能反过来影响业务;只留丢弃流适合常态化的运行期观测，代价是看不到正常流量的分布，遇到"没有丢包但就是慢"这类性能问题时信息不足。比较务实的做法是常态只留丢弃流加低比例采样，遇到问题时临时提升采样率并缩短保留时长。此外要注意流日志里可能包含请求级的元数据，如果业务有数据合规要求，采集范围和保留策略需要提前过一遍合规口径。

L7 网络策略不是免费的：代理介入的延迟账

Cilium 的网络策略支持 L3/L4，也支持基于 HTTP、gRPC 这类应用层协议的 L7 策略。L3/L4 策略的判定发生在包转发路径上，判定依据是地址、端口、协议，成本很低。L7 策略不一样——要判断"这个请求是不是 GET /api/order"，就必须理解应用协议，而理解应用协议意味着要把流量交给一个代理去解析。代理通常在用户态，于是流量路径从"内核转发"变成"内核转发 + 走到用户态代理 + 回到内核"，多出来的这一段就是额外的延迟与资源开销。

这笔延迟账要算清楚。额外的延迟量级取决于代理的实现、请求大小、并发量以及机器的负载情况，无法给出一个通用数字，但它的方向是确定的:每个请求都要多走一跳用户态，在延迟敏感的服务上会被放大。资源开销同样确定:代理本身要占 CPU 和内存，在高 QPS 服务上这部分开销可能会明显到需要为它单独预留资源。所以在容量规划时，开了 L7 策略的节点不能按没开时的规格来配。

因此有一条明确的建议:L7 策略不要对全部服务无差别开启。合理的做法是按服务分级——对真正需要应用层控制的少数服务开启，比如对外暴露的 API 网关、涉及敏感数据的服务、需要按路径或方法做严格隔离的服务;对内部大量同构的、信任边界清晰的后台服务，用 L3/L4 策略就够了。无差别开启的结果是延迟整体上升、资源占用整体上升，而安全收益集中在少数几条策略上，投入产出比很差。

还有两个实操上的坑。第一，L7 策略的判定结果和 L3/L4 混在一起时，排障顺序要从 L7 往回看:先确认是不是被应用层规则拒的，再看是不是被网络层规则拒的，否则容易在错误的层级上花时间。第二，如果服务使用了加密通信，代理要能看到明文就必须介入加密，这会牵扯到证书与信任链的配置，复杂度再上一个台阶。是否值得为了 L7 可见性引入这一层，应该在方案评审阶段就定下来，而不是上线后再补。

eBPF map 常驻内存：按并发连接数怎么估

eBPF 的数据都放在 map 里，map 是内核里的一块常驻内存。Cilium 用到的 map 大致分几类:连接跟踪表、策略表、服务与后端表、以及各类辅助表。它们在规模增长时都会变大，而且这部分内存是常驻的——不会因为业务空闲而被回收。这意味着节点的内存规划里必须给它留一块，否则会出现"业务没涨多少但内存一直在涨"的现象。

怎么估?给一个可操作的方法。第一步，估算峰值并发连接数:可以从历史监控里取新建连接速率和连接平均存活时长，两者相乘是稳态并发数，再乘一个峰值系数。第二步，估算端点数:Pod 数量加上节点本身，策略表的规模与端点数相关。第三步，按"并发连接数对应连接跟踪表条目、端点数对应策略表条目"去粗估条目总量，再乘以单条目大小得到内存量级。单条目大小随版本和特性不同会有差异，具体数字以你所用版本的实际情况为准，这里的价值在于给你一个量级感，而不是精确值。

比内存占用更需要注意的是容量上限。很多 eBPF map 是有最大条目数限制的，配置里可以调整，但配多大需要有依据。容量不足时的表现不是"变慢"，而是"新连接被拒"——新建连接写不进 map，就被直接拒绝。这个现象和 conntrack 表满非常像，容易误判:你会以为是应用的问题或者网络的问题，实际上是容量规划的问题。所以监控里应该把 map 的使用率作为一项常规指标，而不是等到出故障才去看。

实操建议有三条。其一，在压测阶段就把并发连接数打到预期的峰值，观察 map 使用率与内存占用的变化曲线，得到自己环境里的真实斜率，而不是用别人的经验值。其二，给 map 容量设置合理的告警阈值，使用率到一定比例就告警，留出扩容的时间窗。其三，节点规格选择上要为这部分预留余量——同样核数内存更大的机型，在跑 Cilium 且连接数高的场景下差别是明显的。这一点在做服务器租用选型时尤其值得算进去，内存往往比 CPU 更早成为瓶颈。

替代 kube-proxy 之后：排障经验为什么全部失效

Cilium 可以替代 kube-proxy，用 eBPF 在 socket 层做服务转发。原理是在连接建立的那一刻就把目标地址改写成后端 Pod 的地址，于是数据包不需要再走一遍 NAT 和内核转发的完整路径。收益是双重的:路径短了，延迟降低;不再依赖 iptables 的规则表，也就没有了前面讨论的那些规模问题。对于 Service 数量大、服务间调用频繁、对延迟敏感的业务，这是很实在的收益。

但它带来一个组织层面的代价，这个代价往往被低估:团队过去积累的所有 iptables 排障经验，在切换之后全部失效。`iptables -L` 看不到东西了，`conntrack -L` 里没有你预期的条目了，NAT 表是空的，以前那套"看规则—数条目—对计数"的手法没有用武之地。遇到转发问题时，你要看的不再是规则，而是 eBPF 程序有没有被正确挂载、map 里有没有正确的条目、socket 层的改写有没有生效。

工具链也必须换一套。Cilium 自带的命令行工具可以查看组件状态、map 内容、策略判定;eBPF 生态里的通用工具可以查看系统上加载了哪些 eBPF 程序、它们挂在哪里;抓包依然有效，但抓的位置和理解方式不一样了——因为数据包在 socket 层就已经被改写，你在网卡上看到的目的地址可能已经不是应用以为的那个地址。这类"看到的东西和预期不一样"的困惑，如果没有提前的心理准备和知识准备，会在第一次故障时被放大成"这个方案不靠谱"的结论。

还有一个容易被忽视的切换风险:混用。如果集群里一部分节点走了新的转发路径，另一部分还保留旧的行为，跨节点的流量会出现两种语义并存的状态，排查难度比任何一种单一状态都高。所以切换要做就做完整、做彻底，并且选择合适的时间窗。同样地，那些依赖 iptables 做自定义规则的场景——比如节点上跑了额外的防火墙脚本、额外的 NAT 规则、额外的流量标记——在切换之前要逐条确认它们是否仍然生效，不要假定。

团队能力门槛：至少要有人能读懂流日志

前面所有技术点最后都会收敛到一个人的问题上:出了故障，谁来看?在 iptables 时代，这个问题几乎不需要回答，因为能看懂规则的人很多;在 eBPF 时代，这个问题必须提前回答，因为能读懂流日志和策略判定结果的人相对少。给出一条明确的门槛判断:团队里至少要有一个人，能够在不看文档的情况下读懂一条流日志里的每一列含义，并且能根据策略判定结果反推出"为什么这条流被拒"，最好有第二个人能达到同样的水平作为备份。

为什么这条门槛是硬的?因为故障定位时间会被直接拉长。网络故障的影响是按分钟计的，一个能在五分钟内定位的人和一个需要查两小时文档的人，对业务的影响差距是数量级的。更麻烦的是，eBPF 层面的问题往往不指向明确的错误信息——它表现为"不通"或者"慢"，而不是"某某模块报错"。没有解读能力的人面对这种情况，最常见的反应是重启、是回滚、是换方案，而这三种反应都会掩盖真正的根因，导致问题下次再犯。

能力怎么建?给一个可执行的路径。第一步，在测试环境里故意制造几类典型故障——策略写错导致拒绝、MTU 配错导致大包不通、map 打满导致新连接被拒——然后不看答案，只靠工具把它们定位出来，记录每一步花了多长时间。第二步，把定位过程写成团队内部的排查手册，包含命令、输出样例和判读方法。第三步，把流日志的关键指标接进日常监控，让团队在没有故障的时候也习惯看这些数据。三步做完，能力才算落地，而不是停留在"有人看过文档"。

如果团队确实不具备这个能力，也有现实的选项:选择规模不大、特性不激进的部署方式，只用基础转发和 L3/L4 策略，不开 L7、不做 kube-proxy 替代、不追求全量流日志，把复杂度压到团队能兜住的范围;或者把网络和应用的边界划清楚，遇到网络层问题有明确的升级路径和外部支持。承认能力边界并据此设计，比硬上全套特性然后出问题要务实得多。这不是保守，而是工程上的诚实。

五类集群规模下的落点

前文的取舍最终要落到"我这个集群该怎么办"。下表按集群规模分成六个档位，给出各自的落点建议。需要说明的是:预算一列是参考预算区间，不是报价，实际价格随配置、机房、带宽与合同周期浮动，具体以咨询为准;内核版本一列是常见门槛区间，以官方文档为准;单节点规格形态描述的是这一类集群里常见的选型方向，不代表唯一解。

读这张表时重点看最后一列的主要风险，以及"是否建议开启全量流日志"这一列——这两列合起来基本决定了方案在你的环境里是加分还是减分。规模小的档位，风险主要来自过度设计;规模大的档位，风险主要来自容量与团队能力。同样的技术，在不同规模上的主要矛盾是不一样的。

什么时候不该上 Cilium：五条量化劝退条件

技术选型里最有价值的部分往往不是"什么时候该上"，而是"什么时候不该上"。下面是五条明确条件，满足其中任意一条，都应该重新评估或者推迟计划。这些条件都写成了可判定的形式，方便你直接对照自己的环境打勾，而不是靠感觉权衡。

第一条，集群节点数在个位数。这个规模下 iptables 的规则总量通常在几百到几千条，单包匹配成本和全表重建开销都不构成问题，Cilium 的核心收益无法兑现，而它的成本——内核要求、MTU 核对、新工具链——一样都不少。节点数在个位数且没有明确的扩张计划时，不建议上。

第二条，Service 数量很少，比如长期在几十个以内。这条和第一条是同一个逻辑的另一面:收益来自规模，规模不够就没有收益。判断时别只看当下的 Service 数，也看半年内的规划——如果明确会在几个月内涨到几百上千，那提前上是合理的;如果没有这个预期，就别为了技术先进性买单。

第三条，内核版本无法升级。这条是硬门槛。无论是因为发行版限制、合规要求、还是业务软件与内核版本的绑定关系，只要内核版本停在不支持所需特性的位置，就要接受功能缺失，并且把缺失项写进设计。如果缺失的恰好是你最想要的那部分——比如 kube-proxy 替代——那这个方案的立论基础就不成立了，应该重新考虑。

第四条，团队没有 eBPF 排障经验且短期内无法建立。判断标准就是前面那一条:有没有人能在不看文档的情况下读懂流日志并反推策略判定。如果答案是"没有，而且未来几个月也没有时间培养"，那么请把特性范围压到最小，或者推迟。网络方案的可靠性不只取决于软件，也取决于出问题时能不能快速定位。

第五条，依赖大量 iptables 自定义规则。有些节点上跑了额外的防火墙脚本、流量标记、自定义 NAT 或者其他基于 iptables 的机制，这些东西在新方案下的行为需要逐条验证。如果这些规则数量多、来源杂、缺少文档，验证成本会非常高，而且验证不彻底带来的问题是随机出现的。这种情况下建议先做一次规则清点与治理，把依赖收敛清楚之后再谈迁移。

Cilium 切换前要打勾的十五项验收

把前面所有内容压缩成一份可以照着执行的清单。这份清单适用于首次上线和版本升级两种场景，建议打印出来逐条打勾，而不是凭记忆过一遍。每一条都对应前文的一个风险点，跳过任何一条都可能带来一次代价不小的故障。

清单的使用方式:前六项属于环境准备，必须在部署之前完成;第七到十一项属于配置核对，部署时完成;第十二到十五项属于验证与兜底，必须在切流量之前完成。三类之间不要颠倒顺序——很多问题之所以到线上才暴露，就是因为把配置核对留到了验证阶段。

1. 核对内核版本:对照所用 Cilium 版本的官方文档特性矩阵，逐条确认计划启用的每个特性各自要求的最低内核版本，取最大值作为门槛。
2. 核对内核编译配置:确认 BPF 与 BPF 系统调用、网络调度器对 BPF 的支持、cgroup 相关钩子等配置项已在目标内核中打开，而不是只看版本号。
3. 统一内核与组件版本基线:集群内所有节点的操作系统内核版本、Cilium 版本保持一致，并把低版本节点禁止入集群这条检查写进装机模板。
4. 记录一份状态输出基线:部署完成后保存组件状态与特性启用情况的完整输出，作为后续升级的对比基准，重点关注被标记禁用或不支持的条目。
5. 核对 MTU:确认封装模式与封装开销，算出 Pod 侧应设的 MTU，并确认底层链路 MTU 的实际值，两者相加不超过链路能力。
6. 实测路径 MTU:用禁止分片的大包从 Pod 到 Pod、跨节点、跨网段各测一遍，全部通过才算闭环，不要改完配置就认为解决了。
7. 确认封装与路由模式:明确采用覆盖网络封装还是原生路由，两种模式的 MTU、性能、对底层网络的要求都不同，选定后配置要与选型一致。
8. 规划 eBPF map 容量:按峰值并发连接数与端点数估算条目量，设置上限并配置使用率告警，明确容量不足时的表现是新连接被拒。
9. 规划流日志策略:确定采样率、保留时长与存储后端，常态建议丢弃流加低比例采样，全量仅用于短时取证，并预留对应存储资源。
10. 确定 L7 策略范围:按服务分级列出需要 L7 策略的清单，明确不为全部服务无差别开启，并为启用代理的节点预留额外 CPU 与内存。
11. 清点 iptables 依赖:逐条列出节点上现有的自定义 iptables 规则与脚本，评估在切换后是否仍然生效，不生效的要有替代方案。
12. 压测到峰值:把并发连接数打到预期峰值，观察 map 使用率、内存占用、延迟变化，得到本环境的真实曲线。
13. 演练典型故障:在测试环境制造策略拒绝、MTU 错误、map 打满三类故障，计时定位过程，并输出团队内部的排查手册。
14. 确认能力门槛:至少两人能独立读懂流日志并反推策略判定结果，达不到就缩小特性范围，不要带着能力缺口上线。
15. 准备回滚路径:明确回滚的触发条件、执行步骤与验证方法，并在时间窗内实际演练一次，确认回滚后业务能立刻恢复。

这十五项里，最容易被跳过的是第五、六两项(MTU)和第十三项(故障演练)。MTU 容易被跳过是因为它在小规模测试里几乎不出问题，只有真实流量上来了才暴露;故障演练容易被跳过是因为它不产生直接产出，看起来像练兵。但恰恰是这两项，决定了上线之后的第一个月是平稳的还是焦头烂额的。

Cilium 内核功能矩阵需要你逐项比对

为了保证结论可用，这里明确划出本文的能力边界。文中所有版本号——包括内核版本门槛、Cilium 各特性对内核的要求——都是社区常见门槛区间，用于帮你建立判断框架，不能替代官方文档。Cilium 的内核要求会随版本迭代调整，同一特性的要求可能在新版本里放宽也可能收紧，动手之前请打开你所用版本的官方文档特性矩阵逐条比对。所有字节数——包括 VXLAN 与 Geneve 的封装开销——都是常见量级，实际值取决于封装模式、是否带选项字段、是否叠加加密，以你的实际配置为准。

还有几类数字本文刻意没有给出。第一类是性能提升的具体倍数或百分比:这类数字对硬件、内核版本、流量模型、特性开关高度敏感，脱离环境谈倍数没有意义，所以本文只讲成本增长曲线的斜率变化这个方向性结论。第二类是资源占用的精确数值:eBPF map 的单条目大小、流日志的单条记录大小都会随版本变化，本文给的是估算方法而不是结果值。第三类是价格:文中表格里的预算一列已标注为参考预算区间，实际价格随机房、配置、带宽、合同周期浮动，以咨询为准，不要当作报价使用。

需要你动手复核的部分集中在四处。其一，内核版本与编译配置:在目标机器上实测，不要照抄文档或本文。其二，MTU 与封装开销:确认自己的封装模式，算出实际开销，再用禁止分片的大包沿完整路径实测。其三，eBPF map 容量与内存:在压测中拿到自己环境的真实斜率，而不是套用经验值。其四，团队能力:用一次不看答案的故障演练来验证，而不是用"看过文档"来代替。这四项做完，本文的结论才算在你的环境里成立。

最后说明本文的立场与适用范围。本文讨论的是技术选型与落地风险，不构成对任何具体产品的推荐;涉及的方案取舍，都要回到你自己的规模、内核条件、团队能力与业务特征上重新判断。一万网络(天下数据，官网 idc10000.net)深耕 19 年(成立于 2007 年)，提供中国大陆、中国香港、中国台湾等地区的服务器租用与托管资源，可按需指定操作系统版本与内核基线——如果你在核对本文第三、四项时发现现有环境的内核版本或网络链路条件不满足，欢迎就机型、操作系统模板与网络配置做一次具体咨询，把内核与 MTU 这两个前置条件在下单阶段就确认清楚，比交付后再返工要省心得多。