Einführung
Das Domain Name System (DNS) ist ein System zum Verknüpfen verschiedener Arten von Informationen - wie z. B. IP-Adressen - mit leicht zu merkenden Namen. Standardmäßig konfigurieren die meisten Kubernetes-Cluster automatisch einen internen DNS-Dienst, um einen einfachen Mechanismus für die Diensterkennung bereitzustellen. Die integrierte Serviceerkennung erleichtert es Anwendungen, auf Kubernetes-Clustern nach Pods und Services zu suchen und mit diesen zu kommunizieren, selbst wenn diese erstellt, gelöscht und zwischen Knoten verschoben werden.
Die Implementierungsdetails des Kubernetes-DNS-Dienstes haben sich in den letzten Versionen von Kubernetes geändert. In diesem Artikel werden wir uns sowohl diekube-dns- als auch dieCoreDNS-Version des Kubernetes-DNS-Dienstes ansehen. Wir werden ihre Funktionsweise und die von Kubernetes generierten DNS-Einträge überprüfen.
Lesen SieAn Introduction to DNS Terminology, Components, and Concepts, um DNS besser zu verstehen, bevor Sie beginnen. Für alle Kubernetes-Themen, mit denen Sie möglicherweise nicht vertraut sind, können SieAn Introduction to Kubernetes lesen.
Was bietet der Kubernetes DNS-Dienst?
Vor Kubernetes Version 1.11 basierte der Kubernetes DNS-Dienst aufkube-dns. In Version 1.11 wurdenCoreDNS eingeführt, um einige Sicherheits- und Stabilitätsbedenken bei kube-dns auszuräumen.
Unabhängig von der Software, die die tatsächlichen DNS-Einträge verarbeitet, funktionieren beide Implementierungen auf ähnliche Weise:
-
Ein Dienst mit dem Namen
kube-dns
und ein oder mehrere Pods werden erstellt. -
Der Dienst
kube-dns
wartet auf Ereignisse vonservice undendpoint in der Kubernetes-API und aktualisiert seine DNS-Einträge nach Bedarf. Diese Ereignisse werden ausgelöst, wenn Sie Kubernetes-Dienste und die zugehörigen Pods erstellen, aktualisieren oder löschen. -
kubelet setzt die
/etc/resolv.conf
nameserver
-Option jedes neuen Pods auf die Cluster-IP deskube-dns
-Dienstes, wobei die entsprechendensearch
-Optionen die Verwendung kürzerer Hostnamen ermöglichen:resolv.conf
nameserver 10.32.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local options ndots:5
-
Anwendungen, die in Containern ausgeführt werden, können dann Hostnamen wie
example-service.namespace
in die richtigen Cluster-IP-Adressen auflösen.
Beispiel Kubernetes DNS Records
Der vollständige DNSA
-Datensatz eines Kubernetes-Dienstes sieht wie folgt aus:
service.namespace.svc.cluster.local
Ein Pod hätte einen Datensatz in diesem Format, der die tatsächliche IP-Adresse des Pods widerspiegelt:
10.32.0.125.namespace.pod.cluster.local
Außerdem werdenSRV
-Datensätze für die benannten Ports eines Kubernetes-Dienstes erstellt:
_port-name._protocol.service.namespace.svc.cluster.local
Das Ergebnis all dessen ist ein integrierter DNS-basierter Diensterkennungsmechanismus, bei dem Ihre Anwendung oder Ihr Mikrodienst auf einen einfachen und konsistenten Hostnamen abzielen kann, um auf andere Dienste oder Pods im Cluster zuzugreifen.
Domänen durchsuchen und kürzere Hostnamen auflösen
Aufgrund der Suchdomänensuffixe in der Dateiresolv.conf
müssen Sie häufig nicht den vollständigen Hostnamen verwenden, um einen anderen Dienst zu kontaktieren. Wenn Sie einen Dienst im selben Namespace ansprechen, können Sie ihn nur mit dem Dienstnamen kontaktieren:
other-service
Wenn sich der Dienst in einem anderen Namespace befindet, fügen Sie ihn der Abfrage hinzu:
other-service.other-namespace
Wenn Sie einen Pod als Ziel auswählen, müssen Sie mindestens Folgendes verwenden:
pod-ip.other-namespace.pod
Wie wir in der Standarddateiresolv.conf
gesehen haben, werden nur die Suffixe.svc
automatisch vervollständigt. Stellen Sie daher sicher, dass Sie alles bis zu.pod
angeben.
Nachdem wir uns mit der praktischen Verwendung des Kubernetes-DNS-Dienstes vertraut gemacht haben, wollen wir einige Details zu den beiden verschiedenen Implementierungen durchgehen.
Details zur DNS-Implementierung von Kubernetes
Wie im vorherigen Abschnitt erwähnt, wurde in Kubernetes Version 1.11 eine neue Software für den Dienstkube-dns
eingeführt. Die Motivation für die Änderung bestand darin, die Leistung und Sicherheit des Dienstes zu erhöhen. Schauen wir uns zuerst die ursprüngliche Implementierung vonkube-dns
an.
kube-dns
Der Dienstkube-dns
vor Kubernetes 1.11 besteht aus drei Containern, die in einemkube-dns
-Pod imkube-system
-Namespace ausgeführt werden. Die drei Container sind:
-
kube-dns: ist ein Container, in demSkyDNS ausgeführt wird und der die DNS-Abfrageauflösung ausführt
-
dnsmasq:ist ein beliebter, leichter DNS-Resolver und Cache, der die Antworten von SkyDNS zwischenspeichert
-
sidecar:ist ein Beiwagencontainer, der Metrikberichte verarbeitet und auf Integritätsprüfungen für den Dienst reagiert
Sicherheitslücken in Dnsmasq und Skalierungsprobleme bei SkyDNS führten zur Schaffung eines Ersatzsystems, CoreDNS.
CoreDNS
Ab Kubernetes 1.11, einem neuen Kubernetes-DNS-Dienst, wurdeCoreDNS zur allgemeinen Verfügbarkeit hochgestuft. Dies bedeutet, dass es produktionsbereit ist und der Standardcluster-DNS-Dienst für viele Installationstools und verwaltete Kubernetes-Anbieter sein wird.
CoreDNS ist ein einzelner in Go geschriebener Prozess, der alle Funktionen des vorherigen Systems abdeckt. Ein einzelner Container löst DNS-Abfragen auf und speichert sie im Cache, antwortet auf Integritätsprüfungen und stellt Metriken bereit.
CoreDNS behebt nicht nur Leistungs- und Sicherheitsprobleme, sondern behebt auch einige kleinere Fehler und fügt einige neue Funktionen hinzu:
-
Einige Probleme mit Inkompatibilitäten zwischen der Verwendung von stubDomains und externen Diensten wurden behoben
-
CoreDNS kann den DNS-basierten Round-Robin-Lastenausgleich verbessern, indem die Reihenfolge, in der bestimmte Datensätze zurückgegeben werden, zufällig festgelegt wird
-
Eine Funktion namens
autopath
kann die DNS-Antwortzeiten beim Auflösen externer Hostnamen verbessern, indem sie die inresolv.conf
aufgeführten Suffixe der Suchdomäne intelligenter durchläuft -
Mit kube-dns würde
10.32.0.125.namespace.pod.cluster.local
immer in10.32.0.125
aufgelöst, selbst wenn der Pod nicht vorhanden ist. CoreDNS verfügt über einen „Pods Verified“ -Modus, der nur erfolgreich aufgelöst wird, wenn ein Pod mit der richtigen IP-Adresse und im richtigen Namespace vorhanden ist.
Weitere Informationen zu CoreDNS und seinen Unterschieden zu kube-dns finden Sie unterthe Kubernetes CoreDNS GA announcement.
Zusätzliche Konfigurationsoptionen
Kubernetes-Betreiber möchten häufig anpassen, wie ihre Pods und Container bestimmte benutzerdefinierte Domänen auflösen, oder müssen die inresolv.conf
konfigurierten Upstream-Nameserver oder Suchdomänensuffixe anpassen. Sie können dies mit der OptiondnsConfig
der Spezifikation Ihres Pods tun:
example_pod.yaml
apiVersion: v1
kind: Pod
metadata:
namespace: example
name: custom-dns
spec:
containers:
- name: example
image: nginx
dnsPolicy: "None"
dnsConfig:
nameservers:
- 203.0.113.44
searches:
- custom.dns.local
Durch das Aktualisieren dieser Konfiguration werden dieresolv.conf
eines Pods neu geschrieben, um die Änderungen zu aktivieren. Die Konfiguration wird direkt den Standardoptionen vonresolv.conf
zugeordnet, sodass mit der obigen Konfiguration eine Datei mit den Zeilennameserver 203.0.113.44
undsearch custom.dns.local
erstellt wird.
Fazit
In diesem Artikel behandelten wir die Grundlagen dessen, was der Kubernetes-DNS-Dienst Entwicklern bietet, zeigten einige Beispiel-DNS-Einträge für Dienste und Pods, diskutierten, wie das System auf verschiedenen Kubernetes-Versionen implementiert ist, und hoben einige zusätzliche Konfigurationsoptionen hervor, mit denen Sie die Art und Weise Ihrer Pods anpassen können DNS-Abfragen lösen.
Weitere Informationen zum DNS-Dienst von Kubernetes finden Sie unterthe official Kubernetes DNS for Services and Pods documentation.