I’ve recently replaced a bare-metal Microk8s cluster that was my Juju’s home lab k8s cloud target for quite some time, with its K8s 1.35-classic/stable-based equivalent, manually built from snap and Juju controller bootstrapped afterwards.
During this new K8s cluster build out, I configured a custom DNS domain, replacing “cluster.local” default with “k8s.maas.lan”, created as a non-authoritative subdomain to my MaaS-managed lab DNS domain “maas.lan”. With adequate MaaS subdomain forward_dns_servers and K8s upstream-nameservers settings configured, a full zone forward lookup integration was achieved, capable of resolving all K8s service-network forward and reverse lookups from my maas.lan domain clients, directly, without having to use “@forward_ns_ip” in dig queries - happy days.
However, as soon as I started deploying charms onto it, I begun facing various issues and ended up dealing with inexplicable postgresql-k8s ((16/stable) deployment failures.
Quick inspection of logs showed how Juju and postgress-k8s had no awareness of the custom K8s DNS config. Instead of being programmed to do a proper discovery, they seemed to be “hard-coded” to expect the default DNS settings are in place.
Failing to quickly sort it out through Cloud and/or Juju controller configuration changes, I decided to rebuild the cluster with default DNS settings retained, to get my RCA completed and confirmed asap.
As expected, this time a full-blown postgresql-k8 cluster was successfully deployed in minutes, while general slowness issues with all preceding bootstrapping/deployment steps observed before were completely eliminated.
This proves custom DNS <=> failures correlation, but I am still not sure and need your help in establishing:
-
is there still an option to make Juju & charms aware of DNS customisations that I missed to identify or not
-
if confirmed, how quickly could such a lack of capability be translated into a new feature request and fulfilled
Many thanks,
Zed