Cilium eBPF Maps 容量规划与调优指南默认上限、动态尺寸与 Service LB 映射规模计算【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/ciliumeBPF Maps 是 Cilium 数据通路datapath的核心存储结构连接跟踪、NAT、策略、负载均衡等关键能力都依赖这些内核映射而每个 Map 都带有上限容量。本文以 Documentation/network/ebpf/maps.rst 为主线系统梳理 Cilium 各类 BPF Map 的默认容量、作用域与扩展性含义讲解如何通过cilium-agent命令行参数覆盖默认上限、利用--bpf-map-dynamic-size-ratio依据系统内存自动计算容量并给出 Service Load Balancer Map 的精确容量估算公式与扩容注意事项。读完本文你将能根据节点规模为 Cilium 数据通路做出合理的容量规划与调优决策。eBPF Maps 与容量上限的基本概念Cilium 将所有 BPF Map 创建为带有**上限容量upper capacity limit**的映射。当插入条目的数量超过该上限时插入操作会失败进而限制数据通路的扩展能力。因此容量规划是部署 Cilium 前必须考虑的问题每个限制都可以在源码中调整cilium-agent也提供了对应的命令行选项配置选项会按需陆续补充。各 Map 的容量上限与扩容影响体现在数据通路实际处理连接、转发数据包和加载策略的各个环节。下面先看核心 Map 的默认上限总表再逐一展开容量覆盖与动态计算机制。BPF Map 默认上限总表下表汇总了 Cilium 各类 BPF Map 的默认上限值、作用域Scope与扩展性含义数据来源于 maps.rstMap 名称作用域默认上限扩展性含义Auth认证node512k每个节点最多 512k 条已认证关系Connection Tracking连接跟踪node512k TCP / 256k UDP每个节点最多 512k 条并发 TCP 连接、256k 条预期的 UDP 应答NATnode512k最多 512k 条 NAT 条目Neighbor Table邻居表node512k最多 512k 条邻居条目Endpoints端点node64k每个节点最多 64k 个本地端点 主机 IPIP cachenode512k跨所有集群最多 256k 个端点IPv4IPv6 混合或最多 512k 个端点仅 IPv4 或仅 IPv6Service Load Balancer服务负载均衡node64k跨所有集群最多约 3k 个 clusterIP/nodePort Service详见下文 Service LB Map Sizing 一节Service Backends服务后端node64k跨所有集群的所有服务累计最多 64k 个唯一后端Service Source Rangesnode64k跨所有服务累计最多 64k 条 LB 源地址范围Service Session Affinitynode64k来自不同客户端的最多 64k 条亲和性记录Policy策略endpoint16k单个特定端点的最多 16k 个身份 端口 协议允许组合IPv4 FragmentationIPv4 分片node8k节点上同时最多 8k 个在途分片数据报IPv6 FragmentationIPv6 分片node8k节点上同时最多 8k 个在途分片数据报IPv4 Masqnode16k供 BPF 版 ip-masq-agent 使用的最多 16k 条 IPv4 CIDRIPv6 Masqnode16k供 BPF 版 ip-masq-agent 使用的最多 16k 条 IPv6 CIDREgress Policy出站策略node16k跨所有集群的所有目标 CIDR 上最多 16k 个端点Nodenode16k跨所有集群最多 16k 个不同的节点 IPIPv4 与 IPv6从上表可以归纳出几个规划要点作用域差异绝大多数 Map 是节点级node共享的唯独 Policy Map 是**每端点endpoint**独立的——它的上限16k表示单个端点最多允许的策略组合数而非整个节点。连接跟踪是扩容瓶颈CTConnection TrackingMap 的 TCP/UDP 分离设计512k TCP 256k UDP直接决定了节点能支撑的最大并发连接数。负载均衡相关 Map 的规模Service LB、Backends、Source Ranges、Session Affinity 四个 Map 都受服务规模约束具体估算方法见后文。从源码确认默认值这些默认上限在 pkg/option/config.go 中以常量形式定义例如CTMapEntriesGlobalTCPDefault 2 18即 512Ki 条目对应文档的 512k TCPCTMapEntriesGlobalAnyDefault 2 17即 256Ki 条目对应 256k UDPNATMapEntriesGlobalDefault int((CTMapEntriesGlobalTCPDefault CTMapEntriesGlobalAnyDefault) * 2 / 3)即默认按 CT 合计的 2/3 计算PolicyMapMax 1 16、FragmentsMapMax 1 16等见 pkg/option/config.go。同时pkg/datapath/maps/maps_generated.go中登记了各 Map 的实际内核名称如cilium_ct4_global、cilium_ct6_global、cilium_ct_any4_global、cilium_ct_any6_global、cilium_auth_map、cilium_lb4_services_v2、cilium_snat_v4_external、cilium_nodeport_neigh4等见 maps_generated.go可用于在节点上通过bpftool map list对照检查实际生效的容量。使用命令行参数覆盖 Map 容量上限对于部分 BPF Map可以通过cilium-agent的命令行选项覆盖默认容量上限。文档明确支持的参数包括命令行选项作用--bpf-auth-map-maxAuth Map 最大条目数--bpf-ct-global-tcp-max全局 TCP 连接跟踪 Map 最大条目数--bpf-ct-global-any-max全局非 TCPUDP 等连接跟踪 Map 最大条目数--bpf-nat-global-maxNAT Map 最大条目数--bpf-neigh-global-max邻居表 Map 最大条目数--bpf-policy-map-max每端点策略 Map 最大条目数--bpf-fragments-map-max分片 Map 最大条目数--bpf-lb-map-maxService Load Balancer Map 最大条目数这些选项在源码中有完整登记CT/NAT/Neigh 选项定义于 pkg/option/config.goCTMapEntriesGlobalTCPName bpf-ct-global-tcp-max、NATMapEntriesGlobalName bpf-nat-global-max、NeighMapEntriesGlobalName bpf-neigh-global-max等并在Populate阶段通过vp.GetInt(...)读取后写入DaemonConfig见 pkg/option/config.go--bpf-lb-map-max定义于 pkg/loadbalancer/config.go--bpf-policy-map-max定义于 pkg/maps/policymap/cell.go。CT 与 NAT 表之间的 2/3 约束这里有一条容易被忽略的硬性约束当显式指定了--bpf-ct-global-tcp-max和/或--bpf-ct-global-any-max时NAT 表大小--bpf-nat-global-max不得超过组合 CT 表大小TCP UDP的 2/3。以下两种情况会自动生效未显式设置--bpf-nat-global-max使用了动态 BPF Map 尺寸见下文。源码层面的实现位于 pkg/option/config.go当 NAT 大小超过CTMapEntriesGlobalTCP CTMapEntriesGlobalAny时会自动封顶为(CTMapEntriesGlobalTCP CTMapEntriesGlobalAny) * 2 / 3并输出告警日志。此外pkg/option/config.go 的校验逻辑还保证 CT/NAT 条目数落在LimitTableMin1Ki到LimitTableMax16Mi即单个 Map 约 1GiB 条目之间超出范围会直接报错。一个配置示例假设要为每节点 8 vCPU、30GiB 内存的节点显式配置容量cilium-agent \ --bpf-ct-global-tcp-max524288 \ --bpf-ct-global-any-max262144 \ --bpf-nat-global-max524288 \ --bpf-neigh-global-max524288 \ --bpf-policy-map-max16384 \ --bpf-lb-map-max65536注意此时 NAT 表524288不能超过 CT 合计524288 262144的 2/3即最大应为 524288示例中恰好满足约束。基于内存的动态 Map 尺寸--bpf-map-dynamic-size-ratio手动规划每个 Map 的上限既繁琐又容易出错。Cilium 提供了--bpf-map-dynamic-size-ratio选项在 agent 启动时根据给定比例的系统总内存自动确定多个大型 BPF Map 的上限。例如比例0.0025表示这些 Map 最多使用系统总内存的 0.25%。该选项影响以下内存占用最大的 BPF Mapcilium_ct_{4,6}_globalTCP 连接跟踪cilium_ct_{4,6}_anyUDP/任意协议连接跟踪cilium_nodeport_neigh{4,6}NodePort 邻居表cilium_snat_v{4,6}_external外部 SNATcilium_lb{4,6}_reverse_sksock reverse NAT这些内核 Map 名称均可在 pkg/datapath/maps/maps_generated.go 中找到对应登记。动态计算原理源码级动态尺寸的计算逻辑位于 pkg/option/config.go 的getDynamicSizeCalculator计算可用内存memoryAvailableForMaps totalMemory * dynamicSizeRatio计算默认内存基线将各 Map 默认条目数乘以其单元素大小SizeofCTElement、SizeofNATElement、SizeofNeighElement、SizeofSockRevElement求和得到totalMapMemoryDefault按比例分配每个 Map 的条目数按(entriesDefault * memoryAvailableForMaps) / totalMapMemoryDefault计算并受最小值如 TCP CT 为 128Ki、UDP CT 为 64Ki、NAT 为 128Ki与最大值LimitTableMax约束CPU 对齐启用分布式 LRU 时条目数会向上取整到num_possible_cpus()的倍数与内核htab_map_alloc()的行为保持一致避免 Map 属性不匹配导致反复重建见 pkg/option/config.go。注释中还给出了直观的计算示例512MB 内存 → CT TCP 约 33140 条1GB → 约 66280 条4GB → 约 265121 条16GB → 约 1060485 条。显式设置优先如果某个 Map 已通过命令行选项显式指定则动态尺寸对该 Map 失效使用用户提供的值见calculateDynamicBPFMapSizes中if !vp.IsSet(...)的分支逻辑pkg/option/config.go。与 kube-proxy 的连接跟踪对比kube-proxy根据机器 CPU 核数设置 Linux 连接跟踪表nf_conntrack的最大条目数每个核默认 32768 条且无论核数多少最低为 131072 条。Cilium 则有自己基于 BPF Map 的连接跟踪表条目数根据节点总内存计算且无论内存多少最低为 131072 条。当 Cilium 配置--bpf-map-dynamic-size-ratio: 0.0025时两种方案的连接跟踪条目数对比如下数据来自 maps.rstvCPU内存GiBKube-proxy CT 条目Cilium CT 条目13.7513107213107227.51310721310724151310721310728302621442845601660524288569120321201048576113824064240209715222764809636031457284552960可以观察到小内存节点上两者都收敛于 131072 的下限从 8 vCPU / 30GiB 开始Cilium 由于基于内存而非核数计算CT 条目数开始超过 kube-proxy且在内存增长更快的高端节点上优势更明显96 vCPU / 360GiB 时 Cilium 约 455 万条而 kube-proxy 约 314 万条。这印证了 BPF 数据通路在高并发场景下连接跟踪容量的扩展性优势。Service LB Map Sizing服务负载均衡容量估算核心 Map 与容量影响Cilium 使用名为cilium_lb{4,6}_services_v2的 LB services Map 存放 clusterIP 与 nodePort 类型的 Service 负载均衡条目通过--bpf-lb-map-max配置默认 64k。如果该 Map 写满Cilium 可能无法对 Service 更新进行调和reconcile从而影响 Service IP 的连通性或导致无法创建新 Service。在节点上可通过bpftool map list | grep cilium_lb找到cilium_lb4_services_v2/cilium_lb6_services_v2两个实例对应 maps_generated.go 中的登记。容量计算公式单个 Service 在 LB Map 中产生的条目数取决于两个因素Service 选中的 Pod 后端数量以及Service spec 中的端口/协议条目数量每个 Service 的 LB Map 条目数 每个 Service 的端点数量×每个 Service 的端口/协议数量由此可以粗略估算所需的整体 Map 大小LB Map 条目数 ≈LB Service 数量×每个 Service 的平均端点数量×每个 Service 的平均端口/协议数量例如假设有 1000 个 Service平均每个 Service 选中 3 个 Pod 后端、暴露 2 个端口/协议则所需条目约为1000 × 3 × 2 6000远低于 64k 默认上限但如果单个 Service 选中了数千个 Pod 后端则必须单独核算。注意该启发式估算假设各 Service 选中的 Pod 数量与端口/协议条目大致呈正态分布。如果你的场景存在较大离群值例如某个 Service 选中了非常庞大的 Pod 后端集合则可能需要做更精确的逐项估算。扩容的代价连接中断风险一旦 Cilium 在某个节点上创建了 Service LB Map即该节点首次运行 Cilium agent 之后再尝试修改容量参数并重启 Cilium将导致连接中断——因为新 Map 需要重新填充现有 Service 条目。因此如果连接中断不可接受务必在安装 Cilium 之前仔细评估 Map 需求将容量规划前置。小结与容量规划建议规划要点建议默认上限足够大多数场景512k CT、512k NAT、64k Service LB 是常见节点规模的合理起点高并发节点优先用动态尺寸通过--bpf-map-dynamic-size-ratio0.0025让 agent 按内存自动分配避免手工估算显式配置必须满足 CT/NAT 2/3 约束NAT 表 ≤ (CT TCP CT UDP) × 2/3否则会被自动封顶或启动校验失败Service 规模巨大时提前核算使用Service 数 × 平均后端数 × 平均端口数估算cilium_lb{4,6}_services_v2所需容量扩容动作尽量前置首次运行 agent 后调整 LB Map 容量并重启会中断连接尽量在安装阶段定稿参考源码核对实际生效值常量默认值见 pkg/option/config.goMap 内核名称见 pkg/datapath/maps/maps_generated.go容量规划的核心原则是默认值适合作为起点动态尺寸适合作为通用基线显式覆盖用于已知的极端场景而 Service LB 必须结合真实服务拓扑在部署前完成核算。理解这些 Map 上限及其背后的源码实现pkg/option/config.go 中的默认常量、校验与动态计算逻辑将帮助你在规模增长时做出有依据的调优决策。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cilium eBPF Maps 容量规划与调优指南：默认上限、动态尺寸与 Service LB 映射规模计算
Cilium eBPF Maps 容量规划与调优指南默认上限、动态尺寸与 Service LB 映射规模计算【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/ciliumeBPF Maps 是 Cilium 数据通路datapath的核心存储结构连接跟踪、NAT、策略、负载均衡等关键能力都依赖这些内核映射而每个 Map 都带有上限容量。本文以 Documentation/network/ebpf/maps.rst 为主线系统梳理 Cilium 各类 BPF Map 的默认容量、作用域与扩展性含义讲解如何通过cilium-agent命令行参数覆盖默认上限、利用--bpf-map-dynamic-size-ratio依据系统内存自动计算容量并给出 Service Load Balancer Map 的精确容量估算公式与扩容注意事项。读完本文你将能根据节点规模为 Cilium 数据通路做出合理的容量规划与调优决策。eBPF Maps 与容量上限的基本概念Cilium 将所有 BPF Map 创建为带有**上限容量upper capacity limit**的映射。当插入条目的数量超过该上限时插入操作会失败进而限制数据通路的扩展能力。因此容量规划是部署 Cilium 前必须考虑的问题每个限制都可以在源码中调整cilium-agent也提供了对应的命令行选项配置选项会按需陆续补充。各 Map 的容量上限与扩容影响体现在数据通路实际处理连接、转发数据包和加载策略的各个环节。下面先看核心 Map 的默认上限总表再逐一展开容量覆盖与动态计算机制。BPF Map 默认上限总表下表汇总了 Cilium 各类 BPF Map 的默认上限值、作用域Scope与扩展性含义数据来源于 maps.rstMap 名称作用域默认上限扩展性含义Auth认证node512k每个节点最多 512k 条已认证关系Connection Tracking连接跟踪node512k TCP / 256k UDP每个节点最多 512k 条并发 TCP 连接、256k 条预期的 UDP 应答NATnode512k最多 512k 条 NAT 条目Neighbor Table邻居表node512k最多 512k 条邻居条目Endpoints端点node64k每个节点最多 64k 个本地端点 主机 IPIP cachenode512k跨所有集群最多 256k 个端点IPv4IPv6 混合或最多 512k 个端点仅 IPv4 或仅 IPv6Service Load Balancer服务负载均衡node64k跨所有集群最多约 3k 个 clusterIP/nodePort Service详见下文 Service LB Map Sizing 一节Service Backends服务后端node64k跨所有集群的所有服务累计最多 64k 个唯一后端Service Source Rangesnode64k跨所有服务累计最多 64k 条 LB 源地址范围Service Session Affinitynode64k来自不同客户端的最多 64k 条亲和性记录Policy策略endpoint16k单个特定端点的最多 16k 个身份 端口 协议允许组合IPv4 FragmentationIPv4 分片node8k节点上同时最多 8k 个在途分片数据报IPv6 FragmentationIPv6 分片node8k节点上同时最多 8k 个在途分片数据报IPv4 Masqnode16k供 BPF 版 ip-masq-agent 使用的最多 16k 条 IPv4 CIDRIPv6 Masqnode16k供 BPF 版 ip-masq-agent 使用的最多 16k 条 IPv6 CIDREgress Policy出站策略node16k跨所有集群的所有目标 CIDR 上最多 16k 个端点Nodenode16k跨所有集群最多 16k 个不同的节点 IPIPv4 与 IPv6从上表可以归纳出几个规划要点作用域差异绝大多数 Map 是节点级node共享的唯独 Policy Map 是**每端点endpoint**独立的——它的上限16k表示单个端点最多允许的策略组合数而非整个节点。连接跟踪是扩容瓶颈CTConnection TrackingMap 的 TCP/UDP 分离设计512k TCP 256k UDP直接决定了节点能支撑的最大并发连接数。负载均衡相关 Map 的规模Service LB、Backends、Source Ranges、Session Affinity 四个 Map 都受服务规模约束具体估算方法见后文。从源码确认默认值这些默认上限在 pkg/option/config.go 中以常量形式定义例如CTMapEntriesGlobalTCPDefault 2 18即 512Ki 条目对应文档的 512k TCPCTMapEntriesGlobalAnyDefault 2 17即 256Ki 条目对应 256k UDPNATMapEntriesGlobalDefault int((CTMapEntriesGlobalTCPDefault CTMapEntriesGlobalAnyDefault) * 2 / 3)即默认按 CT 合计的 2/3 计算PolicyMapMax 1 16、FragmentsMapMax 1 16等见 pkg/option/config.go。同时pkg/datapath/maps/maps_generated.go中登记了各 Map 的实际内核名称如cilium_ct4_global、cilium_ct6_global、cilium_ct_any4_global、cilium_ct_any6_global、cilium_auth_map、cilium_lb4_services_v2、cilium_snat_v4_external、cilium_nodeport_neigh4等见 maps_generated.go可用于在节点上通过bpftool map list对照检查实际生效的容量。使用命令行参数覆盖 Map 容量上限对于部分 BPF Map可以通过cilium-agent的命令行选项覆盖默认容量上限。文档明确支持的参数包括命令行选项作用--bpf-auth-map-maxAuth Map 最大条目数--bpf-ct-global-tcp-max全局 TCP 连接跟踪 Map 最大条目数--bpf-ct-global-any-max全局非 TCPUDP 等连接跟踪 Map 最大条目数--bpf-nat-global-maxNAT Map 最大条目数--bpf-neigh-global-max邻居表 Map 最大条目数--bpf-policy-map-max每端点策略 Map 最大条目数--bpf-fragments-map-max分片 Map 最大条目数--bpf-lb-map-maxService Load Balancer Map 最大条目数这些选项在源码中有完整登记CT/NAT/Neigh 选项定义于 pkg/option/config.goCTMapEntriesGlobalTCPName bpf-ct-global-tcp-max、NATMapEntriesGlobalName bpf-nat-global-max、NeighMapEntriesGlobalName bpf-neigh-global-max等并在Populate阶段通过vp.GetInt(...)读取后写入DaemonConfig见 pkg/option/config.go--bpf-lb-map-max定义于 pkg/loadbalancer/config.go--bpf-policy-map-max定义于 pkg/maps/policymap/cell.go。CT 与 NAT 表之间的 2/3 约束这里有一条容易被忽略的硬性约束当显式指定了--bpf-ct-global-tcp-max和/或--bpf-ct-global-any-max时NAT 表大小--bpf-nat-global-max不得超过组合 CT 表大小TCP UDP的 2/3。以下两种情况会自动生效未显式设置--bpf-nat-global-max使用了动态 BPF Map 尺寸见下文。源码层面的实现位于 pkg/option/config.go当 NAT 大小超过CTMapEntriesGlobalTCP CTMapEntriesGlobalAny时会自动封顶为(CTMapEntriesGlobalTCP CTMapEntriesGlobalAny) * 2 / 3并输出告警日志。此外pkg/option/config.go 的校验逻辑还保证 CT/NAT 条目数落在LimitTableMin1Ki到LimitTableMax16Mi即单个 Map 约 1GiB 条目之间超出范围会直接报错。一个配置示例假设要为每节点 8 vCPU、30GiB 内存的节点显式配置容量cilium-agent \ --bpf-ct-global-tcp-max524288 \ --bpf-ct-global-any-max262144 \ --bpf-nat-global-max524288 \ --bpf-neigh-global-max524288 \ --bpf-policy-map-max16384 \ --bpf-lb-map-max65536注意此时 NAT 表524288不能超过 CT 合计524288 262144的 2/3即最大应为 524288示例中恰好满足约束。基于内存的动态 Map 尺寸--bpf-map-dynamic-size-ratio手动规划每个 Map 的上限既繁琐又容易出错。Cilium 提供了--bpf-map-dynamic-size-ratio选项在 agent 启动时根据给定比例的系统总内存自动确定多个大型 BPF Map 的上限。例如比例0.0025表示这些 Map 最多使用系统总内存的 0.25%。该选项影响以下内存占用最大的 BPF Mapcilium_ct_{4,6}_globalTCP 连接跟踪cilium_ct_{4,6}_anyUDP/任意协议连接跟踪cilium_nodeport_neigh{4,6}NodePort 邻居表cilium_snat_v{4,6}_external外部 SNATcilium_lb{4,6}_reverse_sksock reverse NAT这些内核 Map 名称均可在 pkg/datapath/maps/maps_generated.go 中找到对应登记。动态计算原理源码级动态尺寸的计算逻辑位于 pkg/option/config.go 的getDynamicSizeCalculator计算可用内存memoryAvailableForMaps totalMemory * dynamicSizeRatio计算默认内存基线将各 Map 默认条目数乘以其单元素大小SizeofCTElement、SizeofNATElement、SizeofNeighElement、SizeofSockRevElement求和得到totalMapMemoryDefault按比例分配每个 Map 的条目数按(entriesDefault * memoryAvailableForMaps) / totalMapMemoryDefault计算并受最小值如 TCP CT 为 128Ki、UDP CT 为 64Ki、NAT 为 128Ki与最大值LimitTableMax约束CPU 对齐启用分布式 LRU 时条目数会向上取整到num_possible_cpus()的倍数与内核htab_map_alloc()的行为保持一致避免 Map 属性不匹配导致反复重建见 pkg/option/config.go。注释中还给出了直观的计算示例512MB 内存 → CT TCP 约 33140 条1GB → 约 66280 条4GB → 约 265121 条16GB → 约 1060485 条。显式设置优先如果某个 Map 已通过命令行选项显式指定则动态尺寸对该 Map 失效使用用户提供的值见calculateDynamicBPFMapSizes中if !vp.IsSet(...)的分支逻辑pkg/option/config.go。与 kube-proxy 的连接跟踪对比kube-proxy根据机器 CPU 核数设置 Linux 连接跟踪表nf_conntrack的最大条目数每个核默认 32768 条且无论核数多少最低为 131072 条。Cilium 则有自己基于 BPF Map 的连接跟踪表条目数根据节点总内存计算且无论内存多少最低为 131072 条。当 Cilium 配置--bpf-map-dynamic-size-ratio: 0.0025时两种方案的连接跟踪条目数对比如下数据来自 maps.rstvCPU内存GiBKube-proxy CT 条目Cilium CT 条目13.7513107213107227.51310721310724151310721310728302621442845601660524288569120321201048576113824064240209715222764809636031457284552960可以观察到小内存节点上两者都收敛于 131072 的下限从 8 vCPU / 30GiB 开始Cilium 由于基于内存而非核数计算CT 条目数开始超过 kube-proxy且在内存增长更快的高端节点上优势更明显96 vCPU / 360GiB 时 Cilium 约 455 万条而 kube-proxy 约 314 万条。这印证了 BPF 数据通路在高并发场景下连接跟踪容量的扩展性优势。Service LB Map Sizing服务负载均衡容量估算核心 Map 与容量影响Cilium 使用名为cilium_lb{4,6}_services_v2的 LB services Map 存放 clusterIP 与 nodePort 类型的 Service 负载均衡条目通过--bpf-lb-map-max配置默认 64k。如果该 Map 写满Cilium 可能无法对 Service 更新进行调和reconcile从而影响 Service IP 的连通性或导致无法创建新 Service。在节点上可通过bpftool map list | grep cilium_lb找到cilium_lb4_services_v2/cilium_lb6_services_v2两个实例对应 maps_generated.go 中的登记。容量计算公式单个 Service 在 LB Map 中产生的条目数取决于两个因素Service 选中的 Pod 后端数量以及Service spec 中的端口/协议条目数量每个 Service 的 LB Map 条目数 每个 Service 的端点数量×每个 Service 的端口/协议数量由此可以粗略估算所需的整体 Map 大小LB Map 条目数 ≈LB Service 数量×每个 Service 的平均端点数量×每个 Service 的平均端口/协议数量例如假设有 1000 个 Service平均每个 Service 选中 3 个 Pod 后端、暴露 2 个端口/协议则所需条目约为1000 × 3 × 2 6000远低于 64k 默认上限但如果单个 Service 选中了数千个 Pod 后端则必须单独核算。注意该启发式估算假设各 Service 选中的 Pod 数量与端口/协议条目大致呈正态分布。如果你的场景存在较大离群值例如某个 Service 选中了非常庞大的 Pod 后端集合则可能需要做更精确的逐项估算。扩容的代价连接中断风险一旦 Cilium 在某个节点上创建了 Service LB Map即该节点首次运行 Cilium agent 之后再尝试修改容量参数并重启 Cilium将导致连接中断——因为新 Map 需要重新填充现有 Service 条目。因此如果连接中断不可接受务必在安装 Cilium 之前仔细评估 Map 需求将容量规划前置。小结与容量规划建议规划要点建议默认上限足够大多数场景512k CT、512k NAT、64k Service LB 是常见节点规模的合理起点高并发节点优先用动态尺寸通过--bpf-map-dynamic-size-ratio0.0025让 agent 按内存自动分配避免手工估算显式配置必须满足 CT/NAT 2/3 约束NAT 表 ≤ (CT TCP CT UDP) × 2/3否则会被自动封顶或启动校验失败Service 规模巨大时提前核算使用Service 数 × 平均后端数 × 平均端口数估算cilium_lb{4,6}_services_v2所需容量扩容动作尽量前置首次运行 agent 后调整 LB Map 容量并重启会中断连接尽量在安装阶段定稿参考源码核对实际生效值常量默认值见 pkg/option/config.goMap 内核名称见 pkg/datapath/maps/maps_generated.go容量规划的核心原则是默认值适合作为起点动态尺寸适合作为通用基线显式覆盖用于已知的极端场景而 Service LB 必须结合真实服务拓扑在部署前完成核算。理解这些 Map 上限及其背后的源码实现pkg/option/config.go 中的默认常量、校验与动态计算逻辑将帮助你在规模增长时做出有依据的调优决策。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考