Optimizing the conntrack Configuration in DataPlane V2 Mode
conntrack is a connection tracking mechanism. It tracks and records the state of network connections, such as TCP states (SYN, ESTABLISHED, CLOSED, and more). With DataPlane V2 enabled, cluster conntrack information is stored in eBPF maps rather than the Linux conntrack table.
By default, DataPlane V2 enables the Cilium configuration parameter --bpf-map-dynamic-size-ratio=0.0025. This parameter calculates the maximum capacity of several large eBPF maps based on total node memory, with a minimum of 131,072 entries. For details, see cilium eBPF maps. kube-proxy sets the maximum number of entries in the Linux conntrack table based on the number of CPU cores. By default, kube-proxy allows a maximum of 32,768 entries per core, with a minimum of 131,072 entries regardless of core count.
The table below compares the values set by kube-proxy and Cilium for their respective connection tracking tables when --bpf-map-dynamic-size-ratio=0.0025 is configured.
| vCPU | Memory (GiB) | kube-proxy conntrack Entries | Cilium conntrack Entries |
|---|---|---|---|
| 1 | 3.75 | 131,072 | 131,072 |
| 2 | 7.5 | 131,072 | 131,072 |
| 4 | 15 | 131,072 | 131,072 |
| 8 | 30 | 262,144 | 284,560 |
| 16 | 60 | 524,288 | 569,120 |
| 32 | 120 | 1,048,576 | 1,138,240 |
| 64 | 240 | 2,097,152 | 2,276,480 |
| 96 | 360 | 3,145,728 | 4,552,960 |
Checking the conntrack Configuration
To view the conntrack table size on a DataPlane V2 node, perform the following steps:
- Obtain the yangtse-cilium pod on the node.
kubectl describe node <nodename> | grep yangtse-ciliumInformation similar to the following is displayed:
kube-system yangtse-cilium-tdhzb 100m (5%) 1 (51%) 128Mi (0%) 0 (0%) 1d
- Check the conntrack table size.
kubectl exec -it -nkube-system yangtse-cilium-tdhzb -- cilium status --verbose | grep -A23 "BPF Maps"
The following is sample output from an 8 GiB node:
BPF Maps: dynamic sizing: on (ratio: 0.002500) Name Size Auth 524288 Non-TCP connection tracking 65536 TCP connection tracking 131072 Endpoints 65535 IP cache 512000 IPv4 masquerading agent 16384 IPv6 masquerading agent 16384 IPv4 fragmentation 8192 IPv4 service 65536 IPv6 service 65536 IPv4 service backend 65536 IPv6 service backend 65536 IPv4 service reverse NAT 65536 IPv6 service reverse NAT 65536 Metrics 1024 Ratelimit metrics 64 NAT 131072 Neighbor table 131072 Endpoint policy 16384 Policy stats 65536 Session affinity 65536 Sock reverse NAT 65536
The table below lists key outputs.
Output
Default Value
Function
Parameter
dynamic sizing: on
0.0025
Determines the size of an eBPF map based on total system memory. The following maps are included:
- cilium_ct_{4,6}_global
- cilium_ct_{4,6}_any
- cilium_nodeport_neigh{4,6}
- cilium_snat_v{4,6}_external
- cilium_lb{4,6}_reverse_sk
bpf-map-dynamic-size-ratio
Non-TCP connection tracking
65536
Non-TCP conntrack map, which is used to match reverse packets of connectionless protocols such as UDP and ICMP. The corresponding eBPF map is cilium_ct_any{4,6}_global.
bpf-ct-global-any-max
TCP connection tracking
131072
TCP conntrack map, which records the 5-tuple, direction, state, and revNAT information of TCP connections. The corresponding eBPF map is cilium_ct{4,6}_global.
bpf-ct-global-tcp-max
NAT
131072
BPF NAT/SNAT map, which is commonly used in BPF masquerade, NodePort SNAT, and egress SNAT paths.
The size of the NAT map cannot exceed 2/3 of the total capacity of TCP and non-TCP conntrack maps.
bpf-nat-global-max
Sock reverse NAT
65536
Socket LB reverse NAT map, which is mainly used for UDP and getpeername().
bpf-sock-rev-map-max
Adjusting the conntrack Configuration
eBPF and Linux conntrack serve the same purpose. The default configuration meets the requirements of most scenarios and does not require adjustment.
- Only DataPlane V2 2.1.1 and later versions support custom configuration.
- Adjusting the conntrack size is a high-risk operation. Fully verify the configuration before applying it to the production environment.
If your service meets any of the following conditions, adjust the configuration based on service requirements.
| Scenario | CCE Standard Cluster (VPC Network) | CCE Turbo Cluster |
|---|---|---|
| bpf-ct-global-tcp-max: "524288" bpf-ct-global-any-max: "262144" bpf-nat-global-max: "524288" bpf-sock-rev-map-max: "262144" | bpf-ct-global-tcp-max: "524288" bpf-ct-global-any-max: "262144" bpf-nat-global-max: "524288" bpf-sock-rev-map-max: "262144" |
| bpf-ct-global-tcp-max: "2097152" bpf-ct-global-any-max: "524288" bpf-nat-global-max: "1048576" bpf-sock-rev-map-max: "524288" | bpf-ct-global-tcp-max: "1048576" bpf-ct-global-any-max: "524288" bpf-nat-global-max: "524288" bpf-sock-rev-map-max: "524288" |
| bpf-ct-global-tcp-max: "4194304" bpf-ct-global-any-max: "1048576" bpf-nat-global-max: "2097152" bpf-sock-rev-map-max: "1048576" | bpf-ct-global-tcp-max: "2097152" bpf-ct-global-any-max: "1048576" bpf-nat-global-max: "1048576" bpf-sock-rev-map-max: "1048576" |
You can create a Cilium community-standard ConfigMap based on your service scale:
apiVersion: v1 kind: ConfigMap metadata: name: cilium-config namespace: kube-system data: bpf-ct-global-tcp-max: "524288" bpf-ct-global-any-max: "262144" bpf-nat-global-max: "524288" bpf-sock-rev-map-max: "262144"
After configuring cilium-config, run the following command to rebuild yangtse-cilium in rolling mode to apply the modification:
uuid=$(uuidgen)
kubectl patch daemonset -nkube-system yangtse-cilium --type='json' -p="[{\"op\": \"add\", \"path\": \"/spec/template/metadata/annotations/change-id\", \"value\": \"$uuid\"}]" What is your overall rating for this page?
Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot