After almost three days of tests, I found a solution. The solution depends on two things: 1. how Kubernetes works; 2. how Patroni works.

How Kubernetes Works

When you create a StatefulSet deployment (but this is true also for Deployment), let's say with 3 pods, Kubernetes register in CoreDNS three DNS names:

IP-with-dashes.<namespace>.pod.cluster.local

however, these names are useless for me because I cannot set them in advance on my YAML files because it depends on the IP Kubernetes assigned to Pods.

However, for StatefulSet deployments, according to this documentation in the Stable Network ID section if I create a Headless service for my Pod I can access them using the short hostname (podname.servicename) of FQDN (<podname>.<servicename governor>.<namespace>.svc.cluster.local).

Here is the Headless service I needed to create:

---
apiVersion: v1
kind: Service
metadata:
  name: spilodemo-svc
  labels:
    application: spilo
    spilo-cluster: spilodemo
spec:
  clusterIP: None
  selector:
    application: spilo
    spilo-cluster: spilodemo

It's important here to set the selector to bind all three pods. Another important thing is to add the following line to your StatefulSet with a name equal to the headless service:

serviceName: spilodemo-svc

This is the Kubernetes part. Now you can reference your Pods with DNS names:

spilodemo-0.spilodemo-svc
spilodemo-1.spilodemo-svc
spilodemo-2.spilodemo-svc

or FQDN:

spilodemo-0.spilodemo-svc.<namespace>.svc.cluster.local
spilodemo-1.spilodemo-svc.<namespace>.svc.cluster.local
spilodemo-2.spilodemo-svc.<namespace>.svc.cluster.local

How Patroni Works

However, using Pods' DNS name is not meaningful for clients because they need a single point of access. For this reason, the Patroni team suggest to create a ClusterIP service like this:

---
apiVersion: v1
kind: Service
metadata:
  name: spilodemo
  labels:
    application: spilo
    spilo-cluster: spilodemo
spec:
  type: ClusterIP
  ports:
  - name: postgresql
    port: 5432
    targetPort: 5432

Note: there is no selector. This is not an error. When you create a Service like this Kubernetes creates a ClusterIP service (then it can be referenced using an IP or hostname) but without an Endpoint. This means that you connect to its IP or its DNS name: spilodemo.<namespace>.svc.cluster.local, the connection hangs.

For this reason, the Patroni team asks you to add in your YAML file the following Endpoint having the same name as the ClusterIP service.

apiVersion: v1
kind: Endpoints
metadata:
  name: spilodemo
  labels:
    application: spilo
    spilo-cluster: spilodemo
subsets: []

Patroni, internally, has a piece of code in Python that via Kubernetes API updates this endpoint with the Master Pod IP. Patroni is able to determine the Endpoint to update using its relative labels above (application, spilo-cluster) that you can even customize.

At this point, Patroni cluster clients only need to use this DNS name (the ClusterIP one) or the relative IP:

spilodemo.spilons.svc.cluster.local

the connection is automatically redirected to the Pod master node IP.

So far so good. Now the confusing part. If you look at the Patroni Kubernetes sample file in Spilo code, you node another headless service was already present.

---
# headless service to avoid deletion of patronidemo-config endpoint
apiVersion: v1
kind: Service
metadata:
  name: spilodemo-config
  labels:
    application: spilo
    spilo-cluster: spilodemo
spec:
  clusterIP: None

What confuse me was the presence of this headless service. I didn't understand its purpose. In the beginning, I thought it was the headless service required to have the Pods DNS name mentioned above. But I was wrong. The purpose of this service is different. Basically, the Zalando team doesn't know how the user writes the YAML file to deploy Patroni. If the user creates the Endpoint but forgot to associate to it a Service, Kubernetes see it as an orphan and delete it. For this reason, the Patroni code itself creates this service on its own. In fact, if you don't define it in the YAML file, Patroni will create it for you.

So, if Patroni creates it for you why do they add it in the sample YAML above? The reason is permissions. If Pod doesn't have permissions cannot create it. This is the reason they added it in the YAML. It's a bit confusing but this is the whole story.