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官方文档。
- 包含模式：规则不以 ! 开头。配置任一包含模式后，仅匹配规则的标签及默认包含项参与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配置。
监控eBPF Map的使用率
DataPlane V2使用eBPF Map 保存连接跟踪、服务转发和网络策略等数据。Map容量不足可能导致条目写入失败、服务或策略下发异常，进而影响Pod网络通信。对于采用LRU淘汰机制的Map，达到容量上限时还可能触发旧条目淘汰，而非直接返回写入失败。具体行为取决于Map类型。更多信息请参考Linux BPF Map文档。
建议在生产集群中开启cilium-agent指标采集，并结合Map容量压力、操作失败、丢包和组件日志配置告警。
启用指标采集
请参见开启DataPlane V2网络的cilium-agent组件可观测性，完成指标端口、采集任务和监控看板配置。适用的集群类型及版本要求以该文档为准。
- 按最小权限原则配置节点安全组和相关访问控制，仅允许可信的监控采集端访问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指标文档。
指标处理建议
| 级别 | 参考条件 | 建议处理 |
|---|---|---|
| 预警 | 压力超过 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。
参数总览
调整以下参数后，需要滚动重启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
