-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generated node local coredns config has extra newline and is invalid #5156
Comments
Is this on a dual-stack cluster? Are you overriding the ClusterDNS address? Just from glancing at the template you linked, this would only appear to be a problem when |
Apologies, my mistake leaving that out. Yes, this is a dual-stack cluster and |
Ok. And you manually set it to both addresses? It works fine if you leave it as the default single-stack value? |
No I haven't manually set the value, I can see it in the |
It is passed through from the |
Just the latter, |
cc @manuelbuil would you mind taking a look at this? |
Thanks for reporting it! I was able to reproduce the issue and found out that there was a bug in the helm templating helper code. Here is the fix: rancher/rke2-charts#387 |
##Environment Details Infrastructure
Node(s) CPU architecture, OS, and version:
Cluster Configuration:
Config.yaml:
Reproduction
Results: $ kgp -n kube-system
install using VERSION=v1.29.1-rc2+rke2r1
|
Environmental Info:
RKE2 Version:
Node(s) CPU architecture, OS, and Version:
Cluster Configuration:
Describe the bug:
When enabling node local DNS and invalid configuration is generated with an additional newline after the
forward
option which is rejected as an invalid config by coredns.Issue appears to be here as the addition of a
-
to strip in the newline fixes the problem, might be something do with how thesplit
function returns as it does not occur with the static definition of10.43.0.10
nor the previous behaviour in 4811c82Steps To Reproduce:
Expected behavior:
It works
Actual behavior:
An invalid config is generated and coredns is stuck in
CrashLoopBackoff
until theConfigMap
is manuallly fixedAdditional context / logs:
The text was updated successfully, but these errors were encountered: