use upstream coredns chart instead of fork #1743
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CoreDNS is a core component of the K8GB application. Until now we were installing it using a fork of the official helm chart with the following diff. The fork was necessary because Kubernetes did not support services of type load balancer with both udp and tcp ports, and to reduce the attack surface by running K8GB on a non-privileged port.
Since version 1.26 Kubernetes supports load balancers with mixed ports.
The coredns helm chart also evolved over the years, and with this contribution we are able to not open privileged ports on coredns.
Generated configuration
The generated configuration by the base chart has only the following differences:
NET_BIND_SERVICE
capability)User configuration
The helm configuration changes slightly, so users should be aware of the following:
dnsZoneNegTTL
is now configured directly on the coredns chart, on thek8s_crd
block undercoredns.servers.plugins
coredns.extraServerBlocks
andcoredns.extraPlugins
no longer exist and must be configured using coredns native configurationcoredns.servers
block must be configured by copying the base chart's values and adapting thezone
key. This is unfortunately a usability drawback since the previous setup configured it on the k8gb chart by only using a couple ofvalues
. However, this is necessary to benefit from all the coredns's port logic that enables TCP and prometheus ports.Conclusion
With this change we are now able to use the upstream chart instead of a fork. Unfortunately there is a overhead on the configuration necessary to the user, but we gain a lot. We can profit from all the features the coredns community offers, expose TCP port 53 publicly (fixes #1741) and expose the metrics port on the container which allows Prometheus metrics scraping.
Others
The upgrade from ubuntu 22.04 to 24.04 seems to have affected the python environment. We now need to create a virtual environment to enable installation of libraries via pip3.
By enabling k3d's loadbalancer we can rely on routing via Kubernetes services. This means we can use services of type LoadBalancer or ClusterIP. We no longer need to rely on the service type NodePort, or on making sure a pod is running on the node exposing the port. With this improvement we can now query the coredns servers using udp or tcp:
In a follow up PR I will try to extend this setup to expose istio and the nginx ingress controller.