Service Discovery from Outside the Cluster The service discovery mechanisms discussed so far in this chapter all use a virtual IP address that points to Pods or external endpoints, and the virtual IP address itself is accessible only from within the Kubernetes cluster. However, a Kubernetes cluster doesn’t run disconnected from the rest of the world, and in addition to connecting to external resources from Pods, very often the opposite is also required—external applications wanting to reach to endpoints provided by the Pods. Let’s see how to make Pods accessible for clients living outside the cluster. The first method to create a Service and expose it outside of the cluster is through type: NodePort . The definition in Example 12-6 creates a Service as earlier, serving Pods that match the selector  app: random-generator , accepting connections on port 80 on the virtual IP address, and routing each to port 8080 of the selected Pod. However, in addition to all of that, this definition also reserves port 30036 on all the nodes and forwards incoming connections to the Service. This reservation makes the Service accessible internally through the virtual IP address, as well as externally through a dedicated port on every node. Open port on all nodes. Specify a fixed port (which needs to be available) or leave this out to get a ran‐ domly selected port assigned. While this method of exposing services as illustrated in Figure 12-5 may seem like a good approach, it has drawbacks. Let’s see some of its distinguishing characteristics: Example 12-6. Service with type NodePort apiVersion : v1 kind : Service metadata : name : random-generator spec : type : NodePort selector : app : random-generator ports : -  port : 80 targetPort : 8080 nodePort : 30036 protocol : TCP Solution  |  107