# DataPlane V2最佳实践 #### 限制Identity数量 Identity是根据安全相关标签生成的集群级数字身份。Cilium从Pod标签以及Namespace、ServiceAccount等元数据中提取参与身份计算的标签。具有相同标签集合的Pod共享同一个Identity；只要相关标签集合不同，系统就会分配新的Identity。 Cilium维护IP与Identity的映射，当报文进入eBPF数据面后，eBPF程序获取通信对端的Identity，并根据Policy Map中的Identity、端口和协议规则执行访问控制。 Identity数量取决于安全相关标签组合的数量，而不是Pod数量。例如，1000个标签相同的Pod可以共享一个Identity；如果每个Pod都包含不同的时间戳、随机ID、构建号或发布哈希，则可能为每个Pod创建不同的Identity，增加控制面、策略计算和端点收敛压力。因此，应通过标签过滤限制无效Identity的产生。 #### 标签过滤 Cilium默认使用大部分标签计算Identity，同时排除pod-template-hash、controller-revision-hash等常见高基数标签。详细配置语法请参见[Cilium官方文档](https://docs.cilium.io/en/stable/operations/performance/scalability/identity-relevant-labels/)。 - **包含模式**：规则不以 ! 开头。配置任一包含模式后，仅匹配规则的标签及默认包含项参与Identity计算。 - **排除模式**：规则以 ! 开头，用于忽略不参与安全策略的标签。 - **匹配规则**：标签规则为正则表达式，默认从键名开头匹配。精确匹配应使用$，域名中的点号需要转义。 **注意事项** - 调整前必须核对全部NetworkPolicy选择器。不可过滤所有标签，也不可过滤NetworkPolicy依赖的标签，否则系统将无法按预期区分不同Pod，可能造成策略失效或访问范围扩大。 - 新规则生效并重新生成Endpoint后，系统会创建或复用新的Identity。旧Identity被回收前，新旧Identity可能短时并存，导致Identity数量以及kube-apiserver、Cilium Agent和Operator的资源开销暂时升高。 - 标签过滤规则变更应避开大规模Pod扩缩容、集群升级和批量策略调整，并在生产变更前完成允许及拒绝流量验证。 #### 配置Conntrack 启用DataPlane V2后，经Cilium eBPF数据面处理的Pod流量使用eBPF Conntrack Map记录连接状态，不再依赖Linux Netfilter Conntrack表。您可以调整Conntrack参数以适配高并发服务等场景下的网络需求，例如调整eBPF Map的大小、调整TCP链接记录超时时间，详情请参见[优化DataPlane V2模式下conntrack配置](https://support.huaweicloud.com/usermanual-cce/cce_10_1163.html)。 #### 监控eBPF Map的使用率 DataPlane V2使用eBPF Map 保存连接跟踪、服务转发和网络策略等数据。Map容量不足可能导致条目写入失败、服务或策略下发异常，进而影响Pod网络通信。对于采用LRU淘汰机制的Map，达到容量上限时还可能触发旧条目淘汰，而非直接返回写入失败。具体行为取决于Map类型。更多信息请参考[Linux BPF Map文档](https://docs.kernel.org/bpf/map_hash.html)。 建议在生产集群中开启cilium-agent指标采集，并结合Map容量压力、操作失败、丢包和组件日志配置告警。 #### 启用指标采集 请参见[开启DataPlane V2网络的cilium-agent组件可观测性](https://support.huaweicloud.com/usermanual-cce/cce_10_1064.html)，完成指标端口、采集任务和监控看板配置。适用的集群类型及版本要求以该文档为准。 ![](https://support.huaweicloud.com/usermanual-cce/public_sys-resources/caution_3.0-zh-cn.png) - 按最小权限原则配置节点安全组和相关访问控制，仅允许可信的监控采集端访问metric 端口。上述文档使用TCP 9962端口，不应将其暴露到公网。 - 开启指标端口后，还需确认Prometheus已成功发现并采集各节点的cilium-agent。 - 指标及标签可能随插件版本变化。上线告警前，应检查实际/metrics输出和查询结果。**查询无数据不代表Map使用率为零。** #### 主要监控指标 | 指标名 | 标签 | 类型 | 说明 | |:---|:---|:---|:---| | ``` cilium_bpf_map_pressure ``` | ``` map_name ``` | Gauge | Map 所需容量与配置容量的比值。小于 1.0 时表示 Map 的使用率，大于或等于 1.0 时表示 Map 已满。 | | ``` cilium_bpf_map_capacity ``` | ``` map_group ``` | Gauge | 按 map_group 分组的 Map 最大条目数，不是当前已使用条目数。上游文档说明容量为 65536 的 Map 类型不单独上报，不能统一描述为归入 default 组。 | | ``` cilium_bpf_map_ops_total ``` | map_name、operation、outcome | Counter | 已执行的 eBPF Map 操作总次数。 | | ``` cilium_bpf_maps_virtual_memory_max_bytes ``` | 无 | Gauge | 系统中已安装的 eBPF Map 使用的最大内存量，单位为字节。 | | ``` bpf_progs_virtual_memory_max_bytes ``` | 无 | Gauge | 系统中已安装的 eBPF 程序使用的最大内存量，单位为字节。 | 上述指标定义详见[Cilium指标文档](https://docs.cilium.io/en/stable/observability/metrics/#ebpf)。 #### 指标处理建议 表1运维参考阈值 | 级别 | 参考条件 | 建议处理 | |:---|:---|:---| | 预警 | 压力超过 80%，持续 5 分钟 | 检查增长趋势、容量配置及条目来源，评估优化或扩容。 | | 严重 | 压力超过 95%，持续 1 分钟 | 优先排查，结合写入失败、丢包和业务影响判断是否需要紧急处置。 | | 异常 | 持续出现 Map 更新失败 | 不受压力阈值限制，及时检查日志和业务连通性。 | 发现Map压力持续升高时，应先定位实例和Map类型，检查条目增长原因及业务影响，再参照[eBPF Map容量调优]选择处理方式。 - **Service Map**：检查Service、后端及端口规模。 - **Policy Map**：检查策略选择范围、Identity数量及规则展开规模。 - **Conntrack和NAT Map**：检查并发连接数、超时设置、回收情况及节点负载。 - **Node Map**：检查节点相关条目增长和残留情况，再评估当前插件是否支持调整容量参数。 不应将所有Map高水位告警都通过增大bpf-map-dynamic-size-ratio处理，也不应在未确认原因前直接重启组件或删除Map。扩容可能增加内存开销，部分变更还可能影响现有连接，应测试环境完成验证后按变更流程实施。 #### eBPF Map容量调优 DataPlane V2使用eBPF Map保存连接跟踪、NAT、网络策略和Service负载均衡等数据。eBPF Map创建后，max_entries不能原地修改；调整容量通常需要重启yangtse-cilium，由组件重新创建或迁移对应的Map。 当Map容量不足时，可能出现条目写入或策略更新失败、连接跟踪条目被淘汰、Service访问异常等问题。建议根据[监控eBPF Map的使用率]持续监控Map压力，并在达到告警阈值后结合业务规模评估是否调整。不同Map容量及其影响请参见[Cilium eBPF Maps](https://docs.cilium.io/en/stable/network/ebpf/maps/)。 #### 参数总览 ![](https://support.huaweicloud.com/usermanual-cce/public_sys-resources/caution_3.0-zh-cn.png) 调整以下参数后，需要滚动重启yangtse-cilium使配置生效。部分Map可能在重建或迁移期间重新填充数据，导致存量连接短暂抖动；其中，调整Service LB Map容量可能中断已有Service连接。 请避开业务高峰，按节点分批滚动，并在变更前确认节点具有足够的可用内存。建议先在测试集群或少量节点上验证。 | **参数** | **影响功能** | **默认值** | **取值范围** | **建议调整场景** | |:---|:---|:---|:---|:---| | ``` bpf-map-dynamic-size-ratio ``` | **连接跟踪与NAT**：根据节点内存动态计算CT、NAT、Neighbor及Socket反向NAT等Map的容量。容量不足可能导致条目写入失败或被提前淘汰，引发新建连接失败、连接中断或丢包。 | ``` 0.0025 ``` | ``` (0.0, 1.0] ``` | CT或NAT Map压力持续偏高，且节点承载大量并发连接、长连接或SNAT连接。不存在适用于所有集群的固定推荐值，应小幅调高并同步观察内存占用。 | | ``` bpf-policy-map-max ``` | **NetworkPolicy（每个Endpoint）**：控制单个Endpoint Policy Map的最大条目数。条目通常由通信方向、对端Identity、端口和协议等维度组成。容量不足时，策略更新可能失败，具体保护行为取决于插件版本和配置。 | ``` 16384 ``` | ``` [256, 65536] ``` | 配置了大量的NetworkPolicy，且单个Pod涉及大量对端Identity或端口、协议组合，Policy Map压力持续偏高。 | | ``` bpf-lb-map-max ``` | **Kubernetes Service（每个节点）**：控制Service LB Map容量。容量不足时，Service更新可能无法写入数据面，影响Service IP访问或新Service创建。 | ``` 65536 ``` | 受插件校验、内核能力和节点内存限制。 | 所需容量接近上限。可按"Service数量 × 平均后端数 × 平均端口/协议数"进行初步估算，并结合实际Map压力确认。 | | ``` bpf-node-map-max ``` | **节点IP映射（每个节点）**：控制Node Map可保存的唯一Node IP数量。容量不足可能影响依赖节点IP查找的数据面功能。 | ``` 16384 ``` | ``` ≥ 16384 ``` | 集群中的唯一Node IP数量接近默认上限，或监控显示Node Map压力持续升高。不能仅按Kubernetes节点数估算，因为一个节点可能对应多个Node IP。 | 例如将bpf-map-dynamic-size-ratio配置为0.01，将bpf-lb-map-max配置为65536，将bpf-node-map-max配置为32768，可在 cilium-config 中增加以下配置： ``` apiVersion: v1 kind: ConfigMap metadata: name: cilium-config namespace: kube-system data: bpf-map-dynamic-size-ratio: "0.01" bpf-lb-map-max: "65536" bpf-node-map-max: "32768" ``` 配置完成后，滚动重启yangtse-cilium使配置生效： ``` kubectl rollout restart daemonset/yangtse-cilium -n kube-system ```