Container Service for Kubernetes (ACK) provides stable and high-performance container networks by integrating the Kubernetes network model, Virtual Private Cloud (VPC), and Server Load Balancer (SLB). This topic describes the terms that are related to ACK cluster networking and Alibaba Cloud network infrastructure. The terms include Container Network Interface (CNI), Service, Ingress, and DNS Service Discovery (DNS-SD). Understanding these terms helps you optimize application deployment models and network access.

CNI

Figure 1. Container network model
model
A containerized application is deployed as multiple workloads on a node. Each workload requires a unique network namespace. To avoid network conflicts, each pod must have a unique network namespace. To enable the application that runs on a pod to communicate with other networks, the pod must be able to access other networks. Container networking has the following features:
  • A pod has a unique network namespace and IP address. Applications that run on different pods can listen on the same port without conflicts.
  • Pods can access each other by using their IP addresses.

    A pod can communicate with other applications in a cluster by using a unique IP address.

    • Pods can access each other within a cluster.
    • Pods can access Elastic Compute Service (ECS) instances that are deployed in the same VPC.
    • ECS instances can access pods that are deployed in the same VPC.
    Note To ensure that the pods and ECS instances in the same VPC can access each other, you must configure proper security group rules. For more information about how to configure security group rules, see Add a security group rule.

ACK provides two network plug-ins to help you implement container networking: Flannel and Terway. The two network plug-ins adopt different network models and have the following features:

Note After you create a cluster, you cannot change the network plug-in that is used by the cluster.

Terway adopts a cloud-native networking solution and configures the container network by using elastic network interfaces (ENIs). ENIs are virtual network interface controllers (NICs) that are provided by Alibaba Cloud. An ENI assigns IP addresses within a VPC to pods. You do not need to specify a CIDR block for pods.

Terway provides the following features:

  • Containers and VMs reside at the same network layer. This makes cloud-native migration easier.

  • Network devices that are allocated to containers can be used for communication without the need to use packet encapsulation or route tables.

  • The number of nodes in a cluster is not limited by the quota of route tables that are used to route traffic or the quota of forwarding database (FDB) tables that are used to encapsulate packets.

  • You do not need to plan the CIDR blocks of overlay networks for containers. Containers in different clusters can communicate with each other if the relevant ports are opened in security group rules.

  • You can directly attach pods to Server Load Balancer (SLB) instances. This saves you the need to use a NodePort Service to route traffic.

  • The NAT gateway can provide SNAT services for containers. This saves you the need to configure SNAT on the cluster nodes for the container CIDR blocks. Containers can use their IP addresses to access VPC resources. This simplifies request auditing. In addition, containers do not rely on connection tracking (conntrack) SNAT to access external networks. This reduces the chances of access failures.

  • Terway allows you to use network policies to enforce access control on pods.

    Network policies define how pods communicate with each other and how pods communicate with other network endpoints. Network policies are Kubernetes resources that are used to select pods based on labels and define access control rules for the selected pods. For more information, see Use network policies for access control in Related topics.

  • When you select Alibaba Cloud Linux as the operating system of the node, Terway supports IPVLAN and Extended Berkeley Packet Filter (eBPF) to improve network performance.

The Flannel network plug-in ensures that the CIDR block of pods does not overlap with the CIDR block of the VPC. The CIDR block of pods is evenly divided and allocated to the nodes in the cluster. Each pod on a node is assigned an IP address that belongs to the CIDR block of the node. Terway enables pods on different nodes to access a VPC by using custom routes that are provided by the VPC.

Flannel provides the following features:

  • The VPC-based Flannel network does not require packet encapsulation and improves network performance by 20% compared with the default Flannel VXLAN network.

  • The CIDR block of pods does not overlap with the CIDR block of the VPC.

  • A route entry must be added to the VPC for each node in the cluster. The number of nodes in a VPC is limited by the quota of routing tables of the VPC.

For more information about the CIDR blocks of VPC and Kubernetes clusters, see Network architectures of VPC-connected Kubernetes clusters.

For more information about how to select a network plug-in based on your business requirements, see Work with Terway.

Networking features of ACK

CategoryNetworking featureNetwork plug-inReferences
TerwayFlannel
Network configuration managementIPv4/IPv6 dual stackSupportedNot supported
Configure network configurations for individual nodesSupportedNot supportedConfigure network settings for individual nodes in a cluster that uses Terway
Configure network configurations for individual podsSupportedNot supportedConfigure a static IP address, a separate vSwitch, and a separate security group for a pod
Configure static pod IP addressesSupportedNot supportedConfigure a static IP address, a separate vSwitch, and a separate security group for a pod
Pod QoSSupportedNot supportedConfigure QoS for pods
Use network policiesSupportedNot supportedUse network policies
Configure security groups for podsSupportedNot supported
Expand the pod CIDR blockSupportedNot supported
Configure multiple route tables for a VPCSupportedSupported
North-south traffic managementConfigure pods to access the InternetSupportedSupported
Expose pods to the InternetSupportedNot supported
Use LoadBalancer ServicesSupportedSupportedUse an automatically created SLB instance to expose an application
Use IngressesSupportedSupportedIngress overview

Service

Cloud-native applications typically require agile iterations and fast scaling. Containers and the related network resources have short lifecycles. To achieve fast workload scaling, you must configure automatic load balancing and use a static IP address. In ACK, a Service provides a static IP address to access a group of pods and balances the loads across the pods. How a Service works
  • When you create a Service, ACK assigns a static IP address to the Service.
  • You use the selector field to select a group of pods for the Service. The Service serves as a load balancer and forwards traffic that is sent to the Service IP and port to the IP addresses and ports of the selected pods.
