Chapter 11: Exposing pods with services

Introduction

The chapter introduces Services as a single address for replicated pods and explains the network model that lets pods communicate directly.

• Single address for pod replicas: Explain why clients need a Service when several pod replicas provide the same service: clients use one address instead of tracking and connecting to individual pods.
  Why it matters: This explains why the Kiada, Quiz, and Quote services need Service objects when each has multiple pod replicas.
• Flat network between pods: Describe how pods communicate directly: each has its own IP address on a flat private pod network, and packets between pods retain their source and destination addresses and ports regardless of where the pods run.
  Why it matters: This gives you the network model behind direct communication between pods.

Key terms: Service objects, pod replicas, pod network, flat address space, SNAT, DNAT

11.1 Exposing pods via services

This section explains why changing pod IP addresses and multiple replicas make direct pod addressing impractical, and why Services are used to expose pods.

• Stable access to pod replicas: Explain why another pod cannot reliably connect to an application using a pod IP address known in advance, and why multiple replicas call for one address that distributes requests among them.
  Why it matters: It explains why clients need an address for an application rather than an address for one particular pod.
• External access through Services: Distinguish development-only port forwarding from the use of a Kubernetes Service to make a group of pods accessible to clients outside the cluster.
  Why it matters: It separates a temporary development connection from the approach the section identifies for external clients.

Key terms: pods are ephemeral, pod IP address, pod replicas, load balancer, port forwarding, Kubernetes Service, clients outside the cluster

11.1.1 Introducing services

This section explains how Services provide stable access to changing pods and how label selectors determine which pods back a Service.

• Stable access through Services: Explain how a Service gives clients a stable IP address and forwards each connection to one of its backing pods, even when those pods change in number or location. Describe why this also helps when there is only one pod that may be recreated.
  Why it matters: Clients can keep using the same address while pods are scaled, moved, or recreated.
• Pod membership by label selector: Describe how pod labels and a Service’s label selector determine which pods back the Service. Explain why the quote Service selects both stable and canary quote pods.
  Why it matters: The selector determines which pods can receive connections sent through a Service.

Key terms: Service, stable IP address, backing pods, load balancer, Pod labels, label selector, app=quote, stable, canary

11.1.2 Creating and updating services

This section shows how to create, inspect, and update Services for pods, including their selectors, ports, and IP-family settings.

• ClusterIP service role: Explain that ClusterIP is the default Service type and provides an internal address for workloads in the cluster, but is not sufficient when an application must be accessible from outside the cluster.
  Why it matters: It helps you choose whether the default Service type fits who needs to reach the application.
• Service manifest routing: Describe how the quote Service manifest connects a Service port to matching pods: it accepts connections on port 80 and forwards them to port 80 of a randomly selected pod matching app=quote. Explain the distinction between a Service port and its target port.
  Why it matters: Selectors and ports determine which pods receive a Service’s traffic and where that traffic arrives.
• Creation and selector changes: Describe the two creation methods shown—applying a Service manifest and using kubectl expose—and explain why the quiz Service’s automatically generated selector is changed from matching all the pod’s labels to avoid limiting traffic to stable pods.
  Why it matters: An automatically chosen selector may exclude pods you intend the Service to reach.
• Service port updates: Explain how to change the quiz Service to accept traffic on port 80 while still forwarding it to the quiz pod’s listening port 8080.
  Why it matters: You can present a conventional HTTP port without changing the port the application actually listens on.
• Service IP family settings: Distinguish SingleStack, PreferDualStack, and RequireDualStack policies, and describe how a created Service reports its assigned IP families and addresses.
  Why it matters: The policy determines whether a Service can be created when a cluster does not support both IPv4 and IPv6.

Key terms: ClusterIP, Service, cluster IP address, Service manifest, label selector, port, targetPort, kubectl apply, kubectl expose, kubectl get services -o wide

11.1.3 Accessing cluster-internal services

This section shows how pods reach ClusterIP services, how services distribute connections, and how pods discover service addresses.

• Cluster-Internal Service Access: Explain where a ClusterIP service can be reached and how to test it from inside the cluster. Describe how the Kiada pods use configured service URLs to reach the Quiz and Quote services.
  Why it matters: Testing from a pod distinguishes service connectivity from access to the cluster from your own machine.
• Service Distribution and Affinity: Explain how a service distributes requests among its backing pods and distinguish the None and ClientIP session-affinity settings.
  Why it matters: It explains both why repeated requests can reach different pods and how to keep one client’s connections on one pod.
