Share via

Active Directory- und Kubernetes-DNS-Abstimmung in Big Data-Cluster-Bereitstellungen

  • Artikel

In diesem Artikel werden einige der Herausforderungen beim Implementieren der Active Directory-Integration während der Bereitstellung von Big Data-Cluster sowie die entsprechenden Lösungen beschrieben.

Wichtig

Das Microsoft SQL Server 2019-Big Data-Cluster-Add-On wird eingestellt. Der Support für SQL Server 2019-Big Data-Clusters endet am 28. Februar 2025. Alle vorhandenen Benutzer*innen von SQL Server 2019 mit Software Assurance werden auf der Plattform vollständig unterstützt, und die Software wird bis zu diesem Zeitpunkt weiterhin über kumulative SQL Server-Updates verwaltet. Weitere Informationen finden Sie im Ankündigungsblogbeitrag und unter Big Data-Optionen auf der Microsoft SQL Server-Plattform.

Übersicht

Wenn der Big Data-Cluster nicht mit Active Directory-Integration bereitgestellt wird, wird der Dienst Kubernetes CoreDNS für interne DNS-Auflösungen verwendet. Kubernetes verwendet eine interne Domäne, z. B. <namespace>.svc.cluster.local. Es werden A-Einträge (Forward-Lookup) und PTR-Einträge (Reverse-Lookup) auf dem DNS-Server mit Namen in dieser Domäne erstellt.

Wenn der Active Directory-Modus aktiviert ist, wird jedoch eine neue Domäne mit eigenen DNS-Servern verwendet. Bei der internen Namensauflösung kann dies zu Verwirrung in Bezug darauf führen, welche DNS-Server für Forward- und Reverse-Lookups zu verwenden sind.

Herausforderungen

  • Wenn neue Kubernetes-Pods bereitgestellt werden, müssen in beiden Gruppen von DNS-Servern DNS-Einträge hinzugefügt werden. Kubernetes übernimmt das Speichern der Einträge in Kubernetes CoreDNS. Das Hinzufügen der erforderlichen Einträge auf den DNS-Servern der Active Directory-Domänencontroller erfolgt jedoch im BDC-Bereitstellungsworkflow. Ebenso muss der Workflow beim Löschen eines Big Data-Clusters sicherstellen, dass diese Einträge entfernt werden.
  • Active Directory-DNS-Server sind nicht Teil des Kubernetes-Clusters. BDC verfügt jedoch über einen eigenen IP-Adressraum in Kubernetes, für den BDC keine Einträge auf einem externen DNS-Server erstellen kann, da er außerhalb der Clustergrenzen nicht sichtbar ist.
  • Wenn im Kubernetes-Cluster Failoverereignisse auftreten, müssen auch die Einträge auf den AD-DNS-Servern aktualisiert werden.
  • Neben den Podnamen müssen auch die Namen von Kubernetes-Diensten über AD-Domänennamenlookups adressierbar sein. Dies stellt eine weitere Herausforderung im Active Directory-DNS dar, da ein einzelner Dienstname mehreren Pod-IP-Adressen zugeordnet sein kann.
  • Es kann zu erheblichen Verzögerungen bei der Weiterleitung von Updates und der Replizierung auf den Active Directory-DNS-Servern der Organisation kommen, auf die die BDC-Verwaltungsworkflows keinen Einfluss haben. Dies kann sich direkt bei der Bereitstellung und beim Failover auf die BDC-Funktionalität auswirken. Im Gegensatz dazu ist Kubernetes CoreDNS aufgrund des Orts schneller und effizienter.

Lösung

Zur Umgehung der oben erwähnten Herausforderungen umfasst die in BDC implementierte Lösung den neuen internen CoreDNS-Dienst, der innerhalb des BDC-Namespace verwaltet wird. Dies ist der einzige DNS-Dienst, den die Pods im BDC-Namespace für die Namensauflösung verwenden. Die Komplexität mehrerer Domänen wird hinter dem neuen CoreDNS-Dienst verborgen.

Zum Beispiel im folgenden Diagramm verwenden die Pods den BDC-CoreDNS-Server für die Namensauflösung. Die Pods interagieren weder mit dem Kubernetes-CoreDNS-Server noch mit dem AD-DNS-Server direkt.

Pods stellen eine Verbindung mit dem CoreDNS-Server im eigenen Namespace her

Im Folgenden sind einige der Implementierungsdetails aufgeführt, die die Funktionsweise dieses Aufbaus in BDC verdeutlichen:

