Open GrahamDumpleton opened 4 months ago
Using Apple Silicon version of educates
when creating cluster makes no difference.
In /etc/resolv.conf
in workshop session container is:
$ cat /etc/resolv.conf
search lab-k8s-fundamentals-w01.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5
The codedns
config is:
│ Corefile: | │
│ .:53 { │
│ errors │
│ health { │
│ lameduck 5s │
│ } │
│ ready │
│ kubernetes cluster.local in-addr.arpa ip6.arpa { │
│ pods insecure │
│ fallthrough in-addr.arpa ip6.arpa │
│ ttl 30 │
│ } │
│ prometheus :9153 │
│ forward . /etc/resolv.conf { │
│ max_concurrent 1000 │
│ } │
│ cache 30 │
│ loop │
│ reload │
│ loadbalance │
│ }
The /etc/resolv.conf
in the Kind cluster docker container is:
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 192.168.65.254
options ndots:0
# Based on host file: '/etc/resolv.conf' (internal resolver)
# ExtServers: [192.168.65.7]
# Overrides: []
# Option ndots from: internal
and the host cannot be resolved from Kind cluster docker container either.
# curl -v lab-k8s-fundamentals-ui.educates-local-dev.test
* Could not resolve host: lab-k8s-fundamentals-ui.educates-local-dev.test
* Closing connection 0
curl: (6) Could not resolve host: lab-k8s-fundamentals-ui.educates-local-dev.test
From Intel box the /etc/resolv.conf
files are the same, but on Intel box the hostname can be resolved from Kind cluster docker container.
This may boil down to the prior known issue seen where golang binaries when compiled as cross architecture builds for macOS rather than native build don't do networking properly such that /etc/resolver
is used.
Trying to implement DNS on home router doesn't work either. Seems like Kind cluster may be going direct to 8.8.8.8 or other public DNS and ignoring home network router DNS.
Way around this may be to edit coredns config and add a line like:
forward educates-local-dev.test 192.168.0.1
where the IP address is that of the host where DNS server is running, or perhaps could point at the local DNS resolver (dnsmasq).
Describe the bug
Did see this a long time back and ignored it since I usually worked on Intel macOS and was too busy to look at it at the time.
On Apple Silicon macOS, if use local DNS resolver, it is not used inside of the cluster when looking up hostnames. This causes workshop session authentication to fail.
Have never had an issue with this on Intel macOS.
Additional information
Using Intel version of
educates
CLI on Apple Silicon. Don't know if this is part of the issue and need to check with Apple Silicon version ofeducates
CLI when creating cluster.