The  Service Discovery  pattern provides a stable endpoint at which clients of a service can access the instances providing the service. For this purpose, Kubernetes provides multiple mechanisms, depending on whether the service consumers and producers are located on or off the cluster. Applications deployed on Kubernetes rarely exist on their own, and usually, they have to interact with other services within the cluster or systems outside the cluster. The interaction can be initiated internally or through external stimulus. Internally initi‐ ated interactions are usually performed through a polling consumer: an application either after startup or later connects to another system and start sending and receiv‐ ing data. Typical examples are an application running within a Pod that reaches a file server and starts consuming files, or connects to a message broker and starts receiv‐ ing or sending messages, or connects to a relational database or a key-value store and starts reading or writing data. The critical distinction here is that the application running within the Pod decides at some point to open an outgoing connection to another Pod or external system, and starts exchanging data in either direction. In this scenario, we don’t have an external stimulus for the application, and we don’t need any additional setup in Kubernetes. To implement the patterns described in Chapter 7,  Batch Job  or Chapter 8,  Periodic Job , we often use this technique. In addition, long-running Pods in DaemonSets or ReplicaSets sometimes actively connect to other systems over the network. The more common use case for Kubernetes workloads occurs when we have long-running serv‐ ices expecting external stimulus, most commonly in the form of incoming HTTP connections from other Pods within the cluster or external systems. In these cases, 99 Problem CHAPTER 12 Service Discovery