Help Center/ Cloud Container Engine/ User Guide/ Settings/ Network
Updated on 2026-05-26 GMT+08:00
View PDF
Share

Network

You can configure a default security group and secondary CIDR block for your clusters.

Cluster Network

Table 1 Parameters

Parameter

Description

VPC

VPC where a cluster resides

VPC enables you to provision logically isolated, configurable, manageable virtual networks for cloud servers, cloud containers, and cloud databases. You can configure IP address ranges, subnets, security groups, and more in a VPC, and assign EIPs and bandwidth to build your service system.

VPC CIDR Block

VPC CIDR Block of a cluster

For details about how to expand the VPC CIDR block, see Adding a Secondary VPC CIDR Block for a Cluster.

Default Node Subnet

Node subnet of a cluster

A subnet is a network that manages ECS network planes. It supports IP address management and DNS. ECSs in a subnet are assigned IP addresses from this subnet.

By default, ECSs in all subnets of the same VPC can communicate with one another, but ECSs in different VPCs cannot.

You can create a VPC peering connection to enable ECSs in different VPCs to communicate with each other.

Default Node Subnet | IPv4 CIDR Block/IPv6 CIDR Block

Node subnet CIDR block of a cluster

IPv4/IPv6 Dual Stack

Whether to enable IPv6 dual stack

Network Model

Network model of a cluster

After a cluster is created, its network model cannot be changed. For details about the comparison between different network models, see Overview.

Default Node Security Group

Default security group of the worker nodes in a cluster

You can select a custom security group as the default node security group for a cluster, and you need to allow traffic from specified ports in the security group to ensure normal communications in the cluster.

If the custom security group needs some modifications, the modified security group applies only to newly created or accepted nodes. For existing nodes, you need to manually modify the security group rules.

DataPlane V2

Whether DataPlane V2 is enabled. DataPlane V2 can be enabled for clusters that use VPC networks or Cloud Native Network 2.0. This function supports eBPF redirection for applying network policies. For details, see DataPlane V2.

Supported cluster versions:

  • CCE Turbo clusters of v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, or later
  • CCE standard clusters (using the VPC networks) of v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0, or later

IPVS Scheduling Policy (available in clusters using IPVS)

The IPVS load-balancing algorithm for control plane nodes. If this parameter is not set, the round robin (RR) algorithm will be used by default.

The options are as follows:

  • rr: The RR algorithm, which allocates requests to backend servers in sequence. When every server has the same weight, requests are evenly distributed.
  • lc: The least connections algorithm, which allocates each new request to the backend server that is currently handling the fewest active connections.
  • dh: The destination hashing algorithm, which hashes requests according to their destination IP addresses and allocates the requests with the same destination IP address to the same backend server.
  • sh: The source hashing algorithm, which hashes requests according to their source IP addresses and allocates the requests with the same source IP address to the same backend server.
  • sed: The shortest expected delay (SED) algorithm, which allocates requests to servers with higher weights. In this way, powerful, lightly-loaded servers can get new requests sooner.
  • nq: The never queue algorithm, which skips any calculation when a backend server has zero active connections and immediately assigns the request to that idle server, eliminating scheduling delay for idle servers.

Clusters v1.28.15-r60, v1.29.15-r20, v1.30.14-r20, v1.31.10-r20, v1.32.6-r20, v1.33.5-r10, or later support this configuration.

CIDR blocks for non-masquerading access (When a pod accesses these blocks, it will use its original IP address.)

(Available in clusters using the VPC networks)

In a cluster using a VPC network, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 are regarded as private CIDR blocks of the cluster by default. If the VPC to which the cluster resides uses a secondary CIDR block, operations such as creating or resetting a node will also add the secondary CIDR block to the private CIDR blocks.

If a pod tries to access a private CIDR block, the source node will not perform NAT on the pod IP address. Instead, the upper-layer VPC can directly send the pod data packet to the destination, which means, the pod IP address is directly used to communicate with the private CIDR block in the cluster.

