Services

Rensin’s Kubernetes: Scheduling the Future at Cloud Scale (2015), ch. 3, "Organize, Grow, and Go", already frames the problem this way: a client — another Pod, or a person outside the cluster — needs a stable address to talk to "the catalog API", not to any one of its interchangeable replicas, and that address has to keep working as individual Pods are replaced, rescheduled or scaled. A Service solves this with three cooperating pieces:

Book 1’s "client request path" — DNS lookup, then a load balancer, then the Service, then a Pod — is still exactly the shape of an external request today; only the components behind each arrow changed, most visibly the frontend load balancer, discussed in The portal IP, CreateExternalLoadBalancer, and the userspace proxy, as history below.

spec.type selects how a Service is reachable. All four keep the same selector-driven Endpoints/EndpointSlices machinery underneath except ExternalName, which is a special case with no selector, no proxying and no Endpoints at all.

Source: Kubernetes Docs — Service.

ExternalName is worth dwelling on because it looks like the odd one out but is in fact the simplest of the four — a pure DNS alias, evaluated fresh on every lookup, with no IP of its own and no health checking:

Source: Kubernetes Docs — Service — ExternalName.

Setting spec.clusterIP: None on an otherwise ordinary Service turns off virtual-IP load-balancing entirely: CoreDNS resolves the Service’s name to the individual Pod IPs directly (an A/AAAA record per ready Pod) instead of to one proxied address, and, when the Service is also referenced by a StatefulSet's spec.serviceName, one additional per-Pod DNS record is created for each ordinal. A client that needs to reach every backend, or one specific backend, rather than "any one of them picked for me", uses this instead of a load-balanced ClusterIP —  StatefulSets is the worked example with a full manifest and diagram.

Source: Kubernetes Docs — Service — Headless Services.

Dropping spec.selector entirely produces a Service that the EndpointSlice controller does not manage at all — nothing populates its endpoints automatically, because there is no selector to match Pods against. Hightower, Burns & Beda’s Kubernetes: Up and Running (1st ed., 2017 sampler), ch. 4 (book ch. 13), "Integrating Storage Solutions and Kubernetes", builds exactly this to import an external service into the cluster’s own naming: a legacy database, or a service still running outside Kubernetes, gets a Service name and DNS entry that in-cluster code can call like any other backend, with the actual address supplied by hand instead of by a label selector. The book wires this with the old, now-deprecated Endpoints object (ExternalName did not yet exist in every case it needed, and EndpointSlice did not exist at all); the current way to do the same thing is a selectorless Service paired with a manually created EndpointSlice:

Source: Kubernetes Docs — Service — Services Without Selectors and Kubernetes Docs — EndpointSlices.

The same chapter also uses a selectorless Service (there, an ExternalName one) for per-namespace resolution: a bookshelf-test namespace and a bookshelf-prod namespace each define a Service named identically (legacy-inventory) but pointing at their own environment’s backend — test at a sandbox database, prod at the real one. In-cluster code that simply calls legacy-inventory (or, with the fully qualified name, legacy-inventory.<namespace>.svc.cluster.local, see DNS and Service Discovery) then gets test/prod parity for free: the exact same manifest and the exact same client code run unmodified in either namespace, because the difference lives entirely in which namespace’s Service object is doing the resolving, not in any code path. This is also the pattern the book uses for a Service that has no health checks of its own to run against an external backend — the cluster trusts whatever address it is given, with no readiness or liveness probing on Kubernetes' side (see Health Probes and Container Lifecycle for the probing Kubernetes does run, which never applies to a manually populated EndpointSlice).

A Service’s spec.ports is a list, not a single value: one Service can expose several ports at once (an HTTP port and a separate metrics port, say), each entry independently mapping its own port to a targetPort on the Pod. Once a Service (or a Pod) has more than one port, every port/targetPort needs a distinct name, because that name — not a bare number — is what a multi-port Pod spec and things like a an Ingress backend reference unambiguously.

Source: Kubernetes Docs — Service — Multi-Port Services.

sessionAffinity controls whether repeated requests from the same client are routed to the same Pod whenever possible. The default, None, load-balances every request independently (round-robin-ish, depending on the kube-proxy mode below); ClientIP instead pins a client’s source IP to whichever Pod it was first routed to, for sessionAffinityConfig.clientIP.timeoutSeconds (default three hours) since its last request. This is a coarse tool — it affinities by IP, not by an application-level session token, so it groups every client behind the same NAT gateway together — and it has nothing to do with externalTrafficPolicy below, which is about which node handles a packet, not which Pod a repeat client lands on.

By default, any node that receives traffic for a NodePort or LoadBalancer Service may forward it to any matching Pod cluster-wide, even one on a different node — convenient, but it means the packet’s original source IP is usually replaced by the forwarding node’s IP by the time it reaches the Pod (SNAT), and it costs an extra network hop whenever the chosen Pod is not local. spec.externalTrafficPolicy: Local changes that for externally-arriving traffic: a node only forwards to Pods running on itself, dropping the packet if it has none, in exchange for the client’s real source IP being preserved end to end and one fewer network hop. spec.internalTrafficPolicy: Local is the same hard rule applied to traffic that originates inside the cluster (a Pod calling the Service’s ClusterIP): kube-proxy only routes to a Pod on the caller’s own node and drops the traffic when that node has none — there is no cluster-wide fallback. It suits a node-local agent that runs on every node (a DaemonSet); for a soft same-node preference that does fall back, use trafficDistribution: PreferSameNode (below) instead. Both default to Cluster (the original, no-locality behaviour); both are read straight off EndpointSlice conditions and nodeName, which is exactly what the flat Endpoints API could not represent per-endpoint.

Source: Kubernetes Docs — Virtual IPs and Service Proxies and Kubernetes Docs — Using Source IP.

kube-proxy is the node-local component that actually programs the packet-forwarding rules an EndpointSlice’s list of addresses describes, in one of three modes:

Source: Kubernetes Docs — Virtual IPs and Service Proxies.

kubectl expose creates a Service from an already-running Deployment, ReplicaSet, Pod or (with --protocol) another Service, inferring the selector from the target’s own labels instead of it being typed out by hand — the quick path from "I have a running Deployment" to "it has a Service in front of it", and the one Hightower, Burns & Beda’s ch. 5 (book ch. 14) uses throughout to put a Service in front of each app it deploys.

Source: Kubernetes Docs — kubectl expose and Kubernetes Docs — Connecting Applications with Services.

Every node’s kube-proxy watches the same EndpointSlice objects independently and programs its own local rules from them; externalTrafficPolicy, internalTrafficPolicy and trafficDistribution are all just filters kube-proxy applies to that same watched list before writing rules — which is why they need no per-node configuration of their own, only the Service’s spec. Source: Kubernetes Docs — EndpointSlices and Kubernetes Docs — Virtual IPs and Service Proxies.