CoreDNS lernen

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

In diesem Buch geht es um CoreDNS, einen neuen DNS-Server, der so konzipiert wurde, dass er gut mit Containern wie Linux- und Docker-Containern zusammenarbeitet und besonders gut in Umgebungen funktioniert, die von Kubernetes, dem beliebten Container-Orchestrierungssystem, verwaltet werden.

In diesem ersten Kapitel wird erklärt, was CoreDNS ist und wie er sich von anderen DNS-Servern unterscheidet, einschließlich seiner Einschränkungen. Das Kapitel geht auch auf die Geschichte von CoreDNS ein, z. B. auf seine Beziehung zur Cloud Native Computing Foundation.

Was ist CoreDNS?

CoreDNS ist eine DNS-Server-Software, die häufig zur Unterstützung der Service-Discovery-Funktion in containerisierten Umgebungen verwendet wird, insbesondere in solchen, die von Kubernetes verwaltet werden. Miek Gieben schrieb die ursprüngliche Version von CoreDNS im Jahr 2016. Zuvor hatte er einen DNS-Server namens SkyDNS und eine beliebte Bibliothek mit DNS-Funktionen in der Sprache Go namens Go DNS geschrieben. Wie sein Nachfolger CoreDNS diente auch SkyDNS in erster Linie dazu, Dienste zu finden. Aber Miek bewunderte die Architektur eines Go-basierten Webservers namens Caddy, so dass er Caddy abspaltete, um CoreDNS zu entwickeln. CoreDNS hat somit die wichtigsten Vorteile von Caddy geerbt: seine einfache Konfigurationssyntax, seine leistungsstarke Plug-in-basierte Architektur und seine Grundlage in Go.

Verglichen mit der Syntax der BIND-Konfigurationsdatei ist das Corefile von CoreDNS, wie es genannt wird, erfrischend einfach. Die Corefile für einen einfachen CoreDNS-basierten DNS-Server ist oft nur ein paar Zeilen lang und - relativ gesehen - leicht zu lesen.

CoreDNS verwendet Plug-ins, um DNS-Funktionen bereitzustellen. So gibt es ein Plug-in für das Caching und ein Plug-in für die Weiterleitung, ein Plug-in für die Konfiguration eines primären DNS-Servers, der Zonendaten aus einer Datei liest, und ein Plug-in für die Konfiguration eines sekundären DNS-Servers. Die Konfiguration der einzelnen Plug-ins ist nicht nur einfach (siehe vorheriger Absatz), sondern wenn du ein Plug-in nicht brauchst, konfigurierst du es nicht und sein Code wird nicht ausgeführt. Das macht CoreDNS schneller und sicherer.

Plug-ins sind auch ziemlich einfach zu entwickeln. Das ist aus zwei Gründen wichtig. Erstens: Wenn du die Funktionen von CoreDNS erweitern möchtest, kannst du dein eigenes Plug-in schreiben; wir behandeln das in Kapitel 9. Zweitens ist es nicht schwer, neue Plug-ins zu schreiben. Es wurden bereits viele Plug-ins entwickelt, und es werden ständig neue entwickelt. Vielleicht findest du eines, das die Funktionen bietet, die du brauchst.

Die Sprache Go ist "speichersicher", d.h. sie ist vor "Speicherzugriffsfehlern" wie Pufferüberläufen und "baumelnden Zeigern" geschützt. Das ist besonders wichtig für einen DNS-Server wie CoreDNS, auf den jeder im Internet zugreifen könnte. Ein böswilliger Akteur könnte einen Pufferüberlauf ausnutzen, um einen DNS-Server zum Absturz zu bringen oder sogar die Kontrolle über das zugrundeliegende Betriebssystem (OS) zu erlangen. Tatsächlich wurden im Laufe der Jahrzehnte eine beträchtliche Anzahl der schwerwiegenden Sicherheitslücken in BIND durch Speicherzugriffsfehler verursacht. Mit CoreDNS musst du dir darüber keine Sorgen machen.

Der wahrscheinlich wichtigste Vorteil von CoreDNS ist jedoch seine Fähigkeit, mit Container-Infrastrukturen und Orchestrierungssystemen wie etcd und Kubernetes zu kommunizieren. Darauf gehen wir später im Buch noch genauer ein, aber hier werfen wir schon mal einen kurzen Blick auf diese Funktion.

CoreDNS, Container und Microservices

Wenn du zu der kleinen Gruppe von Menschen gehörst, die dieses Buch anspricht, hast du wahrscheinlich schon von Containern gehört. Falls nicht, kannst du dir einen Container als eine sehr schlanke, effiziente virtuelle Maschine (VM) vorstellen. Während sich VMs dank eines Hypervisors eine einzige Hardwareplattform teilen können, bieten Container Ausführungsumgebungen, die unter demselben Betriebssystemkern laufen, aber ein ähnliches Maß an Isolierung wie VMs bieten. Container sind viel kleiner als VMs und können viel schneller gestartet und gestoppt werden.

Container werden häufig in Software eingesetzt, die auf einer Microservices-Architektur basiert. Bei Microservices wird eine - oft komplexe - Anwendung in viele Microservices unterteilt. Jeder Microservice ist für die Bereitstellung eines kleinen, aber nützlichen und klar definierten Funktionsumfangs verantwortlich. Ein Microservice kann z. B. die Authentifizierung von Benutzern übernehmen, während ein anderer die Autorisierung dieser Benutzer verwaltet. Insgesamt kann eine Anwendung aus Dutzenden oder Hunderten von Microservices bestehen, die über ein Netzwerk miteinander kommunizieren.

