All Products
Search

This Product

    Container Service for Kubernetes:Comparison between Terway and Flannel

    Document Center

    Container Service for Kubernetes:Comparison between Terway and Flannel

    Last Updated:Mar 26, 2026

    ACK supports two Container Network Interface (CNI) plugins: Terway and Flannel. This topic compares their features and use cases to help you choose the right plugin before creating a cluster.

    Important

    You must select a CNI plugin when you create a cluster. The plugin cannot be changed after the cluster is created.

    Choose a CNI plugin

    For most workloads, use Terway. It supports larger clusters, NetworkPolicy, IPv4/IPv6 dual-stack, and provides better performance and security isolation than Flannel.

    Use Flannel only when your cluster is small, your network requirements are simple, and you do not need the advanced features that Terway provides.

    Terway Flannel
    Best for High-performance workloads, large clusters, security-sensitive environments Small clusters with simple networking needs
    Max nodes (ACK Pro) 15,000 1,000
    NetworkPolicy Supported Not supported
    IPv4/IPv6 dual-stack Supported Not supported
    Pod source IP preservation Yes No (source IP is the node IP)
    Important

    When using Flannel, ALB Ingress only forwards requests to NodePort and LoadBalancer services. ClusterIP services are not supported.

    Feature comparison

    Network performance

    Terway Flannel
    Performance vs. community Flannel Outperforms in TCP RR, UDP PPS, bandwidth, and latency Baseline
    Exclusive ENI mode Each pod gets a dedicated ENI; highest network performance; suited for HPC, gaming, and microservices Not supported
    Shared ENI mode with DataPath V2 Pods bypass the node's network protocol stack using eBPF for intra-cluster traffic; reduces latency Not supported
    Note

    The test data reflects theoretical values based on an ecs.ebmg5s.24xlarge instance. Actual results vary by environment. For details, see the Alibaba Cloud Native Community blog.

    Note

    In DataPath V2 mode, connection tracking (conntrack) is stored in an eBPF map using a Least Recently Used (LRU) algorithm. When the map is full, the oldest entries are evicted. Configure the relevant parameters based on your business scale to avoid exceeding connection limits. For details, see Optimize conntrack configurations in Terway mode.

    Node quota

    Terway Flannel
    ACK Pro cluster 5,000 nodes by default; up to 15,000 nodes 200 nodes by default; up to 1,000 nodes
    ACK Basic cluster Up to 10 nodes Up to 10 nodes
    Limiting factor Cluster capacity limit VPC route table entries (one entry per node; max 1,000 entries after quota increase)

    Pods per node

    Terway: The pod limit depends on the node instance type, the number of ENIs, and the number of private IPv4 addresses per ENI.

    For an ecs.c7.4xlarge instance (Compute-intensive Type c7, 16 vCPUs, 32 GiB memory):

    • Shared ENI mode: up to 210 pods

    • Exclusive ENI mode: up to 7 pods

    A Compute-intensive Type c6 instance supports up to 140 pods in shared ENI mode, because it supports fewer private IPv4 addresses per ENI than c7. For the calculation method, see Calculate the pod quota per node.

    Flannel: The pod limit depends on the Pods per Node setting and the subnet mask bits of the pod CIDR block. 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 can contain up to 16 nodes.

    Important

    The maximum number of nodes in a Flannel cluster cannot be changed after the network is created.

    Pod CIDR block

    Terway Flannel
    IP source Allocated from the VPC CIDR block; consumes VPC IP addresses Independent of the VPC CIDR block; allocated from a dedicated pod CIDR block
    Expandability Add vSwitches to expand the pod CIDR block Cannot be expanded
    Overlap restriction Pod CIDR, Service CIDR, and node CIDR must not overlap; cannot be modified after creation Pod CIDR, node CIDR (VPC), and Service CIDR must not overlap; cannot be modified after creation

    Plan a sufficiently large VPC CIDR block before creating a Terway cluster, because pod IP addresses consume VPC addresses.

    Network security

    Terway Flannel
    Dedicated vSwitches and security groups for pods Supported Not supported
    Kubernetes NetworkPolicy Supported Not supported

    IPv4/IPv6 dual-stack

    Terway Flannel
    Dual-stack Supported Not supported
    Note

    The Flannel plugin in ACK is modified for the Alibaba Cloud environment and is not always in sync with the open source community. For the ACK Flannel release notes, see Flannel.

    Static pod IP

    Terway Flannel
    Static pod IP Supported Not supported

    Session persistence

    Terway Flannel
    SLB backend connection Directly to pods; session persistence is maintained when backend pods change Through NodePort; traffic is interrupted when a pod changes, which may trigger service retries

    Multi-cluster communication

    Terway Flannel
    Cross-cluster pod communication Supported when the corresponding ports are open in security groups Not supported

    Pod source IP preservation

    Terway Flannel
    Source IP when accessing VPC endpoints Pod IP is preserved as the source IP; simplifies auditing Source IP is the node IP; original pod IP is not preserved

    What's next

    Before you create a cluster, plan your network. After a cluster is created, the CIDR blocks for pods, services, and nodes cannot be modified, and the CNI plugin cannot be changed. For guidance on sizing and isolating CIDR blocks, see Plan networks for ACK managed clusters.

    After you finalize your network plan:

    References