headless Service  (by setting both  type: ClusterIP  and  clusterIP: None ). It is called headless  because such a Service doesn’t have a virtual IP address, kube-proxy doesn’t handle these Services, and the platform performs no proxying. However, such a Service is still useful because a headless Service with selectors creates endpoint records in the API Server and generates DNS A records for the matching Pod(s). With that, a DNS lookup for the Service does not return its virtual IP, but instead the IP address(es) of the backing Pod(s). That enables direct access to the sin‐ gleton Pod via the Service DNS record, and without going through the Service virtual IP. For example, if we create a headless Service with the name  my-singleton , we can use it as  my-singleton.default.svc.cluster.local  to access the Pod’s IP address directly. To sum up, for nonstrict singletons, a ReplicaSet with one replica and a regular Ser‐ vice would suffice. For a strict singleton and better performant service discovery, a StatefulSet and a headless Service would be preferred. You can find a complete exam‐ ple of this in Chapter 11,  Stateful Service  where you have to change the number of replicas to one to make it a singleton. In a distributed environment, one way to control the service instance count is through a distributed lock as shown in Figure 10-2. Whenever a service instance or a component inside the instance is activated, it can try to acquire a lock, and if it suc‐ ceeds, the service becomes active. Any subsequent service instance that fails to acquire the lock waits and continuously tries to get the lock in case the currently active service releases it. Many existing distributed frameworks use this mechanism for achieving high availa‐ bility and resiliency. For example, the message broker Apache ActiveMQ can run in a highly available  active-passive  topology where the data source provides the shared lock. The first broker instance that starts up acquires the lock and becomes active, and any other subsequently started instances become passive and wait for the lock to be released. This strategy ensures there is a single active broker instance that is also resilient to failures. In-Application Locking 82  |  Chapter 10: Singleton Service