We are switching to using Kubernetes. It is simple to access other deployed services within a k8s deployment via the built in dns. So if I have pod/service named app1 and a pod/service named app2 and app1 needs to call app2, it can just use "app2" and k8s dns works its magic and everything works. It is nice because we don't need the config mgmt overhead of having a app1_host and app2_host for all environments.
This also works locally using minikube. If app1 and app2 are deployed into minikube, they can reference each other via the service name (which matches the app names)
However, where I am running into issues is local development. Let's say I want to work on app1 in my local IDE. I can spin up app2 in minikube, but now if I want app1 to access app2 in minikube...i can no longer use just "app2". I have to ping minikube/kubectl api and get the running IP and Port and then I can use that locally... which makes we go back to using HOST/PORT type config mgmt.
We could update /etc/hosts file and point app2 to the minikube IP, but I would still need to find out what the external/exposed port is.
We could use config mgmt host/port and on start up dynamically populate them from minikube/k8s api. Is that the recommended way? Is there something that already does that (akin to envconsul)?
Is there a better/more elegant solution that I can harness the power of k8s dns when trying to work locally in an IDE but have dependent services running in minikube or k8s?
Thanks
Always re-build and re-deploy your app on every code change:
Will only switch out files that have been modified and allow you to use hot reloading, e.g. with nodemon for nodejs:
https://www.datawire.io/products/telepresence/
From their website:
Transparently access other microservices in a remote Kubernetes
cluster, as well as cloud resources such as AWS RDS. Your code has
access to the same environment variables and volumes as a regular
Kubernetes pod.