Container Service for Kubernetes (ACK) provides stable and high-performance container networks by integrating the Kubernetes network model with Alibaba Cloud network services. This topic describes the important terms used in ACK cluster networking, such as Container Network Interface (CNI), Service, Ingress, and DNS-based service discovery. You can understand these terms to optimize application deployment models and network access methods.
CNI plug-ins
Kubernetes uses CNI plug-ins to enable and standardize network communication between containers:
The status of a pod in the container network varies based on the lifecycle phase of the pod. For example, when a pod is created, it is added to the container network. When a pod is deleted, it is removed from the container network.
Each pod in the container network is assigned a unique IP address to identify the pod.
Pods can communicate with endpoints in clusters and endpoints outside clusters.
CNI plug-ins are responsible for the implementation of the container network. The CNI plug-in that you use determines how to allocate IP addresses to pods, whether to use overlay networks, how to forward traffic within the cluster, and how to manage access to pods. Well-known open source CNI plug-ins include Calico, Flannel, and Cilium.
ACK provides the following CNI plug-ins: Terway and Flannel. Terway and Flannel provide different features. The following section describes the features provided by Terway and Flannel. You can refer to the Comparison between Terway and Flannel topic to learn how to select between Terway and Flannel when you create an ACK cluster.
After you create a cluster, you cannot change the network plug-in that is used by the cluster.
Terway
Terway is a CNI plug-in developed by Alibaba Cloud. ECS instances in ACK clusters use elastic network interfaces (ENIs) to enable network communication. Terway assigns ENIs on nodes to pods to establish network connections between pods. Therefore, pods in a cluster that uses the Terway plug-in are connected to the virtual private cloud (VPC) in which the cluster resides. The Terway mode improves communication efficiency because no tunneling technologies, such as Virtual Extensible Local Area Network (VXLAN), are required to encapsulate packets. Terway is ideal for large-scale clusters and scenarios that have high requirements for network performance and access control.
When you create an ACK cluster that uses the Terway plug-in, you can configure Terway to run in inclusive ENI mode or exclusive ENI mode. The following section compares the two modes from different perspectives:
From the perspective of IP allocation: In exclusive ENI mode, each pod is assigned a separate ENI, which provides excellent network performance. In inclusive ENI mode, an ENI is shared by multiple pods, which increases the number of pods that can be deployed on the node.
From the perspective of network acceleration: The inclusive ENI mode supports DataPath V2 acceleration. After you enable DataPath V2 acceleration for Terway in inclusive ENI mode, Terway adopts a different traffic forwarding path for faster network communication.
From the perspective of access control: Both the inclusive ENI mode and the exclusive ENI mode support configuring fixed IP addresses, separate security groups, and vSwitches for pods. In addition, the exclusive ENI mode supports access control through Kubernetes network policies.
Flannel
Flannel is an open source CNI plug-in. Flannel uses network virtualization technologies such as VXLAN to build an overlay network for pods. Flannel is easy to configure and use. Compared with Terway, Flannel comes with weaker network performance and access control capabilities because Flannel does not require NAT gateways. In addition, Flannel does not support large clusters. Flannel is suitable for clusters that contain no more than 1,000 nodes. If you have low requirements on network performance and access control, or you want to quickly create and use clusters, we recommend that you use the Flannel plug-in.
For the detailed information about the comparison between Terway and Flannel, see Comparison between Terway and Flannel.
Services
Cloud-native applications require agile iterations and fast scaling. Pods are temporary and replaceable resources in Kubernetes. When pods are destroyed or replaced, the relevant network resources change. Therefore, a stable and consistent entry point to pods is required. In Kubernetes, a Service serves as the entry point to a group of pods and implements load balancing for the pods. The following list describes how a Service works:
A Service is associated with pods that match the selector of the Service. The system maps the IP address and a port of the Service to the IP addresses and ports of the pods.
When a backend pod of the Service is updated, the Service automatically updates the traffic forwarding rules to ensure that traffic can be forwarded to the updated pod.
ACK clusters support the following types of Services: ClusterIP, NodePort, LoadBalancer, Headless, and ExternalName. You can select different types of Services to enable access to pods from within the cluster, from outside the cluster, or from the Internet. For more information, see Getting started.
Ingresses
Compared with Services that provide load balancing at Layer 4, Ingresses manage external access to Services in the cluster at Layer 7. An Ingress provides a centralized entry point to multiple Services. You can use Ingresses to configure different Layer 7 forwarding rules. For example, you can forward requests to different Services based on domain names or paths. For more information, see Ingress overview.
DNS-based service discovery
ACK uses DNS to implement service discovery. For example, the name of a Service can be resolved to the cluster IP address of the Service. This allows you to access the backend pods of the Service. You can use the DNS-based service discovery feature to access applications through domain names, regardless of IP addresses or deployment environments. For more information about the DNS component, see DNS overview.
