After enabling Datapath V2 on a Terway-based cluster, tune three areas to improve performance and stability at scale: conntrack parameters for high-concurrency workloads, Identity count for NetworkPolicy-heavy environments, and the service load balancing map size for large clusters.
Optimize conntrack configuration
Conntrack is a connection tracking module in the Linux kernel. In Datapath V2 mode, an Extended Berkeley Packet Filter (eBPF) program handles connection tracking for the container network.
For high-concurrency workloads, adjust two conntrack parameters: the conntrack table size and the TCP connection record timeout. For configuration steps, see Optimize conntrack configuration in Terway mode.
Limit the number of Identities
In Datapath V2, NetworkPolicy enforcement is built on eBPF rather than Netfilter. The eBPF implementation assigns each pod an Identity — a unique security identifier derived from the pod's labels and namespace labels. Pods with identical label combinations share the same Identity, so NetworkPolicy rules apply uniformly across them using IP-to-Identity mapping.
If you do not enable the NetworkPolicy feature, Identities have no effect and Terway automatically controls their count.
If you enable the NetworkPolicy feature, keep the label set consistent across pods that belong to the same logical group. Labels that differ between pods — such as per-pod timestamps, hashes, or job-run IDs — cause each pod to receive a unique Identity instead of sharing one. A large number of Identities increases cluster management overhead and slows IP address allocation.
To prevent high-churn labels from contributing to Identity generation, configure label filtering.
Configure label filtering
Label filtering changes affect existing workloads and NetworkPolicy behavior. Read the constraints below before proceeding.
Constraints:
-
Adjusting label filtering rules triggers creation of new Identities, temporarily increasing the Identity count and API Server load.
-
Filtered labels cannot be referenced in NetworkPolicy rules. Only filter labels that are not used in any policy.
-
Do not filter all labels. Each pod group must retain at least one label — either a namespace label or a pod label — so the system can identify it.
For the full syntax reference, see the Cilium documentation on identity-relevant labels.
To configure label filtering in Terway, update the cilium_args section as described in Customize Terway configuration parameters.
Adjust the service load balancing map size
Cilium stores load balancing entries for ClusterIP and NodePort Services in eBPF maps named cilium_lb{4,6}_services_v2. The --bpf-lb-map-max flag controls the maximum number of entries in these maps, with a default of 64k.
When the map is full, Cilium cannot update Service endpoints. This causes connectivity failures for existing Service IPs and prevents new Services from being created.
Estimating the required map size:
The number of entries consumed by a single ClusterIP or NodePort Service equals:
entries per Service = number of backend pods × number of port/protocol combinationsTo estimate the total map size needed across the cluster:
required map size = Σ (backend pods × port/protocol combinations) for all ServicesThis estimate assumes pod counts and port/protocol combinations per Service are roughly normally distributed. If any Service selects an unusually large number of backends, calculate that Service's entry count separately and add it to the estimate.
Changing bpf-lb-map-max and restarting Cilium interrupts active connections. The new map must be fully repopulated with existing Service entries before traffic is restored. Plan this change during a maintenance window.