Configuring Container Network Parameters Using CNI

Updated at：2025-10-27

Background

Some containerized applications require tuned sysctl parameters in the container network namespace. Although privileged initContainers can be used for initialization, leveraging native CNI support is a more recommended approach.

The CCE CNI provides a sysctl plugin, which enables flexible configurations based on the CNI Chain.

This document explains how to configure and use CCE CNI to manage container sysctl settings at both the cluster and application levels.

Instructions for use

1. Confirm the container network mode

Execute kubectl get cm -n kube-system cce-cni-node-agent -o yaml and check the cniMode field.

A value starting with vpc-route- indicates a network solution based on VPC instance routing
A value starting with vpc-secondary-ip- indicates a network solution based on elastic network interfaces

2. Modify the CNI configuration file template

Based on the network mode obtained in Step 1, execute kubectl edit cm -n kube-system cce-cni-config-template to modify the CNI configuration template corresponding to the mode.

Manually edit the plugins list and add the sysctl configuration file at the end. The CNI configurations of all nodes will be updated after 1 minute.

A sample of the modified configuration is as follows:

YAML

1  cce-cni-secondary-ip-veth: |
2    {
3        "name":"{{ .NetworkName }}",
4        "cniVersion":"0.3.1",
5        "plugins":[
6            {
7                "type":"ptp",
8                "enableARPProxy":true,
9                "vethPrefix":"veth",
10                "mtu": {{ .VethMTU }},
11                "ipam":{
12                    "type":"eni-ipam",
13                    "endpoint":"{{ .IPAMEndPoint }}",
14                    "instanceType":"{{ .InstanceType }}",
15                    "deleteENIScopeLinkRoute":true
16                }
17            },
18            {
19              "type":"sysctl",
20              "kubeconfig":"/etc/cni/net.d/cce-cni.d/cce-cni.kubeconfig"
21            }
22        ]
23    }

3. Cluster-granularity configuration (optional)

In the configuration from Step 2, you can further add the sysctl field to specify the parameters that need to be configured.

After the following configuration takes effect, all newly created containers in the cluster will set /proc/sys/net/core/somaxconn to 500.

                JSON
                
            

                {
  "type":"sysctl",
  "kubeconfig":"/etc/cni/net.d/cce-cni.d/cce-cni.kubeconfig",
  "sysctl":{
    "net.core.somaxconn":"8192"
  }
}
            

4. Application-granularity configuration (optional)

After completing Step 2, users can configure sysctl parameters by setting the pod annotations.

For example, an Nginx container created using the following YAML file will set /proc/sys/net/core/somaxconn to 8192 and /proc/sys/net/ipv4/tcp_tw_reuse to 1.

YAML

1kind: Deployment
2apiVersion: apps/v1
3metadata:
4  name: nginx-example
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: nginx-example
10  template:
11    metadata:
12      labels:
13        app: nginx-example
14      annotations:
15        net.sysctl.cce.io/net.core.somaxconn: "8192"
16        net.sysctl.cce.io/net.ipv4.tcp_tw_reuse: "1"
17    spec:
18      containers:
19        - name: nginx-example
20          image: nginx:alpine
21          imagePullPolicy: IfNotPresent

Note

Ensure the CNI configuration is a valid JSON file
The configurable sysctl parameters for netns vary across different kernel versions. Configure carefully; otherwise, the container may fail to start

Reference documentation

Encrypting etcd Data Using KMS

CCE - Public Network Access Practice

CCE CCE