CoreDNS meldet i/o timeout - Lösung 42

Seit Kurzem nutzt die Infrastruktur des Raspberry Pi Kubernetes Clusters den Travel Router SFT1200 von GL.iNET. Dieser kann Internetzugriff via LAN, WLAN, Tethering und USB Modem für andere Geräte via LAN und WLAN bereitstellen. Um den Ersatz der SD-Karten der bisherigen Geräte zu vereinfachen, habe ich im Router statische DHCP-Einträge für die MAC-Adressen hinterlegt. Dabei dachte ich, es gut wäre, wenn ich statt des Standardnetzes (Class C), mal etwas anderes nutze, damit ich die Netze intern gut unterscheiden kann. Ich habe mich für Class A (konkret 10.42.42.0/24) entschieden und die Konfiguration der Nodes entsprechend geändert.

Allerdings traten im Anschluss seltsame Fehler auf. Beispielsweise konnte der Cloudflare Tunnel (siehe Lokales Kubernetes im Internet verfügbar) keine Verbindung zum Internet mehr herstellen. Die Fehlermeldung half mir nicht direkt weiter und auch im Netz gab es im Kontext von cloudflared (die für den Tunnel genutzte Software) keine Lösung.

Allerdings zeigte auch CoreDNS Probleme an, weshalb ich dort in die Logs schaute und folgendes fand:

read udp 10.42.12.34:49738->10.42.42.1:53: i/o timeout

Es dauerte einen Moment, bis ich in der Dokumentation von K3s fündig wurde. Die Leute bei Rancher scheinen auch Fans der 42 zu sein. Standardmäßig wird 10.42.0.0/16 für die IPs der Pods genutzt. Dadurch wurden die DNS-Anfragen an 10.42.42.1 nicht aus dem Kubernetes Cluster herausgegeben und intern konnten sie nicht beantwortet werden.

Ein ärgerlicher Fehler, der sich aber ja schnell beheben ließ. Die Nodes verwenden jetzt 10.0.0.0/24 und die 42 bleibt K3s vorbehalten. 😉