> Everything running inside of a kubernetes cluster should just be querying the kubernetes endpoints api for these IPs directly
Wouldn't this put a huge load on the apiserver? Not to mention it's incompatible with software not designed for Kubernetes.
The options for that are:
* dnsPolicy: Default
* enableServiceLinks: true (the default)
Then you can use MYDATABASENAME_SERVICE_HOST from the environment and there is no CoreDNS in the path at all.
If I restart my DB, will the database service host env var also be updated? Will restarting a DB or changing the IP of a DB will also imply a restart of all of the services that need access to the DB?
The service's ClusterIP will not change.
Unless you want to also get rid of kube-proxy, in addition to CoreDNS; in that case you don't get ClusterIPs for services.
To be honest kube-proxy and CoreDNS are probably the only components I haven't had problems with on my cluster.
Re:It's not always DNS – unless it is
by paulddraper on Friday December 22, 2023 @03:40PM
(#38738418)
> querying the kubernetes endpoints api for these IPs directly
Isn't DNS built explicitly for this?
This might fix problems accidentally, at the cost of k8 dependency.
I hate coredns. Everything running inside of a kubernetes cluster should just be querying the kubernetes endpoints api for these IPs directly and using the node dnsservers for external hosts.