Use Services to implement service discovery and load balancing - Container Service for Kubernetes

In Kubernetes, a Service is an abstraction that helps you expose a group of pods over a network. A Service provides a domain name for the pods exposed by the Service and implements load balancing among the pods. This topic describes how a Service works and the precautions for configuring a LoadBalancer Service. This topic also describes how to select different types of Services to expose applications.

Terms

Service

After you create a pod, you may encounter the following issues when you directly access the pod:

The pod may be deleted and recreated by its controller (such as a Deployment). Therefore, access to the pod is unstable.
An IP address is dynamically allocated to the pod after the pod is launched. You cannot predict which IP address is allocated before the pod is launched.
An application consists of multiple pods that run the same image. Therefore, it is not feasible to access individual pods of an application.

To address the preceding issues, Kubernetes provides the Service object. A Service provides a stable network interface and a persistent IP address for the pods exposed by the Service. A Service uses label selectors to select the pods to be exposed and implements load balancing among the pods. This addresses the preceding issues and ensures high availability and efficiency for the application.

Endpoint

In Kubernetes, endpoints play an important role in implementing service discovery based on Services. An endpoint tracks the changes in the pods that match the label selectors of a Service in real time. When a pod is deleted or recreated, the pod IP changes. In this case, the corresponding endpoint updates the IP address and port of the new pod to ensure that the Service can forward traffic to the new pod.

IPVS

IP Virtual Server (IPVS) is a load balancer based on Linux Virtual Server (LVS). IPVS creates virtual IP addresses to distribute the traffic received by Services to the backend pods of the Services.

When you create a Service, kube-proxy specifies routing rules for the Service in the IPVS route table. The routing rules determine how traffic is forwarded from the virtual IP address of the node to the backend pods. You can run ipvsadm commands on a node to query the IPVS route table of the node and the routing rules in the table.

Important

If the ipvsadm tool is not installed, you can install it by running the command sudo yum install ipvsadm.

iptables

iptables uses a set of configurable tables and chains to determine how packets are transmitted. Each chain corresponds to a set of rules.

When you create a Service, kube-proxy specifies routing rules for the Service in the tables of iptables. These rules determine how packets are transmitted to the pods that match the label selectors of the Service. You can run the iptables -t nat -L command on a node to query the tables of iptables on the node and the routing rules in the tables.

Service type

Feature	Description	Scenario	Billing
ClusterIP	The default Service type. A ClusterIP Service uses an intra-cluster virtual IP address.	This type of Service is suitable for scenarios where you need to expose your application only within the cluster. For example, if a pod of a frontend application needs to access a backend database in the same cluster, you can use a ClusterIP Service to expose the database within the cluster.	Free of charge.
NodePort	A NodePort Service exposes a node port. You can access a NodePort Service by sending requests to `<NodeIP>:<NodePort>`. NodePort Services work at Layer 4 of the Open Systems Intercommunication (OSI) model.	This type of Service is suitable for scenarios where you need to temporarily expose your application to the Internet or your application needs to receive a small amount of external traffic on a port. For example, if you want to deploy a web application in the test environment, you can use a NodePort Service to expose the application. Compared with LoadBalancer Services, NodePort Services do not implement load balancing among nodes. If you access an application by using a NodePort Service, traffic is forwarded only to the node to which you send requests. In this case, resource bottlenecks may easily occur on the node.	Free of charge. If you want to enable Internet access, associate an elastic IP address (EIP) with the node. For more information about EIP billing, see Billing overview.
LoadBalancer	A LoadBalancer Service is similar to a NodePort Service configured with a load balancer. This type of Service can evenly distribute traffic to multiple pods. A LoadBalancer Service automatically provides a public IP address to expose the backend pods to external access. LoadBalancer Services can process TCP and UDP requests at Layer 4 and manage HTTP and HTTPS requests at Layer 7.	This type of Service is suitable for scenarios where you want to provide a stable and easy-to-manage ingress for an application deployed on the cloud. For example, you can use LoadBalancer Services to expose public services deployed in the production environment, such as web applications and API services, to the Internet. This ensures the high availability of the services and allows them to withstand traffic spikes.	Server Load Balancer (SLB) charges you fees for SLB instances used by LoadBalancer Services. For more information, see CLB billing overview and NLB billing rules.
Headless Service	A headless Service does not have a fixed virtual IP address. When you access the backend pods of a headless Service, the Service performs a DNS lookup and returns a list of IP addresses. Then, you can directly connect to any IP address in the list based on your requirements.	This type of Service is suitable for scenarios where you need to directly access individual backend pods by using DNS records instead of proxies or load balancers. For example, you can use a headless Service to expose a ClickHouse application that is deployed as a StatefulSet. This way, you can access each pod of the ClickHouse application. This allows you to balance reads and writes among the pods and improve data processing efficiency.	Free of charge.
ExternalName	An ExternalName Service is used to map a Service to an external domain name. This allows pods in the cluster to access the external domain name by using the Service.	This type of Service is suitable for scenarios where your cluster needs to access public domain names. For example, if your application needs to access the domain name of an external database, you can map the domain name to an ExternalName Service. This way, the pods of the application can access the domain name by using the ExternalName Service from within the cluster.	Free of charge.