ACK provides the following types of Services to handle requests from different sources and clients:
  • ClusterIP
    A ClusterIP Service is used for access within the cluster. If you want your application to provide services within the cluster, create a ClusterIP Service.
    Note The default Service type is ClusterIP.
  • NodePort
    A NodePort Service is used to expose an application to the Internet. You can use the IP address and port of a cluster node to expose your application. This way, your application can be accessed by using the node IP address and port.
  • LoadBalancer
    A LoadBalancer Service is also used to expose an application to the Internet. A LoadBalancer Service uses an SLB instance to expose applications. Therefore, LoadBalancer Services provide higher availability and performance than NodePort Services. For more information about how to use a LoadBalancer Service to expose an application, see Use an existing SLB instance to expose an application and Use an automatically created SLB instance to expose an application.
  • Headless Service
    A Headless Service is defined by setting the clusterIP field to None in the Service configuration file. A Headless Service does not have a static virtual IP address (VIP). When a client accesses the domain name of a Headless Service, the DNS server returns the IP addresses of all backend pods. The client must use DNS load balancing to balance the loads across pods.
  • ExternalName
    An ExternalName Service is used to map an external domain name to a Service within the cluster. For example, you can map the domain name of an external database to a Service name within the cluster. This allows you to access the database within the cluster by using the Service name.

For more information about how to configure a LoadBalancer Service, see Considerations for configuring a LoadBalancer type Service.

Ingress

In ACK clusters, Services support Layer 4 load balancing. However, Ingresses manage external access to Services in the cluster at Layer 7. 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 access paths for Layer 7 load balancing. For more information see Ingress overview.

Figure 2. The relationship between Ingresses and Services
The relationship between Ingresses and Services

Examples

In common architectures that decouple the frontend and backend services, different access paths are used to access frontend and backend services. In this case, Ingresses can be used to implement Layer 7 load balancing across different applications. Examples

DNS for service discovery

ACK uses DNS for service discovery. For example, the name of a Service can be resolved to the cluster IP of the Service on a client. The name of a pod can be resolved to the IP address of the pod by using a StatefulSet. Using DNS for service discovery allows you to access applications without the need to use the IP addresses of the applications or worry about the environments in which the applications are deployed.

CoreDNS automatically converts the name of a Service to the IP address of the Service. This allows you to use the same Service name to access the Service in different environments. For more information about how to configure and optimize DNS resolution in a cluster, see Configure DNS resolution. dns

Infrastructure

  • VPC

    VPC is a type of private network provided by Alibaba Cloud. VPCs are logically isolated from each other. You can create and manage cloud services in VPCs, such as ECS instances, ApsaraDB RDS, and SLB instances.

    Each VPC consists of one vRouter, at least one private CIDR block, and at least one vSwitch. vpc

    • Private CIDR blocks

      When you create a VPC and a vSwitch, you must specify the private IP address range for the VPC in CIDR notation.

      You can use one of the standard private CIDR blocks listed in the following table as the private CIDR block of a VPC, or use a custom CIDR block. For more information about CIDR blocks, see Plan networks.

      CIDR blockDescription
      192.168.0.0/16Number of available private IP addresses (excluding IP addresses reserved by the system): 65,532
      172.16.0.0/12Number of available private IP addresses (excluding IP addresses reserved by the system): 1,048,572
      10.0.0.0/8Number of available private IP addresses (excluding IP addresses reserved by the system): 16,777,212
      Custom CIDR blockYou can also use a custom CIDR block other than 100.64.0.0/10, 224.0.0.0/4, 127.0.0.0/8, 169.254.0.0/16, or their subnets.

    • vRouters

      A vRouter is the hub of a VPC. As a core component, it connects the vSwitches in a VPC and serves as a gateway between a VPC and other networks. After a VPC is created, a vRouter is automatically created for the VPC. A vRouter can be associated with only one route table.

      For more information about route tables, see Route table overview.

    • vSwitches

      A vSwitch is a basic network component that connects different cloud resources in a VPC. After you create a VPC, you can create vSwitches to create one or more subnets for the VPC. vSwitches in the same VPC can communicate with each other. You can deploy your applications in vSwitches that belong to different zones to improve service availability.

      For more information about vSwitches, see Create and manage a vSwitch.

  • SLB

    After you connect ECS instances to an SLB instance, SLB uses virtual IP addresses (VIPs) to virtualize the ECS instances into an application service pool. The application service pool features high performance and high availability. Client requests are distributed across the ECS instances based on forwarding rules.

    SLB checks the health status of the ECS instances and automatically removes unhealthy ECS instances from the pool to eliminate single points of failure. This improves the availability of your applications. You can also use SLB to protect applications against distributed denial of service (DDoS) attacks.

    SLB consists of the following components:
    • SLB instances

      An SLB instance is a running entity of the SLB service. An SLB instance receives and distributes traffic to backend servers. To get started with SLB, you must create an SLB instance and add at least one listener and two ECS instances to the SLB instance.

    • Listeners

      A listener checks client requests and forwards them to backend servers. A listener also performs health checks on backend servers.

    • Backend servers

      ECS instances are attached to SLB instances as backend servers to receive and process client requests. You can add ECS instances to a server pool one by one, or add multiple ECS instances to a vServer group or a primary/secondary server group at a time.