mechanism that can be used from applications written in any language, and is also easy to emulate outside the Kubernetes cluster for development and testing purposes. The main issue with this mechanism is the temporal dependency on Service creation. Since environment variables cannot be injected into already running Pods, the Service coordinates are available only for Pods started after the Service is created in Kubernetes. That requires the Service to be defined before starting the Pods that depend on the Service—or if this is not the case, the Pods needs to be restarted. Kubernetes runs a DNS server that all the Pods are automatically configured to use. Moreover, when a new Service is created, it automatically gets a new DNS entry that all Pods can start using. Assuming a client knows the name of the Ser‐ vice it wants to access, it can reach the Service by a fully qualified domain name (FQDN) such as  random-generator.default.svc.cluster.local . Here, random-generator  is the name of the Service,  default  is the name of the name‐ space,  svc  indicates it is a Service resource, and  cluster.local  is the cluster- specific suffix. We can omit the cluster suffix if desired, and the namespace as well when accessing the Service from the same namespace. The DNS discovery mechanism doesn’t suffer from the drawbacks of the environment-variable-based mechanism, as the DNS server allows lookup of all Services to all Pods as soon as a Service is defined. However, you may still need to use the environment variables to look up the port number to use if it is a non‐ standard one or unknown by the service consumer. Here are some other high-level characteristics of the Service with  type: ClusterIP that other types build upon: Discovery through DNS lookup Multiple ports Session affinity A single Service definition can support multiple source and target ports. For example, if your Pod supports both HTTP on port 8080 and HTTPS on port 8443, there is no need to define two Services. A single Service can expose both ports on 80 and 443, for example. When there is a new request, the Service picks a Pod randomly to connect to by default. That can be changed with  sessionAffinity: ClientIP , which makes all requests originating from the same client IP stick to the same Pod. Remember that Kubernetes Services performs L4 transport layer load balancing, and it can‐ Solution  |  103 Example 12-2. Service-related environment variables set automatically in Pod RANDOM_GENERATOR_SERVICE_HOST=10.109.72.32 RANDOM_GENERATOR_SERVICE_PORT=8080