This message was deleted.
# k3s
a
This message was deleted.
p
wouldnt it be
server1.svc.namespace.domain-xx.local
?
or you mean internal as in internal network but not internal k8s
k3s*
f
Yes, I'm trying to reach our gitlab server, which is another vm (not running k3s). But in this example I'm trying to make a lookup on the k3s host (ip and name). But I can't lookup any other vm with the name.
when I try to lookup for our gitlab (code.domain-xx.local) not working. But the same lookup with the gitlabs IP is working fine and it shows me:
Copy code
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup 10.2.17.20
Server:    192.168.246.10
Address 1: 192.168.246.10 kube-dns.kube-system.svc.domain-xx.local

Name:      10.2.17.20
Address 1: 10.2.17.20 code.domain-xx.local
as far as I understood it the lookup should be forwarded to our internal dns server, which should provide the ip/name. (which it's doing outside of k3s). But why ip lookup is working and name lookup not? search domains are correct (in /etc/resolv.conf). Is there a way to check coredns' search domains? Maybe there is something wrong here, as IP lookup works fine. (which is also delivered by upstream dns)
c
are you using the same domain for your Kubernetes cluster as your actual domain?
f
yes, all in one domain
c
I wouldn’t do that. coredns assumes it is authoritative for the cluster domain. It isn’t going to forward lookups for the cluster domain out to your primary dns server.
tl;dr don’t set the cluster domain to the same thing as your real domain, it will mask the records in your real domain
that’s why it’s called the cluster domain. It’s just for use in the cluster.
f
ah wait, what exactly you mean with cluster domain? My 'real' domain is domain-xx.local. This is the domain where our gitlab, dns server and also the k3s host is. I did not specify any special domain in k3s installation.
Where I can check the 'cluster domain' ?
c
ok. it can be hard to tell when people redact things.
the default cluster domain is cluster.local
and you showed
kube-dns.kube-system.svc.domain-xx.local
which was indicating that you’d replaced the cluster domain with domain-xx.local because that is NOT the default cluster domain.
so is that what you actually were getting, or was that some over-exuberant redacting of your actual data?
f
I replaced our real domain with domain-xx.local .
c
That suggests that you’re using your real domain as the cluster domain then
f
ah, got it now. Sorry.
c
which you shouldn’t do
f
yes, i set up the cluster with --cluster-domain domain-xx.local
c
yep. don’t do that.
f
got it, will fix it and try again. Thank you very much!
c
so
did not specify any special domain in k3s installation.
was not accurate
f
any ressources for best practices where I can find such info?
c
you should uninstall and reinstall, the cluster domain can’t be changed after the cluster is brought up.
f
Yes, it was not. Sorry
No problem, will redo it. Sorry again.
c
np!
🙌 1
I don’t know that there’s any specific document in either our docs or the upstream Kubernetes docs that says not to set your cluster domain to the same thing as your real domain, I guess the expectation is that people would know not to have conflicting DNS zones.
f
Yeah, I thougth setting up the same cluster-domain would help. Did not thought about DNS Zones at the moment. Learned my lesson now. 🙂 Will change it to something different.
c
it looks like you’ve also customized the cluster and service CIDRs, those don’t overlap with your actual network ranges do they?
f
I have to do it. The default ranges overlapping some of our used network ranges.
c
ok. just make sure that the ranges you picked don’t overlap with any actual ranges, and that the cluster-cidr is large enough to hold as many nodes as you plan on adding.
👍 1