• Service Names and DNS Search: Describe how pods resolve service names within and across namespaces, and explain why a short name can work without a fully qualified domain name.
  Why it matters: Service names let pods find services without hard-coding their cluster IP addresses.
• Pod DNS Configuration: Describe how dnsPolicy determines the DNS configuration supplied to a pod and how dnsConfig can customize it.
  Why it matters: A pod’s DNS policy affects whether it can resolve cluster service names in the usual way.
• Service Environment Variable Discovery: Explain when Kubernetes injects service address variables into containers, why older pods may lack them, and why DNS or disabling service links may be preferable.
  Why it matters: It explains why service variables may be absent or troublesome even though DNS discovery works.
• Virtual Service IP Limitations: Explain why ping is not a valid test of whether a service is forwarding application traffic, and distinguish port-forwarding to a backing pod from connecting through the service.
  Why it matters: Neither a failed ping nor a successful port-forward proves whether traffic through the service works.

Key terms: ClusterIP, kubectl exec, QUIZ_URL, QUOTE_URL, load balancer, sessionAffinity, None, ClientIP, timeoutSeconds, cluster DNS

11.2 Exposing services externally

The section explains why ClusterIP alone cannot expose the Kiada service outside the cluster and compares four ways to make a service externally reachable.

• ClusterIP external access limit: Explain why the existing ClusterIP service is insufficient for clients outside the cluster.
  Why it matters: This is the reason the section considers other ways to expose the service.
• External IP service routing: Describe what specifying a service external IP tells Kubernetes to do and what must happen for traffic to reach the service.
  Why it matters: An external IP works only if traffic to that address actually reaches a cluster node.
• NodePort and LoadBalancer exposure: Distinguish exposing a service with NodePort from using LoadBalancer, including how clients reach each arrangement and the infrastructure limitation on LoadBalancer.
  Why it matters: The distinction explains whether you arrange the external load balancer yourself or ask Kubernetes to provision one.
• Ingress as shared entry point: Distinguish Ingress from exposure through node ports and load balancers, and state the external-address benefit described here.
  Why it matters: Ingress offers a shared external entry point for multiple services.

Key terms: ClusterIP, Kiada service, spec.externalIPs, Service object, NodePort, node port, LoadBalancer, cluster IP, Ingress object, ingress controller

11.2.1 Exposing pods through a NodePort service

This section explains how a NodePort service exposes selected pods through a port on every cluster node and how to find and test those access points.

• NodePort access and forwarding: Explain how a NodePort service makes pods reachable through every cluster node, including nodes that do not run a selected pod.
  Why it matters: Clients can use a reachable node without having to locate the pod that will handle the request.
• Service and node port settings: Describe what the Kiada NodePort service exposes and how its node port numbers can be chosen.
  Why it matters: Distinguishing service ports from node ports helps you choose the right address and port when connecting.
• Finding reachable NodePort addresses: Describe how to find and test the addresses for a NodePort service, and what can prevent access.
  Why it matters: A node port alone is not enough to reach the application; you also need an accessible node address and an open network path.
• Observed request forwarding and client IP: Describe what the Kiada request example shows about the responding pod and the client IP it reports.
  Why it matters: The response provides visible evidence of cross-node forwarding and cautions against assuming the reported client IP is the original requester’s.

Key terms: NodePort service, node port, cluster IP, selector, NodePort, kubectl get nodes -o wide, INTERNAL-IP, EXTERNAL-IP, Client IP, node

11.2.2 Exposing a service through an external load balancer

This section explains how a LoadBalancer service exposes an application through an external load balancer, how to create one, and what to expect while it is provisioned.

• LoadBalancer traffic path: Trace how client connections reach a LoadBalancer service and explain why clients use the load balancer instead of a particular node.
  Why it matters: It explains both the traffic path and the advantage over directing clients to one node.
• LoadBalancer service configuration: Describe how the section creates a LoadBalancer service from the existing NodePort service manifest, including the role of explicit node ports and applying the update.
  Why it matters: You can add external load balancing without unnecessarily replacing the existing service.
• LoadBalancer availability and address: Explain when an external load balancer address becomes available and what access remains possible if the cluster does not support provisioning one.
  Why it matters: A pending external IP does not necessarily mean the service itself is unusable.

Key terms: LoadBalancer service, NodePort, node port, healthy nodes, type: LoadBalancer, kubectl apply, internal cluster IP, EXTERNAL-IP, <pending>, node ports

11.2.3 Configuring the external traffic policy for a service

This section explains the tradeoffs between Cluster and Local external traffic policies for NodePort and LoadBalancer services.

