Chapter 5. Services: enabling clients to discover and talk to pods

You’ve learned about pods and how to deploy them through ReplicaSets and similar resources to ensure they keep running. Although certain pods can do their work independently of an external stimulus, many applications these days are meant to respond to external requests. For example, in the case of microservices, pods will usually respond to HTTP requests coming either from other pods inside the cluster or from clients outside the cluster.

Pods need a way of finding other pods if they want to consume the services they provide. Unlike in the non-Kubernetes world, where a sysadmin would configure each client app by specifying the exact IP address or hostname of the server providing the service in the client’s configuration files, doing the same in Kubernetes wouldn’t work, because

5.1. Introducing services

5.1.1. Creating services

5.1.2. Discovering services

5.2. Connecting to services living outside the cluster

5.2.1. Introducing service endpoints

5.2.2. Manually configuring service endpoints

5.2.3. Creating an alias for an external service

5.3. Exposing services to external clients

5.3.1. Using a NodePort service

5.3.2. Exposing a service through an external load balancer

5.3.3. Understanding the peculiarities of external connections

5.4. Exposing services externally through an Ingress resource

5.4.1. Creating an Ingress resource

5.4.2. Accessing the service through the Ingress

5.4.3. Exposing multiple services through the same Ingress

5.4.4. Configuring Ingress to handle TLS traffic

5.5. Signaling when a pod is ready to accept connections

5.5.1. Introducing readiness probes

5.5.2. Adding a readiness probe to a pod

5.5.3. Understanding what real-world readiness probes should do

5.6. Using a headless service for discovering individual pods

5.6.1. Creating a headless service

5.6.2. Discovering pods through DNS

5.6.3. Discovering all pods—even those that aren’t ready

5.7. Troubleshooting services