Service Overview

After a pod is created, accessing it directly can result in certain problems:

• The pod can be deleted and recreated at any time by a controller such as a Deployment. If the pod is recreated, access to it may fail.
• An IP address cannot be assigned to a pod until the pod is started. Before the pod is started, its IP address is unknown.
• Applications usually run on multiple pods that use the same image. Accessing pods one by one is not efficient.

For example, a Deployment is used to deploy the frontend and backend of an application. The frontend calls the backend for computing, as shown in Figure 1. Three pods are running in the backend, and they are independent and replaceable. When a backend pod is recreated, the new pod is assigned with a new IP address, but the frontend pod is unaware of this change.

Figure 1 Inter-pod access

To solve these problems, Kubernetes introduces Services, which provide stable network interfaces and persistent IP addresses for pods. You can set these IP addresses using Service CIDR blocks during cluster creation. The Service CIDR blocks are used to assign IP addresses to Services. A Service uses a label selector to identify its target pods and uses load balancing to evenly distribute traffic among them. This abstraction eliminates the complexity of directly accessing individual pods and enhances both the availability and efficiency of workloads.

For the example above, a Service is created for the backend pods and used for the frontend pod to access these backend pods. In this way, the frontend pod remains unaffected by any changes to the backend pods, as shown in Figure 2.

Figure 2 Accessing pods through a Service

In Kubernetes, both Endpoints and EndpointSlices are resource objects used to manage the network endpoints of service backend pods.

• Endpoints are a traditional resource object for service discovery. An Endpoint is a collection of endpoints of all pods associated with a Service. An Endpoint is automatically created for each Service with a selector defined. It records a list of IP addresses and ports for all matching pods. After a pod is deleted or recreated, its IP address may change. The Endpoint updates the pod IP address and port accordingly to ensure that the Service continues to route traffic to the correct pods.

  Key features of Endpoints include:

  • Each Endpoint object corresponds to a single Service.
  • Each Endpoint stores the IP addresses and ports of all backend pods associated with the Service.
  • Any change to a pod's status triggers an update to the corresponding Endpoint object.
  • By default, an Endpoint object can hold up to 1000 endpoints. If this limit is exceeded, additional endpoints are truncated and not included in the object.
• EndpointSlices are an alternative to the traditional Endpoints API, introduced as an alpha feature in Kubernetes v1.16 and promoted to stable in v1.21. They address the performance limitations of Endpoints in large clusters and manage network endpoints using sharding.
  • Each Service is associated with one or more EndpointSlices.
  • By default, each EndpointSlice can hold up to 100 endpoints. When this limit is exceeded, Kubernetes creates additional EndpointSlices to accommodate the remaining endpoints.
  • Endpoints are grouped by protocol, port, and Service name.
  • EndpointSlices support IPv4, IPv6, and fully qualified domain name (FQDN) address types.

The differences between Endpoint and EndpointSlice objects are listed in the table below.

kube-proxy is a key component of a Kubernetes cluster. It is used for load balancing and forwarding data between a Service and its backend pods. CCE supports two iptables and IPVS request forwarding.

• iptables is a Linux kernel function for processing and filtering a large number of data packets. It allows flexible sequences of rules to be attached to various hooks in the packet processing pipeline. When iptables is used, kube-proxy implements NAT and load balancing in the NAT pre-routing hook. For each Service, kube-proxy installs an iptables rule which captures the traffic destined for the Service's ClusterIP and ports and redirects the traffic to one of the backend pods. By default, iptables randomly selects a backend pod. For details, see iptables proxy mode.
• IPVS is constructed on top of Netfilter and balances transport-layer loads as part of the Linux kernel. IPVS can direct requests for TCP- or UDP-based services to the real servers, and make services of the real servers appear as virtual services on a single IP address.

  In the IPVS mode, kube-proxy uses IPVS load balancing instead of iptables. IPVS is designed to balance loads for a large number of Services. It has a set of optimized APIs and uses optimized search algorithms instead of simply searching for rules from a list. For details, see IPVS proxy mode.

For details about the comparison between the iptables and IPVS, see Comparing iptables and IPVS.

For a NodePort and LoadBalancer Service, requests are first sent to the node port, then the Service, and finally the pod backing the Service. The backing pod may be not located in the node receiving the requests. By default, the backend workload can be accessed from any node IP address and service port. If the pod is not on the node that receives the request, the request will be redirected to the node where the pod is located, which may cause performance loss.

• Using YAML: The externalTrafficPolicy parameter in a Service is used to determine whether the external traffic can be routed to the local nodes or cluster-wide endpoints. The following is an example:

  apiVersion: v1
  kind: Service
  metadata:
    name: nginx-nodeport
  spec:
    externalTrafficPolicy: Local #  Service affinity
    ports:
    - name: service
      nodePort: 30000
      port: 80
      protocol: TCP
      targetPort: 80
    selector:
      app: nginx
    type: NodePort

  • If the value of externalTrafficPolicy is Local, requests sent from Node IP address:Service port will be forwarded only to the pod on the local node. If the node does not have a pod, the requests are suspended.
  • If the value of externalTrafficPolicy is Cluster, requests are forwarded within the cluster and the backend workload can be accessed from any node IP address and service port.
  • If externalTrafficPolicy is not set, the default value Cluster will be used.

The table below compares the two options of service affinity (externalTrafficPolicy).