You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
service_cidr and cluster_dns have default values (10.43.0.0/16 and 10.43.0.10 respectively).
If they are both absent from the configuration, the default values are used, and the resulting cluster will have a functioning kube-dns Service. Yay!
However, if I set service_cidr (for instance, to 10.10.0.0/16) without setting cluster_dns, then it looks like cluster_dns remains to its default value of 10.43.0.10, and since the default value is outside of the service CIDR, the creation of the kube-dns Service fails, and the resulting cluster has a broken DNS configuration (the pods are configured with 10.43.0.10 but there is no ClusterIP service at that address).
I'm going to submit a PR to add a warning in the sample configuration file, to remind users that if they change the service_cidr, they should also change the cluster_dns.
Do you think it would be necessary to add a check in the configuration validation as well?
Or, alternatively, if cluster_dns is not set, should it be automatically computed from service_cidr?
The text was updated successfully, but these errors were encountered:
jpetazzo
added a commit
to jpetazzo/hetzner-k3s
that referenced
this issue
Apr 28, 2024
As mentioned in vitobotta#351.
There is already a note about that in the README, but I thought it might
help to have it proeminently in the sample configuration as well.
A PR would be nice. I think it's better to keep settings explicit IMO. BTW I am in the middle of a massive refactoring, and a lot of code has changed already for v2.0 which I am going to release soon. So you may want to wait for the PR. Otherwise you will need to adapt it to the new code later.
service_cidr
andcluster_dns
have default values (10.43.0.0/16
and10.43.0.10
respectively).If they are both absent from the configuration, the default values are used, and the resulting cluster will have a functioning
kube-dns
Service. Yay!However, if I set
service_cidr
(for instance, to10.10.0.0/16
) without settingcluster_dns
, then it looks likecluster_dns
remains to its default value of10.43.0.10
, and since the default value is outside of the service CIDR, the creation of thekube-dns
Service fails, and the resulting cluster has a broken DNS configuration (the pods are configured with 10.43.0.10 but there is no ClusterIP service at that address).I'm going to submit a PR to add a warning in the sample configuration file, to remind users that if they change the
service_cidr
, they should also change thecluster_dns
.Do you think it would be necessary to add a check in the configuration validation as well?
Or, alternatively, if
cluster_dns
is not set, should it be automatically computed fromservice_cidr
?The text was updated successfully, but these errors were encountered: