Understand the networking concepts and infrastructure - Container Compute Service

ACS integrates the Kubernetes network model, Virtual Private Cloud (VPC), and Server Load Balancer (SLB) to deliver stable, high-performance container networking. This topic explains the core networking concepts in ACS — container network interface (CNI), Service, Ingress, and DNS service discovery — and the underlying network infrastructure that supports them.

Networking features

Category	Feature	Supported	Notes
Network configuration	Dual-stack (IPv4 and IPv6)	Not supported	—
Network configuration	Per-pod network configuration	Supported	Specify vSwitches and security groups for pods
Network configuration	Per-pod security groups	Supported	Specify vSwitches and security groups for pods
North-south traffic	Pod internet access	Supported	Enable internet access for an ACS cluster and Mount an independent EIP for pods
North-south traffic	Expose pods to the internet	Supported	Mount an independent EIP for pods and Configure DNAT to expose a pod
North-south traffic	LoadBalancer Services	Supported	Use an automatically created CLB Service to expose an application
North-south traffic	Ingresses	Supported	ALB Ingress management

Service

Pods are ephemeral — they get new IP addresses every time they restart or scale. Without an abstraction layer, every client that depends on a pod must track pod IP changes manually. A Kubernetes Service solves this by giving you a stable network endpoint for a group of pods, so clients can reach your application without tracking individual pod IPs or reconfiguring when pods change.

When you create a Service, ACS assigns it a stable IP address. The selector field maps the Service's IP and port to the matching pods for load balancing.

ACS supports the following Service types:

ClusterIP — Exposes the Service on an internal cluster IP. Use this for communication between services within the cluster. ClusterIP is the default type when you create a Service.
LoadBalancer — Exposes the Service externally using an SLB instance. This provides higher availability and performance than NodePort. For details, see Use an existing SLB instance to expose an application and Use an automatically created CLB Service to expose an application.
Headless Service — A Service with clusterIP set to None. It has no fixed virtual IP address (VIP). DNS queries for the Service return the IP addresses of all matching pods directly, so the client handles load balancing.
ExternalName — Maps 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 lets you access the database within the cluster through the Service name.

For important considerations when using LoadBalancer Services, see Considerations for configuring a LoadBalancer Service.

Ingress

Services handle Layer 4 (TCP/UDP) load balancing: they route traffic based on IP and port. Because Layer 4 operates below the application layer, Services have no awareness of HTTP paths or hostnames and cannot route based on them.

Ingress operates at Layer 7 (HTTP/HTTPS) and adds content-based routing on top of Services. With an Ingress, you can route requests to different Services based on URL paths or domain names. Use an Ingress when you need path-based or host-based routing — for example, when a single external IP must serve multiple backend Services.

Example: In a frontend/backend architecture where different access paths distinguish the frontend from the backend, Ingress can implement Layer 7 load balancing across different applications.

For details, see ALB Ingress management.

DNS service discovery

ACS uses CoreDNS for service discovery. Reach any Service in the cluster by name — no need to hardcode IP addresses or adjust configuration when pods restart.

A Service name resolves to the cluster IP of the Service.
A StatefulSet pod name resolves to the pod's IP address directly.

Because CoreDNS resolves Service names to the correct IP automatically, the same Service name works across different environments without any client reconfiguration.

For details on how DNS works and how to configure it, see How DNS works and configure DNS.

Network infrastructure

VPC

A Virtual Private Cloud (VPC) is a logically isolated private network on Alibaba Cloud. Each VPC is independent, and you can deploy cloud resources such as Elastic Compute Service (ECS) instances, ApsaraDB RDS instances, and SLB instances inside it.

A VPC typically includes a private CIDR block, at least one vSwitch, and a route table:

Private CIDR block — The IP address range allocated to the VPC and its vSwitches. Plan this carefully to avoid conflicts and ensure room to scale.
vSwitch — Divides the VPC into subnets. Each vSwitch must reside in a single zone, and you can deploy cloud resources within it and assign IP addresses.
Route table — Controls traffic routing out of the VPC. A system route table is created automatically, with system routes added by default.

SLB

Server Load Balancer (SLB) distributes incoming client requests across backend ECS instances using forwarding rules. It virtualizes the ECS instances into an application service pool using virtual IP addresses (VIPs), providing high availability and performance.

SLB continuously monitors the health of backend servers and automatically removes unhealthy instances from the pool, eliminating single points of failure. It also provides DDoS protection.

SLB consists of three components:

SLB instance — The running entity of the SLB service. It receives incoming traffic and distributes it to backend servers. To get started, create an SLB instance and add at least one listener and two ECS instances.
Listener — Checks incoming client requests and forwards them to backend servers. Listeners also run health checks on backend servers.
Backend server — An ECS instance attached to an SLB instance to receive and process client requests. Manage backend servers individually or in vServer groups or primary/secondary server groups.

For details, see SLB overview.