Eine Einführung in den Kubernetes DNS Service

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 Namenkube-dns und ein oder mehrere Pods werden erstellt.

  • Der Dienstkube-dnswartet 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.confnameserver-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 wieexample-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.confmü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.svcautomatisch 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-dnseingefü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-dnsan.

kube-dns

Der Dienstkube-dnsvor 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 namensautopath 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ürde10.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 OptiondnsConfigder 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.confeines Pods neu geschrieben, um die Änderungen zu aktivieren. Die Konfiguration wird direkt den Standardoptionen vonresolv.confzugeordnet, sodass mit der obigen Konfiguration eine Datei mit den Zeilennameserver 203.0.113.44 undsearch custom.dns.localerstellt 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.