【Cilium / eBPF】关键 BPF Map：policy、service、CT 的职责与失败表象
内容提要
本文介绍Cilium v1.20的BPF Map状态轴，涵盖Policy、Service、CT/NAT等核心表职责、默认上限及满表故障表象。强调排障先定位具体表，注意动态容量调整与NAT/CT约束，并指出升级世代切换和容量规划纪律的重要性。
延伸解读
排障先定位表，再改参数
文章强调，遇到网络故障时，应先根据症状判断是哪张 BPF Map 出了问题，而不是盲目修改配置。例如，策略拒绝应查 policy map 和 ipcache，Service 不通应查 LB services 和 backends，突发新建连接失败应查 CT 表。改 NetworkPolicy 解决不了 LB map 满的问题，加大 CT 也解决不了 identity 未解析。正确的做法是先用包路径停顿点缩小范围，再针对具体表做假设，避免同时调整多个 --bpf-*-max 参数。
容量规划需考虑动态调整与约束
Cilium 提供固定上限和动态 sizing 两种容量配置方式，但各有风险。固定上限便于预测，但估小则故障，估大则浪费内存；动态 sizing 随节点内存伸缩，但不同节点上限可能不一致，增加排障难度。此外，文档明确硬约束：若显式设定 CT 上限，NAT 表不得超过 CT（TCP+UDP）合计的 2/3，否则生命周期会错配。规划时需结合业务规模，对离群 Service 单独核算，避免上线后因容量不足引发变更事故。
升级与扩容需注意世代切换与中断风险
文章指出，Cilium v1.20 的 policy map 使用 v3 前缀，对应身份聚合语义的变化，升级时可能因 map 世代切换导致已有连接异常。此外，LB map 在首次创建后若调整大小并重启，会中断连接并重填，因此容量规划应提前写入安装参数，而不是上线后临时修改。团队故障手册若仍依赖检查 iptables 规则条数，在 KPR 集群上会系统性漏掉 Map 轴，需补充 map 压力信号相关检查项。
Q&A
Cilium 中 Policy BPF Map 的作用是什么？默认上限是多少？满了会出现什么现象？
Policy BPF Map 用于存储每个 endpoint 允许的 identity+port+protocol 对，默认上限为 16k。当表满时，特定 Pod 在策略变复杂后可能开始拒绝合法对端。
Cilium 的 Service Load Balancer Map 满了会有什么影响？如何调整大小？
Service LB Map 默认上限为 64k，满了可能导致无法 reconcile Service 更新，影响连通到 Service IP 或创建新 Service。可通过 --bpf-lb-map-max 调整，但文档警告 map 创建后改大小并重启会导致重填期间连接中断。
Cilium 的 CT 和 NAT Map 分别负责什么？它们之间有什么约束？
CT Map 跟踪连接状态，NAT Map 处理 SNAT/DNAT 条目。文档硬约束：若显式设定 CT 上限，NAT 表不得超过 CT（TCP+UDP）合计的 2/3，否则 NAT 与 CT 生命周期会错配。
Cilium 中 ipcache Map 的作用是什么？它满了或陈旧时会出现什么问题？
ipcache Map 负责 IP 到 Identity 的解析。缓存滞后会导致身份窗口、跨节点策略误判、陈旧身份等问题。
Cilium 排障时如何根据症状定位到具体的 BPF Map？
根据症状定位：policy deny 或 label change 查 policy map + ipcache；Service VIP 或 NodePort 故障查 LB services + backends；突发新连接失败查 CT；本地投递失败查 endpoints map；升级异常查 map 世代。
Cilium 的 BPF Map 容量规划有哪些注意事项？
容量规划需注意：LB map 首次创建后改大小并重启会中断连接，因此应提前按启发式估算后端×端口积，对离群 Service 单独核算；同时注意 NAT 表不得超过 CT 合计的 2/3；动态 sizing 与固定上限各有风险，需根据实际选择。