• Cluster policy forwarding costs: Explain why forwarding external traffic to a pod on another node adds latency and hides the client’s IP address.
  Why it matters: These costs explain why a service might use the Local policy instead.
• Local routing and node eligibility: Describe how to select the Local external traffic policy and why a load balancer must avoid nodes without local service pods.
  Why it matters: Local routing preserves the client IP, but traffic must reach a node that can serve it.
• Per-pod traffic distribution tradeoff: Compare how Cluster and Local distribute traffic when nodes have different numbers of service pods, using the section’s two-node example.
  Why it matters: Choosing Local to avoid extra hops and preserve client IPs can put more traffic on some pods than others.

Key terms: Cluster, network hop, source IP, externalTrafficPolicy, Local, healthCheckNodePort, endpoints

11.3 Managing service endpoints

This section introduces the idea that service endpoints need not be pods.

• Non-pod service endpoints: Explain that although services are often backed by pods, they can forward traffic to any endpoint with an IP address.
  Why it matters: It broadens what you can consider a destination for service traffic.

Key terms: services, endpoints, IP address

11.3.1 Introducing the Endpoints object

This section explains where a Service’s endpoint addresses are stored, how to inspect them, and how Kubernetes keeps them up to date.

• Service and Endpoints separation: Explain why a Service’s endpoint addresses appear in kubectl describe even though the Service object does not list its pods.
  Why it matters: It tells you which object to inspect when you need to see a Service’s endpoints.
• Endpoint addresses and subsets: Describe what an Endpoints object contains and how its addresses and subsets appear when inspecting its full manifest.
  Why it matters: It helps you interpret what you see when inspecting an Endpoints manifest.
• Automatic endpoint membership updates: Explain who creates and updates an Endpoints object as pods matching a Service’s label selector appear or disappear.
  Why it matters: It explains why a Service’s endpoint list can change without you editing it.

Key terms: Service object, Endpoints object, kubectl describe, addresses array, endpoint subset, ports, label selector, endpoint

11.3.2 Introducing the EndpointSlice object

This section explains why Kubernetes uses EndpointSlice objects and how to find and inspect the slices associated with a Service.

• EndpointSlice performance rationale: Explain why a Service with many endpoints makes a single Endpoints object costly to update, and how splitting its endpoints across EndpointSlices addresses the problem.
  Why it matters: It explains why Kubernetes introduced EndpointSlices rather than relying on one growing Endpoints object.
• EndpointSlice grouping and limits: Describe how endpoints are divided among EndpointSlice objects, including port groupings and the stated endpoint and port limits.
  Why it matters: A single Service can have several slices because its endpoints use different ports or exceed a slice’s practical size.
• EndpointSlice discovery and inspection: Describe how Kubernetes creates EndpointSlices and how to list the slices for a particular Service and inspect their contents.
  Why it matters: These commands let you find the slices behind a Service and see which addresses and ports they contain.

Key terms: Endpoints object, EndpointSlice object, endpoints, endpoint subsets, EndpointSlice, ports, kubectl get endpointslices, kubernetes.io/service-name, kubectl describe, endpoint addresses

11.3.3 Managing service endpoints manually

This section explains how to configure a Service’s endpoints by hand and switch between manual and selector-managed endpoints without changing the Service’s address.

• Selectorless Service endpoints: Explain how to make a Service without a pod selector route traffic to manually specified endpoints, and why this is useful for an external service.
  Why it matters: It lets pods access an external destination through a Service name without selecting any pods.
• Stable address during migration: Describe how adding or removing a Service’s selector switches between Kubernetes-managed pod endpoints and manually managed endpoints while preserving the Service address.
  Why it matters: A Service can keep the same client-facing address while its destinations move into or out of the cluster.

Key terms: Service, label selector, Endpoints object, EndpointSlice, cluster IP, cluster DNS, selector, cluster IP address

11.4 Understanding DNS records for Service objects

Introduces the DNS records Kubernetes creates for Services and a temporary pod for inspecting them.

• Service DNS record types: Explain that cluster DNS provides an A record for a Service’s internal cluster IP address, or an AAAA record for IPv6, and an SRV record for each port the Service makes available.
  Why it matters: These records explain what a pod can look up about a Service through cluster DNS.
• Temporary DNS inspection pod: Describe how the section sets up a temporary pod for examining DNS records: it uses the giantswarm/tiny-tools image, attaches the terminal to its shell with -it, removes the pod on shell exit with --rm, and places it in the Kiada suite’s namespace when needed.
  Why it matters: The temporary pod provides the lookup tools in the intended namespace without leaving a pod behind.

