Due to the agile iteration and rapid elasticity requirements of cloud-native applications, and the short lifespan of individual containers and their related network resources, a fixed access address and automatic load balancing are necessary for quick business scalability. CCSE uses Service to provide a fixed access entry for a group of containers and load balance traffic among them. Implementation principles are as follows:
n When creating a Service object, CCSE assigns a relatively fixed Service IP address.
n By using the selector field, a group of containers is chosen, and the Service IP address and port are load balanced to the IP addresses and ports of this group of containers.
CCSE supports various Service network modes to accommodate different sources and types of client access:
l ClusterIP
A ClusterIP type Service is used for internal application communication within the cluster. If your application needs to be exposed to provide services within the cluster, please use a ClusterIP type Service.
l NodePort
A NodePort type Service exposes applications deployed in the cluster to the outside world through a fixed port on the cluster nodes. This allows access to the applications from outside the cluster using the node IP address and the fixed port.
l LoadBalancer
A LoadBalancer type Service also exposes applications deployed within the cluster to the outside world. However, it does this through the eSurfing Cloud load balancer, offering higher availability and performance compared to the NodePort method.
l Headless Service
A Headless Service type is specified by setting the clusterIP field to "None" in the Service properties. When using the Headless Service type, the Service does not have a fixed virtual IP address. When a client accesses the Service domain name, DNS returns the IP addresses of all back-end Pod instances. Clients must use DNS load balancing to evenly distribute the traffic among the back-end instances.
l ExternalName
The ExternalName type of Service maps an external domain name to a Service within the cluster. For example, mapping an external database domain name to an internal Service name in the cluster allows direct access within the cluster using the Service name.