How Services work

ClusterIP

Creation and allocation
When you create a ClusterIP Service in a Container Service for Kubernetes (ACK) cluster, the control plane of the cluster allocates a virtual IP address to the Service. This IP address can be accessed only from within the cluster.
Traffic forwarding
When you access a ClusterIP Service, the request is captured by kube-proxy. Then, kube-proxy forwards the request to a backend pod by using the round-robin scheduling algorithm.
Service discovery
When a ClusterIP Service is created, CoreDNS registers a DNS record that enables the Service to be resolved and accessed by its name. To access a ClusterIP Service, send a request to an endpoint in the Service.Namespace.svc.cluster.local:port format. Example: nginx.default.svc.cluster.local:80.
Pod labels and endpoint tracking
Each Service has a set of label selectors that are used to select backend pods.
The control planes of a cluster monitor pod changes in the cluster in real time. When a new pod matches the label selectors of a Service or existing pods that match the label selectors are updated or deleted, the control planes of the cluster update the endpoint of the Service.

NodePort

Creation and allocation
When you create a NodePort Service, the cluster opens a port on the node for the Service, allowing external access.
Traffic forwarding
kube-proxy listens on the port exposed for the NodePort Service. The port is automatically allocated from a specific port range (30000 to 32767 by default). When an external request reaches the port on the node, kube-proxy routes the request to the ClusterIP Service, then forwards it to the backend pod.
External Access
You can access a NodePort Service by sending requests to its external endpoint in the <NodeIP>:<NodePort> format.

LoadBalancer

Creation and allocation
When you create a LoadBalancer Service, the control plane of the cluster automatically create an SLB instance for the Service. For more information, see Use an existing SLB instance to expose an application and Use an automatically created SLB instance to expose an application.
Traffic forwarding
When an external request reaches the external IP address of the SLB instance, the SLB instance routes the request to the port on the node. Then, kube-proxy forwards the request to a backend pod.
Configure routing and health check settings
The SLB instance automatically uses a listening port and conducts health checks, ensuring that the requests are routed only to healthy pods.

External traffic policies: Local and Cluster

You can configure the external traffic policy of a LoadBalancer or NodePort Service by specifying the externalTrafficPolicy parameter. The external traffic policy specifies how external requests are routed to backend pods. Two external traffic policies are supported: Local and Cluster. The features of external traffic policies vary based on the network plug-in used by the cluster. The following section describes the features of external traffic policies when Terway-Eniip or Flannel is used as the network plug-in.

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 network plug-in of the cluster in the Cluster Information section.

Flannel

In the Flannel network plug-in:

Local: Traffic is routed only to pods on the node to which the requests are sent.
Cluster: Traffic can be routed to pods on other nodes in the cluster.

The following table describes the differences between the Local policy and the Cluster policy.

Item	Local	Cluster
Backend servers	Only the nodes on which the backend pods are deployed are added to SLB instances as backend servers.	All nodes in the cluster are added to SLB instances as backend servers.
SLB resource quotas	This policy consumes a small amount of SLB resources and does not require high SLB resource quotas. For more information about SLB resource quotas, see Quotas.	This policy requires high SLB resource quotas because all nodes in the cluster are added to SLB instances as backend servers. For more information about SLB resource quotas, see Quotas.
Access to the IP address of an SLB instance	Only the nodes on which the backend pods are deployed can access the IP address of an SLB instance.	All nodes in the cluster can access the IP address of an SLB instance.
Load balancing among pods	By default, load balancing among pods is disabled. To enable load balancing among pods, set the scheduling algorithm to weighted round-robin (WRR) by adding the `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler:"wrr"` annotation to the Service YAML file.	By default, load balancing among pods is enabled.
Source IP preservation	Supported	Not supported
Session persistence	Supported	Not supported
Use scenarios	Applications that need to preserve client IP addresses, such as applications that need to record client IP addresses in logs.	Applications that require high availability but do not need to preserve client IP addresses, such as large web application clusters.

Terway-Eniip

If the cluster uses the Terway-Eniip network plug-in, traffic is directly forwarded to backend pods, regardless of which external traffic policy is used.