Key terms: cluster DNS, A record, AAAA record, SRV record, internal cluster IP address, one-off pod, giantswarm/tiny-tools, host, nslookup, dig

11.4.1 Inspecting a service’s A and SRV records in DNS

Shows how to inspect a Service’s DNS A and SRV records to find its cluster IP and advertised ports.

• Service A record lookup: Explain how to look up a Service’s IP address from a pod and what address DNS returns for a LoadBalancer Service.
  Why it matters: A DNS lookup inside the cluster may give you a different address from the one external clients use.
• Service port SRV records: Describe what a Service’s SRV records tell a client and how named ports can be looked up.
  Why it matters: SRV records let clients discover a Service’s available ports through DNS.

Key terms: A record, nslookup, cluster IP, LoadBalancer, SRV record, named ports, Service object

11.4.2 Using headless services to connect to pods directly

This section explains how headless Services expose endpoint IP addresses through DNS so clients can connect directly to pods rather than through a Service cluster IP.

• Headless Service DNS records: Explain why a client might need a headless Service, how to create one, and how its DNS results differ from those of a regular Service.
  Why it matters: DNS gives clients a standard way to find individual pods without querying the Kubernetes API.
• Direct client connections: Describe how clients use a headless Service’s DNS results to reach pods directly, including what happens when a client simply connects using the Service’s FQDN.
  Why it matters: Direct pod addresses let a client choose its targets while still allowing ordinary FQDN-based connections.
• Selectorless headless endpoints: State what DNS returns when a headless Service has manually configured endpoints instead of a label selector.
  Why it matters: The DNS behavior also applies when Service endpoints are configured manually rather than selected from pods.

Key terms: headless service, clusterIP, None, A record, label selector, AAAA record, FQDN, pod IP, cluster IP, A/AAAA record

11.4.3 Creating a CNAME alias for an existing service

This section explains how an ExternalName Service creates a DNS alias for another service and how pods use that alias.

• ExternalName service configuration: Explain how to create a Service that aliases an existing internal or external service: set its type to ExternalName and its externalName field to the destination DNS name, without defining endpoints.
  Why it matters: This lets you give an existing service a Kubernetes Service name without defining its endpoints.
• ExternalName DNS connection behavior: Describe how pods use an ExternalName Service's DNS name and where their connections go after it resolves.
  Why it matters: The Service name gives pods a convenient alias, but it does not put a cluster IP in the connection path.

Key terms: CNAME record, ExternalName, Endpoints, EndpointSlice, cluster IP, time-api.<namespace>.svc.cluster.local

11.5 Configuring services to route traffic to nearby endpoints

This section explains two reasons a service might route traffic to nearby endpoints: reducing cross-zone or cross-region costs and reaching endpoints that work only in the caller’s node-local context.

• Nearby endpoint routing rationale: Explain why a service might forward traffic to pods near the pod sending the traffic when cluster nodes span availability zones or regions.
  Why it matters: Endpoint location can affect both the speed and cost of communication between pods.
• Node-local endpoint requirement: Distinguish the need to use an endpoint on the same node from choosing a nearby endpoint for performance or cost reasons.
  Why it matters: For some services, using a local endpoint is necessary for correct context rather than merely an optimization.

Key terms: availability zones, regions, services, pods, service endpoints, same node, node-local endpoints

11.5.1 Forwarding traffic only within the same node with internalTrafficPolicy

This section shows how a Service can restrict internal traffic to endpoints on the client pod’s node and how to observe that behavior.

• Node-local service routing: Explain why a node-tied service may need internalTrafficPolicy set to Local and what happens when a client pod has no service endpoint on its node.
  Why it matters: Some services are useful only when a client reaches a pod on its own node.
• Observing local endpoint selection: Describe how the quote-local example demonstrates node-local routing, including the result of removing the local quote pods.
  Why it matters: The example gives you a way to distinguish strict local routing from ordinary routing across nodes.

Key terms: internalTrafficPolicy, Local, node-local service endpoints, quote-local, -o wide, curl, kiada pods, quote pods

11.5.2 Topology-aware hints

This section explains how topology-aware hints steer Service traffic toward endpoints in suitable zones, how Kubernetes assigns those hints, and how nodes use them.

• Zone-local traffic motivation: Explain why a Service might favor endpoints in the caller’s zone, while recognizing that topology-aware hints do not guarantee every connection stays within that zone.
  Why it matters: This explains both the benefit of zone-aware routing and why it should not be treated as a strict locality guarantee.
• Hint prerequisites and assignment: Describe what enables topology-aware hints, where Kubernetes records them, and how the EndpointSlice controller assigns endpoints to zones.
  Why it matters: The hints must exist before nodes can use them to narrow their choice of endpoints.
