Pod names are used instead of service names

[Gerrit-K]

tl;dr
Since version 1.8.2 kubefwd uses the pod names instead of the service names as hostnames

---

I used to use kubefwd 1.8.0 a lot for local development and embedded the service names in configs, e.g. the redis service oy my app acme for the feature featxy was forwarded according to the service name featxy-acme-redis. Since upgrading to 1.8.4 (actually since 1.8.2 and later) /etc/hosts is populated with the pod names instead (e.g. featxy-acme-redis-57cbcdbd98) which forces me to change all the configs if the pod gets a new identifier. Is this a bug or a feature?

[cjimti]

If I remember correcly it was the result of a PR to fix headless services. I will look into this.

[Gerrit-K]

Thanks for the quick resolution!

[Gerrit-K]

@cjimti Sorry for digging this up again, but this issue seems to have reappeared. I'm using 1.9.7 and kubefwd only forwards the pod names (including the suffix) as host names again.

Edit: just tested with 1.9.6 and it works. I guess that's due to #93 ?

[cjimti]

@Gerrit-K thanks for bringing this up. @calmkart, any chance you can help with this regression in #93 ? Thanks

I am at KubeCon this week so limited in my availability and then on vacation next week.

[calmkart]

@Gerrit-K @cjimti
From my logic, the headless service should not be represented only by the first pod. So the service name accessing the headless service should not be forwarded to his first pod.
The current logic is:

1. The normal service forwards its first pod to the service name (nginx), and we can access the first pod (nginx-deployment-5cdfb5fc49-b44j2) by accessing the service name(nginx)

2. Headless service forwards all pods (similar to this: nginx-deployment-5cdfb5fc49-b44j2.nginx1; nginx-deployment-5cdfb5fc49-dfhvs.nginx1) but does not forward the service name (nginx1), we access the headless service name (nginx1) Unable to access any pods.

Is it correct and necessary to automatically forward its first pod as a service name for a headless service? (Accessing nginx1 means accessing nginx-deployment-5cdfb5fc49-b44j2.nginx1)

I will make changes if necessary. Looking forward to the reply.

[cjimti]

@calmkart yes to support 12-factor style development. When developing software locally the application may wish to point to a headless service (such as cassandra-client:9180,) since /etc/hosts is not DNS we need to point any headless service to the first Pod it finds.

However, we also need to continue forwarding the individual Pods backing a headless service to be as flexible as possible.

[calmkart]

@cjimti
fixed in commit
for pr #95

[cjimti]

@Gerrit-K I have reverted back to 1.9.6 and released it again as 1.10.0. This solved the problem for me as well as keeping @calmkart's performance updates.

[Gerrit-K]

Sorry for the late response and thanks to both of you for revisiting and fixing this!