What happened:
I have a single headless service associated to a deployment. Each pod in the deployment has two containers. One container is responsible for serving incoming gRPC requests (some compute heavy task). The other container is responsible for communicating with a custom load balancer service we have. On startup, it first does a reverse DNS lookup to get the DNS name of the pod. This DNS name is given to the load balancer service so whichever client needs to connect to it, does so through the DNS name of the specific pod. This way, we can precisely control which clients go to which service pods.

What you expected to happen:
That I can do a reverse DNS lookup of a pod and get a DNS record. In other words, if a pod has IP address 1.2.3.4, I should be able to run the following command and see the following output:

getent hosts 1.2.3.4
1.2.3.4 1-2-3-4.my-service.my-namespace.svc.cluster.local

However, as a result of #6898, I no longer get the DNS record returned when running the command. If I set the hostname to some value 'foo', I will get a DNS record returned. However, the DNS record is now the same for all pods as it is based on that value 'foo'. This completely breaks my load balancing service as I can no longer route requests to a specific pod. What I need, is a way to get back to the behavior before PR #6898 was merged. I do not have multiple services, only one and I would like the PTR records created as they were before. It seems to me like the change should have been scoped to the special case when you have pods associated with multiple services.

How to reproduce it (as minimally and precisely as possible):
Create a headless service associated to a deployment. Run getent hosts on the IP address for one of the pods. Before PR #6898, you will get a DNS record returned. After, you will not.

Anything else we need to know?:

Environment:
The environment is not relevant as this issue is a direct result of the change in behavior as caused by PR #6898