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