• Node-side endpoint selection: Trace how a node chooses Service endpoints with and without topology-aware hints.
  Why it matters: This is how the recorded hints affect where traffic sent to a Service can go.

Key terms: topology-aware traffic routing, zone, kubernetes.io/zone, service.kubernetes.io/topology-aware-hints, Auto, EndpointSlice, forZones, EndpointSlice controller, cluster IP, topology-aware hints

11.6 Managing the inclusion of a pod in service endpoints

This section explains why a pod whose labels match a Service should not necessarily receive traffic as soon as it appears.

• Endpoint eligibility and application readiness: Explain why a newly appearing pod with labels matching a Service’s selector may need to wait before receiving connections.
  Why it matters: A pod can be selected by a Service before its application is ready to serve clients well.

Key terms: service, endpoint, label selector, ready

11.6.1 Introducing readiness probes

This section explains how readiness probes determine whether a pod receives service traffic, how applications can signal readiness, and how probe execution is configured.

• Readiness and service endpoints: Explain how a readiness probe affects a pod’s readiness and its inclusion in services, and distinguish a failed readiness probe from a failed liveness probe.
  Why it matters: Readiness keeps service traffic away from pods that cannot currently accept connections without restarting them.
• Application-specific readiness checks: Describe who decides what readiness means for an application and how the three readiness probe types determine whether a container is ready.
  Why it matters: A readiness check must reflect what being able to accept connections means for that particular application.
• Readiness probe timing settings: Describe the configurable execution settings shared with liveness probes and the readiness-specific success threshold, including when the initial delay begins if there is a startup probe.
  Why it matters: These settings affect when repeated checks can change a container’s readiness status.

Key terms: Kubelet, readiness probe, liveness probe, endpoint, label selector, exec probe, httpGet probe, tcpSocket probe, exit code, response code

11.6.2 Adding a readiness probe to a pod

This section uses a file-based readiness probe to show how a pod becomes ready or unready and how that changes its inclusion in a Service.

• File-based readiness probe behavior: Explain how the example probe uses the presence of /var/ready to determine readiness, and why the pod does not become ready immediately after the file is created.
  Why it matters: A successful check may not make a container ready until the probe’s success requirement is met.
• Pod readiness and service endpoints: Trace how the containers’ readiness affects whether the pod receives Service traffic, and describe how the example verifies the change.
  Why it matters: Readiness determines whether a matching pod is available to handle Service requests.
• Manual endpoint control alternatives: Distinguish the example’s file-based probe from the recommended ways to remove a pod from a Service manually.
  Why it matters: The demonstration should not be mistaken for a production pattern for controlling Service membership.
• Publishing unready service addresses: Explain the exception provided by publishNotReadyAddresses and its effect on endpoint readiness and DNS treatment.
  Why it matters: This setting is an explicit exception to the usual endpoint treatment of unready pods.

Key terms: readiness probe, ls /var/ready, success, ready, READY column, Endpoints, EndpointSlice, notReadyAddresses, ready condition, active endpoint

11.6.3 Implementing real-world readiness probes

This section explains how to make readiness probes reflect an application's ability to serve requests without letting transient dependency failures unnecessarily remove pods from service.

• Readiness probe baseline: Explain why a pod should have a readiness probe and how a minimal HTTP probe determines whether it is ready.
  Why it matters: A probe keeps a service from sending requests to an application that has not started accepting them.
• Application-specific readiness checks: Explain why a readiness probe should test the capability the pod actually provides, using the Quote pod as an example.
  Why it matters: A successful probe is useful only if it reflects what clients need the pod to do.
• Dedicated readiness endpoints: Describe how a dedicated readiness endpoint can check an application's internal requirements, using the Quiz pod as an example.
  Why it matters: A dedicated endpoint can represent whether the application can provide its service, not merely whether its HTTP server responds.
• External dependency probe risks: Justify caution when checking external services in a readiness probe and describe the section's rule of thumb.
  Why it matters: An overambitious check can turn a short network disturbance into a longer loss of service.
• Readiness during pod termination: Explain whether a readiness probe needs special shutdown behavior when a pod is deleted.
  Why it matters: Shutdown does not require adding a special termination check to the readiness probe.

Key terms: readiness probe, service endpoint, GET /, Quote pod, /quote, quote-writer, dedicated readiness endpoint, /healthz/ready, Quiz pod, MongoDB

11.7 Summary

The section recaps how Services provide stable access to pods, how clients find them and endpoints are chosen, and how traffic routing can account for locality and readiness.