Zentrale Verwaltung mehrerer Domänen

Die Komplexität der Vorgänge bei Namensabfragen bleibt zentral hinter dem internen DNS-Dienst verborgen. Dadurch wird vermieden, dass einzelne Pods mehrere Domänen verwalten müssen, und die Struktur wird vereinfacht.

Keine Einträge für interne Pods auf externen DNS-Servern

Aufgrund dieses Strukturprinzips muss BDC keine A- und PTR-Einträge für Pods im Kubernetes-IP-Adressraum auf externen DNS-Servern erstellen und verwalten.

Keine Duplizierung von Einträgen

Interne DNS-Einträge an mehreren Orten. Der einzige Speicher für diese Einträge ist Kubernetes CoreDNS. Die BDC-interne Version von CoreDNS führt eine computerseitige Umschreibung und Weiterleitung von DNS-Abfragen an Kubernetes CoreDNS durch.

Computerseitige Umschreibung

Da BDC keine Einträge speichert, ist BDC für die Übersetzung eingehender Forward-Lookup-Abfragen mit Namen in der AD-Domäne in die Namen in der Kubernetes-Domäne sowie die Weiterleitung dieser Abfragen an Kubernetes CoreDNS zuständig. Beispielsweise würde eine eingehende Abfrage für compute-0-0.contoso.local in compute-0-0.compute-0-svc.contoso.svc.cluster.local umgeschrieben und diese Abfrage dann an Kubernetes CoreDNS weitergeleitet. Bei Reverse-Lookups wird die Abfrage mit den internen IP-Adressen aus Kubernetes CoreDNS weitergeleitet und die Antwort in den AD-Domänennamen umgeschrieben, bevor sie an den Client gesendet wird.

Einfachheit bei Podkonfigurationen

Da bei allen BDC-Pods in /etc/resolv.conf nur auf die BDC-interne Version von CoreDNS verwiesen wird, vereinfacht dies die Netzwerkansicht aus Sicht der Pods. Die Komplexität wird stattdessen in der internen Version von CoreDNS verborgen.

Statische und zuverlässige IP-Adresse für den DNS-Dienst

Der von BDC bereitgestellte CoreDNS-Dienst verfügt über eine registrierte statische interne IP-Adresse, auf die von allen Pods aus zugegriffen werden kann. Dadurch wird sichergestellt, dass die Werte in /etc/resolv.conf nicht aktualisiert werden müssen.

Die Verwaltung des Lastenausgleichs für den Dienst wird weiterhin von Kubernetes übernommen.

Wenn Lookups für Dienste anstelle einzelner Pods durchgeführt werden, werden sie weiterhin an Kubernetes CoreDNS weitergeleitet, sodass BDC nicht für die Implementierung eines Lastenausgleichs speziell für die AD-Domäne verantwortlich ist.

Wenn beispielsweise eine Forward-Lookup-Abfrage für compute-0-svc.contoso.local erfolgt, wird diese in compute-0-svc.contoso.svc.cluster.local umgeschrieben. Diese Abfrage wird an Kubernetes CoreDNS weitergeleitet, wo der Lastenausgleich vorgenommen wird. Die Antwort ist eine IP-Adresse für eine der verschiedenen Computepoolinstanzen (Podreplikate).

Skalierbarkeit

Da BDC keine Einträge speichert, kann die BDC-interne Version von CoreDNS ohne Zustandsbeibehaltung und Eintragsreplikation replikateübergreifend skaliert werden. Wenn die DNS-Einträge in BDC gespeichert werden, muss BDC auch den Status in alle Pods replizieren.

Extern sichtbare Diensteinträge bleiben im AD-DNS

Für Dienstendpunkte, auf die Clients außerhalb des Kubernetes-Clusters zugreifen können müssen, werden bei der Bereitstellung von BDC DNS-Einträge auf dem AD-DNS-Server erstellt. Der Benutzer gibt die zu registrierenden DNS-Namen über die Bereitstellungskonfigurationsprofile an.

Eigenes Aufheben der Bereitstellung

Wenn BDC gelöscht wurde, ist keine zusätzliche dynamische Arbeit zum Löschen von DNS-Einträgen erforderlich, wenn die Bereitstellung des Clusters aufgehoben wird. Die einzigen Einträge im Remote-Active Directory-DNS, die bereinigt werden müssen, sind für externe Dienste, und die Anzahl dieser Einträge ist statisch. Die internen DNS-Einträge werden automatisch zusammen mit dem Cluster entfernt.

Nächste Schritte