This function is available only in clusters of v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later versions. For details, see Retaining the Original IP Address of a Pod.

NOTE:

To enable a node to access a pod in another node, the node CIDR block must be added to this parameter.

Similarly, to enable an ECS to access the IP address of a pod in a cluster that is in the same VPC as the ECS, the ECS CIDR block must be added to this parameter.

Pod Access to Metadata (supported only by CCE Turbo clusters)

Whether to allow a newly created pod in a cluster to access the node metadata, such as AZs and enterprise project ID. For details about the metadata types and how to obtain metadata, see ECS Metadata Types.

This function is available only in clusters of v1.23.13-r0, v1.25.8-r0, v1.27.5-r0, v1.28.3-r0, or later versions.

  • If a pod is created when the function is enabled, whether it can access metadata depends on the function status.
  • If a pod is created when the function is disabled or in a cluster of an earlier version, it cannot access metadata regardless of the function status. To grant a pod access to metadata, it must be rebuilt while the function is enabled.

Network Policies (available in clusters using the container tunnel networks)

Whether to enable network policies. The change works within 10 seconds. This configuration is supported by clusters of v1.25.16-r10, v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, v1.31.1-r0, and later versions.

  • Disabled: The network policy capability is not supported, and the created policies do not take effect.
  • Enabled: If a customer's Service CIDR block conflicts with an on-premises CIDR block, the link to a newly added gateway may not be established.

    For example, when a cluster accesses an external address through a Direct Connect connection, the switch outside the cloud does not support ip-option. If this configuration is enabled, the network access may fail.

Service Settings

Table 2 Parameters

Parameter

Description

Request Forwarding

Forwarding mode of a cluster

After a cluster is created, the service forwarding mode cannot be changed. IPVS and iptables are supported. For details, see Comparing iptables, nftables, and IPVS.

IPv4 Service CIDR Block/IPv6 Service CIDR Block

Each Service in a cluster has its own IP address. When creating a CCE cluster, you can specify the Service address range (Service CIDR block). The Service CIDR block cannot overlap with the subnet or the container CIDR block. The Service CIDR block can be used only within the cluster.

Service Port Range
NodePort range. The default range is 30000 to 32767. This can be changed to 20106 to 32767. After changing the value, update the node security group's TCP/UDP port range accordingly on the security group page. Otherwise, non-default ports will be inaccessible externally.
NOTE:

If a port number is smaller than 20106, it may conflict with the system health check port, potentially making the cluster unavailable. If a port number is greater than 32767, it may conflict with the OS ephemeral port range, potentially affecting performance.

Container CIDR Blocks (Available only in Clusters Using the VPC Network Model)

  • Container CIDR Block: If a container CIDR block configured during cluster creation cannot meet service expansion requirements, you can expand the container CIDR block. For details, see Adding a Container CIDR Block for a Cluster That Uses a VPC Network.
    • This function is only available for clusters v1.19.16-r0 or later that use VPC networks.
  • Reserve Pod CIDR: If this option is enabled, the container CIDR block can be reserved in the VPC where the cluster is deployed to prevent conflicts with new subnet CIDR blocks.

    This option is supported by clusters v1.28.15-r70, v1.29.15-r30, v1.30.14-r30, v1.31.10-r30, v1.32.6-r30, v1.33.5-r20, or later.

Container Network (Available only in CCE Turbo Clusters)

If you want different namespaces or workloads to use different subnet CIDR blocks and security groups, you can create a policy to associate the subnets and security groups with namespaces or workloads. For details, see Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration.

  • Container Subnet: Pod IP addresses are allocated from this subnet. Only the pods in the same namespace or for running the same workload can communicate with each other.
  • Associate Security Group: You can configure security group rules for pods in the same namespace or for running the same workload to customize access policies.

This configuration is supported only by CCE Turbo clusters. Pod subnets can be deleted from clusters of v1.23.17-r0, v1.25.12-r0, v1.27.9-r0, v1.28.7-r0, v1.29.3-r0, or later versions.

