All Products
Search

This Product

    Container Service for Kubernetes:Terway vs. Flannel CNI plugins

    Document Center

    Container Service for Kubernetes:Terway vs. Flannel CNI plugins

    Last Updated:Jul 14, 2026

    ACK offers Terway for ENI-based high-performance networking and Flannel for simpler VPC-routed clusters.

    • Terway, developed by Alibaba Cloud, uses ENIs for pod networking and provides features such as eBPF-based network acceleration, NetworkPolicy, and pod-level vSwitches and security groups. Suitable for scenarios requiring large node scale, high network performance, and robust security, such as high-performance computing (HPC), gaming, and microservices.

    • Flannel is an open-source CNI plugin. In ACK, it uses the Alibaba Cloud VPC network mode, forwarding packets directly through the VPC route table. Suitable for small-scale clusters that need simplified networking without granular container network control.

    Important

    • Install a CNI plugin when you create a cluster. The plugin cannot be changed afterward.

    • With Flannel, ALB Ingress can forward requests only to NodePort and LoadBalancer services. ClusterIP services are not supported.

    Item

    Terway

    Flannel

    Network performance

    		image

    • Terway outperforms community Flannel in TCP RR, UDP PPS, bandwidth, and latency.

      Note

      Test data are theoretical values based on ecs.ebmg5s.24xlarge instances and may vary by environment. See Alibaba Cloud Native Community.

    • Terway supports exclusive ENI mode, where each pod has a dedicated ENI for superior network performance. Suitable for scenarios such as HPC, gaming, and microservices.

    • Terway supports shared ENI mode with DataPath V2 acceleration, an upgrade to the IPVLAN solution. For intra-cluster traffic, DataPath V2 uses eBPF to bypass the node network stack for faster access.

    Note

    In DataPath V2 mode, container conntrack data is stored in an eBPF map. Like Linux conntrack, it uses an LRU algorithm, evicting the oldest records when full. Optimize conntrack configurations to avoid exceeding connection limits.

    Node quota

    The maximum number of nodes in a Terway cluster depends on the cluster capacity limit.

    • ACK Pro cluster: supports 5,000 nodes by default and a maximum of 50,000 nodes.

    • ACK Basic cluster: 10 nodes.

    The maximum node count in a Flannel cluster depends on VPC route table entries and the cluster capacity limit.

    The VPC route table supports 200 entries by default, up to 1,000 after a quota increase. Each node uses one entry, so a Flannel cluster supports up to 1,000 nodes.

    • ACK Pro cluster: supports 200 nodes by default and a maximum of 1,000 nodes.

    • ACK Basic cluster: 10 nodes.

    Pods per node

    Pods use node ENIs. The maximum pod count per node depends on the instance type and metrics such as the ENIs and the number of private IPv4 addresses per ENI.

    image

    For example, a Compute-optimized c7 instance (ecs.c7.4xlarge, 16 vCPUs, 32 GiB):

    • In shared ENI mode, a node can run a maximum of 210 pods.

    • In exclusive ENI mode, a node can run a maximum of 7 pods.

    Although Compute-optimized c6 and Compute-optimized c7 instances have the same number of ENIs, a Compute-optimized c6 instance can run up to 140 pods in shared ENI mode because it has fewer private IPv4 addresses per ENI. See Calculate the pod quota per node.

    The maximum pod count per node depends on the Number of Pods per Node parameter and the subnet mask of the Container CIDR Block.

    image

    For example, if the pod CIDR block of an ACK Pro cluster is 172.16.0.0/20, each node can run up to 256 pods and the cluster supports up to 16 nodes.

    Important

    The maximum node count in a Flannel cluster cannot be changed after creation.

    Pod CIDR block

    • The pod CIDR block is allocated from the VPC CIDR block, consuming many VPC IP addresses. Plan a VPC with sufficient IP addresses.

    • The pod CIDR block and service CIDR must be independent and cannot overlap. The CIDR blocks cannot be modified.

    • You can expand the pod CIDR block by adding vSwitches.

    • The pod CIDR block is independent of the VPC CIDR block. Flannel assigns each node a subnet from this block for pod IP allocation.

    • The pod CIDR block, node CIDR (VPC CIDR block), and service CIDR must be independent and cannot overlap. The CIDR blocks cannot be modified.

    • The pod CIDR block cannot be expanded.

    Network security

    • You can configure independent vSwitches and security groups for pods.

    • Supports Kubernetes NetworkPolicy for container-level access control.

    • You cannot configure independent vSwitches and security groups for pods.

    • Does not support NetworkPolicy.

    IPv4/IPv6 dual-stack

    Supports dual-stack networking.

    Does not support dual-stack networking.

    Note

    ACK uses a modified Flannel plugin, not always in sync with the open-source community. See Flannel release notes.

    Static pod IP

    Supports static IP addresses for pods.

    Does not support static IP addresses for pods.

    Session persistence

    Because load balancing backends connect directly to pods, session persistence ensures service availability even if backend pods change.

    Load balancing backends use NodePort to connect to pods. If a backend pod is replaced, traffic is interrupted, which may cause service retries.

    Multi-cluster communication

    Pods in different clusters can communicate if the required ports are open in security groups.

    Not supported.

    Pod source IP preservation

    When a pod accesses other VPC endpoints, its original IP is preserved as the source IP, simplifying auditing.

    When a pod accesses other VPC endpoints, its source IP is replaced with the node IP.

    Next steps

    References