In der Praxis kann jeder Microservice von einem oder mehreren Containern bereitgestellt werden. Der Authentifizierungsdienst könnte zum Beispiel als Container implementiert sein. Das Starten und Stoppen von Containern ist so schnell und einfach, dass die Anwendung - oder ein übergeordneter Container-Orchestrator -zusätzliche Authentifizierungscontainer dynamisch starten und stoppen kann, wenn die Nachfrage nach Authentifizierung steigt oder sinkt.

In einer solchen Umgebung kann es jedoch eine Herausforderung sein, herauszufinden, wo ein bestimmter Dienst ausgeführt wird. Angenommen, ein Container, der den Datenbankdienst unterstützt, muss mit dem Autorisierungsdienst kommunizieren, um festzustellen, ob ein bestimmter Nutzer eine bestimmte Suche durchführen darf. Wenn die Container, die den Autorisierungsdienst implementieren, dynamisch gestartet und gestoppt werden, um die Last auszugleichen, wie bekommen wir dann eine Liste aller laufenden Autorisierungscontainer?

Die Antwort ist meistens DNS, das Domain Name System. Da die Kommunikation zwischen Containern fast immer auf IP, dem Internetprotokoll, basiert und Entwickler/innen schon seit Jahrzehnten DNS nutzen, um die IP-Adressen von Ressourcen zu finden, ist es ganz natürlich, DNS zu nutzen, um Container zu identifizieren, die einen bestimmten Dienst anbieten.

In dieser Eigenschaft glänzt CoreDNS wirklich. CoreDNS ist nicht nur ein flexibler, sicherer DNS-Server, sondern lässt sich auch direkt in viele Container-Orchestrierungssysteme integrieren, darunter Kubernetes. Das bedeutet, dass es für die Administratoren von containerisierten Anwendungen einfach ist, einen DNS-Server einzurichten, der die Kommunikation zwischen Containern vermittelt und erleichtert.

CoreDNS-Einschränkungen

CoreDNS hat derzeit allerdings einige erhebliche Einschränkungen und ist nicht für jeden denkbaren DNS-Server geeignet. Dazu gehört vor allem, dass CoreDNS, zumindest in der aktuellen Version, keine vollständige Rekursion unterstützt. Mit anderen Worten: CoreDNS kann eine Anfrage nicht bearbeiten, indem es bei der Wurzel eines DNS-Namensraums beginnt, einen Root-DNS-Server abfragt und Verweisen folgt, bis es eine Antwort von einem der autoritativen DNS-Server erhält. Stattdessen verlässt er sich dabei auf andere DNS-Server, die sogenannten Forwarder. In Kapitel 2 werden wir mehr über Rekursion und Forwarder erfahren.

Wenn du noch unschlüssig bist, ob CoreDNS die richtige Wahl für deine Bedürfnisse ist, hilft dir vielleicht Tabelle 1-1, die die wichtigsten Unterschiede zwischen den Funktionen von CoreDNS und BIND zusammenfasst.

Tabelle 1-1. Wichtige funktionale Unterschiede zwischen CoreDNS und BIND

	CoreDNS	BIND
Vollständige Rekursion	Nein	Ja
Dynamische Updates	Nein	Ja
Integration mit Kubernetes	Ja	Nein
Integration mit Amazon Route 53	Ja	Nein
Unterstützung der Domain Name System Security Extensions (DNSSEC)	Begrenzt	Vollständig
Unterstützung für DNS über Transport Layer Security (DoT)	Ja	Nein

Wenn du dir nicht sicher bist, was einige dieser Begriffe bedeuten, keine Sorge, wir behandeln sie später im Buch. Vorher wollen wir aber noch kurz über die formale Beziehung zwischen CoreDNS, Kubernetes und der Cloud Native Computing Foundation sprechen.

CoreDNS, Kubernetes und die Cloud Native Computing Foundation

Kubernetes, das Container-Orchestrierungssystem, mit dem CoreDNS so gut zusammenarbeitet, wurde ursprünglich bei Google entwickelt und dann 2015 in ein Open-Source-Projekt umgewandelt. Um das neue Open-Source-Projekt Kubernetes zu verwalten, hat Google zusammen mit der Linux Foundation die Cloud Native Computing Foundation, kurz CNCF, gegründet.

Die CNCF ist zur Heimat vieler Technologien geworden, die für die Entwicklung cloudbasierter Anwendungen wichtig sind, darunter Prometheus, das das Sammeln von Metriken und Warnmeldungen unterstützt, und Envoy, ein Service-Proxy. Projekte, die von der CNCF verwaltet werden, durchlaufen verschiedene "Reifegrade": von der "Sandbox" für Projekte im Anfangsstadium über die "Inkubation" für Projekte, die Akzeptanz finden, bis hin zur "Graduierung" für reife Projekte, die für eine breite Anwendung geeignet sind.

CoreDNS wurde 2017 bei der CNCF eingereicht und erhielt im Januar 2019 den Status "graduated". Als Beweis dafür, wie wichtig CoreDNS für Kubernetes-Umgebungen ist, wurde CoreDNS mit der im Dezember 2018 veröffentlichten Kubernetes-Version 1.13 zum Standard-DNS-Server von Kubernetes. Da CoreDNS jetzt mit fast jeder neuen Kubernetes-Implementierung installiert wird und Kubernetes ein Moloch in der Welt der Container ist (und Container selbst die Welt im Sturm erobern), erwarten wir, dass die installierte Basis von CoreDNS explodieren wird.

Genug der Lobeshymnen auf CoreDNS. Wir haben darüber gesprochen, wofür CoreDNS gut ist und wofür nicht, und wie sein Schicksal mit Kubernetes verknüpft wurde. Als Nächstes geben wir dir eine kurze Auffrischung der DNS-Theorie, damit wir darüber sprechen können, wie du CoreDNS so konfigurierst, dass es nützliche Arbeit leistet!