Figure 12-2. Server-side service discovery At first glance,  Service Discovery  may seem like a simple pattern. However, multiple mechanisms can be used to implement this pattern, which depends on whether a ser‐ vice consumer is within or outside the cluster, and whether the service provider is within or outside the cluster. Let’s assume we have a web application and want to run it on Kubernetes. As soon as we create a Deployment with a few replicas, the scheduler places the Pods on the suit‐ able nodes, and each Pod gets a cluster IP address assigned before starting up. If another client service within a different Pod wishes to consume the web application endpoints, there isn’t an easy way to know the IP addresses of the service provider Pods in advance. This challenge is what the Kubernetes Service resource addresses. It provides a con‐ stant and stable entry point for a collection of Pods offering the same functionality. The easiest way to create a Service is through  kubectl expose , which creates a Ser‐ vice for a Pod or multiple Pods of a Deployment or ReplicaSet. The command creates a virtual IP address referred to as the  clusterIP , and it pulls both Pod selectors and port numbers from the resources to create the Service definition. However, to have full control over the definition, we create the Service manually, as shown in Example 12-1. Internal Service Discovery Example 12-1. A simple Service apiVersion : v1 kind : Service metadata : name : random-generator spec : selector : app : random-generator Solution  |  101