Service quick start-Container Service for Kubernetes(ACK)-阿里云帮助中心

In Kubernetes, a Service is an abstraction that exposes an application running on a set of pods as a network service. It provides a stable DNS name and load balancing for the pods. This topic explains how Kubernetes Services work, outlines important considerations, and provides recommendations for choosing a Service type.

Key concepts

Service

Accessing pods directly after they are created can lead to a few issues:

A controller, such as a Deployment, can terminate and recreate pods at any time, making direct access unreliable.
A pod's IP address is dynamically assigned at startup and cannot be predicted in advance.
An application often consists of multiple pods running the same image, which makes it impractical to access each pod individually.

To solve these problems, Kubernetes provides the Service object, which gives pods a stable network interface and a persistent IP address. A Service uses a label selector to identify a group of target pods and distributes traffic among them using load balancing. This approach resolves the issues of direct pod access and ensures your application is highly available and efficient.

Endpoint

In Kubernetes, an endpoint is a key resource that a Service uses for service discovery. It tracks changes to pods that match the Service's selector in real time. When a pod is deleted or recreated and its IP address changes, the endpoint resource immediately updates its list of pod IP addresses and ports. This ensures the Service always directs traffic to active, healthy pods.

IPVS

IPVS is a load balancer based on the Linux Virtual Server (LVS) feature in the Linux kernel. It manages Service traffic by creating a virtual IP that distributes requests to backend pods.

When you create a Service in Kubernetes, kube-proxy configures rules in the IPVS table. These rules define how traffic is forwarded from the node's virtual IP to the backend pods. You can view the current IPVS routing table and rules on a cluster node using the ipvsadm command.

Important

If the ipvsadm tool is not installed, run the sudo yum install ipvsadm command to install it.

iptables

iptables works with a set of configurable tables and chains. Each chain contains a set of rules that control the flow of network packets.

When you create a Service in Kubernetes, kube-proxy adds corresponding rules to iptables. These rules use the Service's label selector to forward packets to the correct pods. You can view the current iptables NAT table and rules on a cluster node using the iptables -t nat -L command.

nftables

nftables is the next-generation packet filtering framework in the Linux kernel, designed to replace iptables. It uses a unified rule set and a more efficient packet matching mechanism to handle network traffic rules.

When you create a Service in a Kubernetes cluster, kube-proxy uses the nftables API to create tables and chains that manage the Service's traffic forwarding rules. You can view all active nftables rules and table structures on a cluster node using the nft list ruleset command.

Service types

Important

If the Cloud Controller Manager version is v2.5.0 or later, using a CLB instance to create a Service in the console becomes a whitelisted feature that only supports pay-as-you-go billing. To create a CLB-type Service in the console, submit a request on the Quota Center page.

Name	Description	Use cases	Billing
ClusterIP	The default Service type. A ClusterIP Service is assigned a virtual IP address that is only reachable from within the cluster.	Ideal for services that only need to communicate within the same cluster. For example, if a frontend application pod needs to access a backend database within the same cluster, you can expose the database as a ClusterIP Service.	Free of charge.
NodePort	A NodePort Service opens a specific port on every node in the cluster. You can access the Service from outside the cluster using `<NodeIP>:<NodePort>`. This mechanism primarily operates at Layer 4 (Transport Layer) of the OSI model.	Suitable for exposing a service to the internet for development, testing, or other low-traffic applications. For example, you can use a NodePort Service to deploy and debug a web application in a test environment. Unlike a LoadBalancer Service, it does not provide load balancing across nodes. Traffic is sent to only one node, which can easily become a resource bottleneck.	Free of charge. To enable public internet access, you must associate an EIP with the node. For more information about EIP billing, see Billing overview.
LoadBalancer	A LoadBalancer Service extends the NodePort type by provisioning an external load balancer that distributes traffic across pods in the cluster. The Service automatically provides an external IP address that clients can use to access it. It supports both Layer 4 (TCP/UDP) and Layer 7 (HTTP/HTTPS) traffic management.	Ideal for applications running on a public cloud that require a stable, easy-to-manage external entry point. For example, public services in a production environment that need to be accessed from the internet and must handle large volumes of external traffic with high availability, such as web applications or API services. Important For intra-cluster communication, always use a `ClusterIP` Service. This is the most stable, efficient, and architecturally sound method. In contrast, accessing a `LoadBalancer` type Service from within the same cluster can lead to inconsistent behavior. Its availability is affected by multiple factors, including: The cloud provider's specific implementation of the LoadBalancer. The CNI network plugin used by the cluster (such as Flannel, Terway-Eniip, or Cilium). The operating mode (iptables, IPVS, or nftables) and version of `kube-proxy`. The Service's `externalTrafficPolicy` setting (`Cluster` or `Local`). Therefore, accessing a LoadBalancer IP from within the cluster may vary significantly or even fail across different environments and Kubernetes versions. Example scenario: Flannel + IPVS + externalTrafficPolicy=Local Consider a cluster that uses the Flannel CNI network plugin where a `LoadBalancer` Service is configured with `externalTrafficPolicy: Local`. If a request is sent to the LoadBalancer's external IP from a node that does not have a corresponding backend pod: Kubernetes version < 1.24: The request will not be forwarded correctly, and the access will fail. Kubernetes version ≥ 1.24: `kube-proxy` can fall back from `Local` to `Cluster` behavior to support intra-cluster access. The request will be successfully forwarded to a backend pod on another node.	For information about fees for load balancing instances, see CLB Billing Overview NLB billing rules.
Headless Service	A Headless Service has no virtual IP address. A DNS query for the service name returns a list of pod IP addresses instead of a single service IP. This allows you to discover and connect to specific pods directly.	Ideal for applications that need to communicate directly with specific backend pods rather than through a proxy or load balancer. For example, if you deploy a stateful application like a ClickHouse database service, you can use a Headless Service. This allows application pods to directly access each ClickHouse pod, balancing data reads or performing targeted writes to improve data processing efficiency.	Free of charge.
ExternalName	An ExternalName Service maps an internal service name to an external domain name. This allows pods inside the cluster to access the external domain using the internal service name.	Ideal when a cluster needs to access a service exposed under a public domain name. For example, if your application pods need to access an external database domain, you can use an ExternalName Service to map the domain to an internal service name, which allows direct access from within the cluster.	Free of charge.

