Container Compute Service:Network overview

Networking features of ACS

Service

Cloud-native applications 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. ACS allows you to create a Service as the ingress and load balancer of a pod. How a Service works

• When you create a Service, ACS assigns a stable IP address to the Service.

• You can configure the selector parameter to select a pod and map the IP address and port of the Service to the IP address and port of the pod for load balancing.

ACS provides the following types of Services to handle requests from different sources and clients:

• ClusterIP

  • A ClusterIP Service is used to handle access within the cluster. If you want your application to provide services within the cluster, create a ClusterIP Service.

  Note

  By default, ClusterIP is selected when you create a Service.

• LoadBalancer

  • A LoadBalancer Service is 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 applications, see Use an existing SLB instance to expose an application and Expose an application using a service that automatically creates a load balancer.

• 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 fixed virtual IP address (VIP). When a client accesses the domain of the Service, DNS 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 through the Service name.

For more information, see Considerations for configuring a LoadBalancer Service.

Ingress

In ACS 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 paths. For more information, see ALB Ingress management.

Example

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

DNS service discovery

ACS uses DNS for service discovery. For example, the name of a Service can be resolved to the cluster IP address 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. DNS-based 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 use and fine-tune the DNS component, see How DNS works and configure DNS.

Network 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 Elastic Compute Service (ECS) instances, ApsaraDB RDS instances, and SLB instances.

  A VPC typically includes a private CIDR block, at lease one vSwitch, and a route table.

  

  • Private CIDR block: A range of IP addresses allocated to VPCs and vSwitches. Proper planning is required to avoid conflicts and ensure scalability.

  • vSwitch: Divides a VPC into one or more subnets where you can deploy cloud resources and allocate IP addresses for them. A vSwitch must reside in a single zone.

  • Route table: Controls traffic routing from VPC to destinations. A system route table is created by default, and system routes are automatically added.

• SLB

  After you connect ECS instances to an SLB instance, SLB uses VIPs to virtualize the ECS instances and adds the ECS instances to 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. For more information about SLB, see SLB overview.

  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 defend your applications against 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.

  • Listener

    A listener checks client requests and forwards them to backend servers. Listeners also perform 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, or create vServer groups or primary/secondary server groups to manage ECS instances in batches.