service consumers need a mechanism for discovering Pods that are dynamically placed by the scheduler and sometimes elastically scaled up and down. It would be a significant challenge if we had to perform tracking, registering and dis‐ covering endpoints of dynamic Kubernetes Pods ourselves. That is why Kubernetes implements the  Service Discovery  pattern through different mechanisms, which we explore in this chapter. If we look at the “Before Kubernetes Era,” the most common mechanism of service discovery was through client-side discovery. In this architecture, when a service con‐ sumer had to call another service that might be scaled to multiple instances, the ser‐ vice consumer would have a discovery agent capable of looking at a registry for service instances and then choosing one to call. Classically, that would be done, for example, either with an embedded agent within the consumer service (such as a Zoo‐ Keeper client, Consul client, or Ribbon), or with another colocated process such as Prana looked up the service in a registry, as shown in Figure 12-1. In the “Post Kubernetes Era,” many of the nonfunctional responsibilities of dis‐ tributed systems such as placement, health check, healing, and resource isolation are moving into the platform, and so is  Service Discovery  and load balancing. If we use the definitions from service-oriented architecture (SOA), a service provider instance still has to register itself with a service registry while providing the service capabili‐ ties, and a service consumer has to access the information in the registry to reach the service. In the Kubernetes world, all that happens behind the scenes so that a service con‐ sumer calls a fixed virtual Service endpoint that can dynamically discover service instances implemented as Pods. Figure 12-2 shows how registration and lookup are embraced by Kubernetes. 100  |  Chapter 12: Service Discovery Figure 12-1. Client-side service discovery Solution