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.

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.
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.
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.

How Services work

ClusterIP

Creation and allocation
When you create a ClusterIP Service in a Container Service for Kubernetes (ACK) cluster, the control planes of the cluster allocate a virtual IP address to the Service from the Service CIDR block of the cluster. The virtual IP address is a cluster IP address. The cluster IP address can be accessed only from within the cluster and does not belong to the pod CIDR block.
Traffic forwarding
When you access a ClusterIP Service from within the cluster, the request is captured by kube-proxy. kube-proxy forwards the request to a backend pod by using the round-robin scheduling algorithm based on the iptables or IPVS rules.
Service discovery
When you create a ClusterIP Service, a new DNS record is added to CoreDNS. The DNS record can be used to resolve a ClusterIP Service name to its cluster IP address. To access a ClusterIP Service, send a request to an endpoint in the Service.Namespace.svc.cluster.local:port format, such as 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 allocates a cluster IP address to the Service and exposes a node port for the Service. The node port is automatically allocated from a specific port range (30000 to 32767 by default). You can also specify a custom node port.
Traffic forwarding
kube-proxy listens on the node port exposed for a NodePort Service on each node in the cluster. When an external request reaches the node port on a node, kube-proxy routes the request to the cluster IP address and then 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 without specifying an SLB instance, the control planes 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 node port on a node based on the load balancing policy. Then, the kube-proxy on the node forwards the request to a backend pod based on the iptables or IPVS rules.
Configure routing and health check settings
The SLB instance automatically uses the listening port specified in the Service YAML file and forwards requests received on the port to pods that match the label selectors of the Service. In addition, SLB automatically configures health check settings for the SLB instance to ensure 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

If the cluster uses the Flannel network plug-in, the NodePort Services on nodes forward traffic to the backend pods.

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.