How it works

ClusterIP

Creation and allocation
When you create a ClusterIP Service in an ACK cluster, the control plane assigns it a virtual IP address (ClusterIP) that is accessible only from within the cluster.
Traffic forwarding
When you access the ClusterIP, kube-proxy intercepts the traffic and forwards it to a backend pod using a round-robin scheduling algorithm.
Service discovery
When a ClusterIP Service is created, CoreDNS registers a DNS record for it, allowing the service to be resolved and accessed by its name. The format is service-name.namespace.svc.cluster.local:port, for example, nginx.default.svc.cluster.local:80.
Pod labels and endpoint tracking
A Service uses a label selector to identify its backend pods.
The control plane continuously monitors pod changes. When pods that match the Service's label selector are added, updated, or removed, the control plane updates the endpoint.

NodePort

Creation and allocation
When you create a NodePort Service, the cluster opens a port (the NodePort) on its nodes to allow external access.
Traffic forwarding
kube-proxy listens on the NodePort, which is automatically chosen from a default range of 30000-32767. It routes external requests to the ClusterIP, which then forwards them to the backend pods.
External access
You can access the Service externally using the node's IP address and the static port (NodePort) in the format <NodeIP>:<NodePort>.

LoadBalancer

Creation and allocation
When you create a LoadBalancer Service, the control plane automatically interacts with the load balancing service to create a load balancer instance to handle traffic. For more information, see Use an existing Server Load Balancer instance to expose an application and Expose an application with an auto-provisioned LoadBalancer Service.
Traffic forwarding
When external traffic reaches the external IP of the load balancer instance, it is routed to the port on the nodes. Then, kube-proxy forwards the traffic to the backend pods.
Route and health check configuration
The load balancer automatically configures listener ports and performs health checks to ensure traffic is routed only to healthy pods.

External traffic policy

LoadBalancer and NodePort Services have an externalTrafficPolicy setting that controls how external traffic is routed. The behavior of this setting differs between clusters that use the Terway-Eniip and Flannel network plugins.

Note

Log on to the ACK console. On the Clusters page, click the name of your cluster. On the Basic Information tab, you can view the CNI network plugin that your cluster uses.

Flannel network plugin

Item	Local	Cluster
Backend server attachment	Only nodes that host backend pods are added as backend servers to the load balancer.	All nodes in the cluster are added as backend servers to the load balancer.
Load balancer quota	Consumes fewer load balancer quota resources. For more information, see Quota limits.	Consumes a large number of load balancer quota resources because all cluster nodes are attached as backends. For more information, see Quota limits.
Intra-cluster access to Service	Only nodes that host backend pods for the Service can access it.	Any node in the cluster can access the Service.
Pod load balancing	Load balancing between pods is disabled by default. To enable load balancing, set the scheduler to WRR by adding the annotation `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` to the Service.	Load balancing between pods is enabled by default.
Source IP preservation	Supported.	Not supported.
Session persistence	Supported.	Not supported.
Use cases	Applications that need to preserve the original client IP address, such as for logging based on the source IP.	When high service availability is required and source IP preservation is not a concern, such as in large web application clusters.

Terway-Eniip network plugin

Item	Local	Cluster
Backend server attachment	Pods are directly added to the load balancer as backend servers.
Load balancer quota	Consumes fewer load balancer quota resources because only application pods are attached. For more information, see Quota limits.
Intra-cluster access to Service	When accessing the Service from within the cluster, traffic passes through kube-proxy on the node and is subject to the `externalTrafficPolicy`. As a result, only nodes that host backend pods for the Service can access it.	Any node in the cluster can access the Service.
Pod load balancing	Load balancing between pods is enabled by default.
Source IP preservation	Supported.
Session persistence	Supported.

Usage notes

Before using the Service load balancing feature, review the relevant considerations. For more information, see Considerations for configuring Service load balancing.