Container Network Pre-binding Settings (Available only in CCE Turbo Clusters)

A CCE Turbo cluster requests for and binds a network interface or supplementary network interface to each pod. Pods support fast scaling. However, it takes some time to create and bind a network interface to a pod, which slows down the pod startup speed if large-scale network interfaces are to be created in batches. Dynamic container network interface pre-binding is enabled by default to speed up pod startup while improving the IP address usage. Cluster pre-binding policies take effect globally. Cluster nodes will pre-bind container network interfaces based on the configured policies. To configure a separate pre-binding policy for a group of nodes, enable node pool pre-binding.

This configuration is supported only by CCE Turbo clusters.

All Container ENI Pre-binding

  • After this function is enabled, your cluster nodes will request for and be pre-bound with the maximum number of network interfaces supported by the node flavor. For example, if the maximum number of supplementary network interfaces supported by an s7.large.2 node is 16, CCE will dynamically pre-bind 16 supplementary network interfaces to this node.
  • After this function is disabled, you can customize the pre-binding parameters on the console.
    Table 3 Parameters of the dynamic network interface pre-binding policy

    Parameter

    Default Value

    Description

    Suggestion

    Minimum Number of Container ENIs Bound to a Node

    10

    Minimum number of network interfaces bound to a node. The value can be a number or a percentage.

    • Number: The value must be an integer from 0 to 65535. The value 10 indicates that at least 10 pod network interfaces must be bound to a node. If the number you specified exceeds the pod network interface quota of the node, the network interface quota will be used.
    • Percentage: The value ranges from 1% to 100%. For example, the value 10% indicates that if the network interface quota of a node is 128, at least 12 (rounded down) network interfaces must be bound to a node.

    Set both nic-minimum-target and nic-maximum-target to the same value or percentage.

    Configure this parameter based on the number of pods typically running on most nodes.

    Upper Limit of Pre-bound Container ENIs

    0

    After the number of network interfaces bound to a node exceeds the nic-maximum-target value, CCE will not proactively pre-bind network interfaces.

    Checking the upper limit of pre-bound pod network interfaces is enabled only when the value of this parameter is greater than or equal to the minimum number of pod network interfaces (nic-minimum-target) bound to a node. The value can be a number or a percentage.

    • Number: The value must be an integer from 0 to 65535. The value 0 indicates that the check on the upper limit of pre-bound pod network interfaces is disabled. If the number you specified exceeds the pod network interface quota of the node, the network interface quota will be used.
    • Percentage: The value ranges from 1% to 100%. For example, a value of 50% means that if a node's network interface quota is 128, the maximum number of pre-bound network interfaces is 64 (rounded down).

    Set both nic-minimum-target and nic-maximum-target to the same value or percentage.

    Configure this parameter based on the maximum number of pods running on most nodes.

    Container ENIs Dynamically Pre-bound to a Node

    2

    The target number of network interfaces to be pre-bound to a node before it starts.

    When the sum of the nic-warm-target value and the number of network interfaces already bound to the node exceeds the nic-maximum-target value, CCE will pre-bind the number of network interfaces specified by the difference between the nic-maximum-target value and the current number of network interfaces bound to the node.

    Set the parameter value to the number of pods that can be scaled out instantaneously within 10 seconds on most nodes.

    Threshold for Unbinding Pre-bound Container ENIs

    2

    Pre-bound network interfaces on a node will only be unbound and reclaimed if the difference between the number of idle network interfaces and the nic-warm-target value exceeds the threshold. The value can only be a number.

    • A large value will accelerate pod startup but slow down the unbinding of idle pod network interfaces and decrease the IP address usage. Exercise caution when performing this operation.
    • A small value will speed up the unbinding of idle pod network interfaces and increase the IP address usage but will slow down pod startup, especially when a large number of pods increase instantaneously.

    Configure this parameter based on the difference between the number of pods that are frequently scaled on most nodes within minutes and the number of pods that are instantly scaled out on most nodes within 10 seconds.
Parent Topic: Settings