Each pod in Kubernetes clusters has an IP address. However, pods are frequently created and deleted. Therefore, it is not practical to directly expose pods to external access. The Service resource decouples the frontend from the backend to provide a loosely coupled microservices architecture. 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.
How a Service works
Cloud-native applications typically 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. ACK allows you to create a Service as the ingress and load balancer of a pod. How a Service works
When you create a Service, ACK assigns a stable IP address to the Service.
You can configure the selector parameter to select a pod and then map the IP address and port of the Service to the IP address and port of the pod for load balancing.
Precautions
Before you use Services to implement load balancing, we recommend that you learn about the precautions for configuring a LoadBalancer Service. For more information, see Precautions for configuring a LoadBalancer type Service.
Use Services to expose applications
ACK provides the following types of Services to handle requests from different sources and clients:
ClusterIP
A ClusterIP Service is used for handling access within the cluster. If you want your application to provide services within the cluster, create a ClusterIP Service.
NoteBy default, ClusterIP is selected when you create a Service.
When you create a ClusterIP Service, no SLB instance is created.
NodePort
A NodePort Service is used to expose an application to the Internet. You can use the IP address and port of a cluster node to expose your application. This way, your application can be accessed through the node IP address and port.
LoadBalancer
A LoadBalancer Service is also 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 Use an automatically created SLB instance to expose an application.
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.
You can use annotations to configure Server Load Balancer (SLB) instances. For more information, see Add annotations to the YAML file of a Service to configure CLB instances and Configure NLB instances by using annotations.
Differences between external traffic policies
The external traffic policy feature varies based on the network plug-in that is used by the cluster. This section compares the external traffic policy features provided by the Flannel and Terway-Eniip network plug-ins.
Log on to the Container Service for Kubernetes (ACK) console. On the Clusters page, click the name of the cluster that you want to manage. 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: This policy routes traffic only to pods on the node where the Service is deployed.
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 annotation | By default, load balancing among pods is enabled. |
Source IP preservation | Supported | Not supported |
Session persistence | Supported | Not supported |
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.
The following table describes the differences between the Local policy and the Cluster policy.
Item | Local | Cluster |
Backend servers | Pods can be 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. | |
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 enabled. | |
Source IP preservation | Supported | |
Session persistence | Supported | |
References
For more information about the precautions for configuring a LoadBalancer Service and the policies that are used by the Cloud Controller Manager (CCM) to update SLB resources, see precautions for configuring a LoadBalancer type Service.
If Service annotations do not take effect or SLB instances cannot be associated with Services, refer to Service FAQ and Service troubleshooting.