The Different Facets of a Service

The Kubernetes Service resource is considerably more complex than people often realize. When you create a Service, typically the cluster machinery will:

• Allocate a cluster-wide IP address for the Service itself (its cluster IP);
• Allocate a DNS name for the Service, resolving to the cluster IP (its DNS name);
• Collect the separate cluster-wide IP addresses assigned to each Pod matched by the Service’s selector (the endpoint IPs) into the Service’s Endpoints or EndpointSlices.
• Configure the network such that traffic to the cluster IP will be load-balanced across all the endpoint IPs.

Unfortunately, these implementation details become very important when considering how Gateway API can work for service meshes!

In GAMMA initiative work, it has become useful to consider Services as comprising two separate facets:

• The frontend of the Service is the combination of the cluster IP and its DNS name.

• The backend of the Service is the collection of endpoint IPs. (The Pods are not part of the Service backend, but they are of course strongly associated with the endpoint IPs.)

The distinction between the facets is critical because the gateway and the mesh each need to decide whether a request that mentions a given Service should be directed to the Service’s frontend or its backend:

• Directing the request to the Service’s frontend (Service routing) leaves the decision of which endpoint IP to use to the underlying network infrastructure (which might be kube-proxy, a service mesh, or something else).

• Directing the request to the Service’s backend (endpoint routing) is often necessary to enable more advanced load balancing decisions (for example, a gateway implementing sticky sessions).

While Service routing may be the most direct fit for Ana‘s sense of routing, endpoint routing can be more predictable when using Gateway API for both north/south and east/west traffic. The GAMMA initiative is working to formalize guidance for this use case.