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

In diesem Artikel werden einige der Herausforderungen und Lösungen beschrieben, die bei der Bereitstellung von Big Data-Clustern die Active Directory-Integration berücksichtigen.

Overview

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

Wenn der Active Directory-Modus aktiviert ist, wird jedoch eine neue Domäne mit einem eigenen Satz von DNS-Servern in das Bild aufgenommen. Bei der internen Namensauflösung kann dies zu Verwirrung führen, zu welcher Gruppe von DNS-Servern für Forward- und Reverse-Lookups gewechselt werden soll.

Challenges

• Wenn neue Kubernetes-Pods bereitgestellt werden, müssen DNS-Einträge in beiden Gruppen von DNS-Servern hinzugefügt werden. Kubernetes übernimmt jedoch die Aufzeichnung der Einträge in seinem CoreDNS. BDC-Bereitstellungsworkflow ist jedoch für das Hinzufügen der erforderlichen Einträge in Active Directory-Domänencontroller-DNS-Servern verantwortlich. Ebenso muss der Workflow beim Löschen eines Big Data-Clusters sicherstellen, dass diese Einträge entfernt werden.
• Active Directory-DNS-Server sind außerhalb des Kubernetes-Clusters. BDC verfügt jedoch über einen eigenen IP-Speicherplatz in Kubernetes und kann keine Einträge für diesen IP-Speicherplatz in einem externen DNS-Server erstellen, da dieser IP-Bereich außerhalb der Clustergrenzen nicht sichtbar ist.
• Wenn Failoverereignisse im Kubernetes-Cluster auftreten, müssen einträge in AD-DNS-Servern ebenfalls aktualisiert werden.
• Zusätzlich zu Podnamen müssen Kubernetes-Dienstnamen auch über die AD-Domänennamensuche adressierbar sein. Dadurch entsteht eine zusätzliche Herausforderung in Active Directory DNS, da ein Dienstname mehreren Pod-IP-Adressen zugeordnet werden kann.
• Datensatzaktualisierungsweitergabe und Replikationsverzögerungen in Active Directory-DNS-Servern der Organisation können erheblich und über die Kontrolle der BDC-Verwaltungsworkflows hinausgehen. Dies kann sich unmittelbar auf die BDC-Funktionalität bei Deployment und Failover auswirken. Im Gegenteil, Kubernetes CoreDNS ist aufgrund seiner Lokalität schneller und effizient.

Solution

Um die oben genannten Herausforderungen zu umgehen, umfasst die in BDC implementierte Lösung einen neuen internen CoreDNS-Dienst, der im BDC-Namespace verwaltet wird. In diesem BDC-Namespace ist dies der einzige DNS-Dienst, den die Pods für Namensauflösungen anfragen. Die Komplexität mehrerer Domänen ist hinter dem neuen CoreDNS-Dienst verborgen.

Im folgenden Diagramm verwenden die Pods beispielsweise den BDC CoreDNS-Server, um Namen aufzulösen. Die Pods interagieren nicht direkt mit dem Kubernetes CoreDNS-Server oder dem AD-DNS-Server.

Hier sind einige der Implementierungsdetails, die verdeutlichen, wie dieses Design in BDC funktioniert:

Zentralisierte Verwaltung mehrerer Domänen

Die Komplexität dessen, was bei Namensabfragen geschieht, bleibt hinter dem internen DNS-Dienst zentral verborgen. Dadurch wird vermieden, dass die Last der Verwaltung mehrerer Domänen auf einzelne Pods gelegt wird, was das Design vereinfacht.

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

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

Keine Duplizierung von Datensätzen

Interne DNS-Einträge an mehreren Stellen. Der einzige Speicher für diese Datensätze ist Kubernetes CoreDNS. Der interne CoreDNS des BDC führt ein rechenbasiertes Umschreiben und Weiterleiten von DNS-Abfragen an Kubernetes CoreDNS durch.

Computational rewriting

Da BDC keine Datensätze speichert, ist BDC für die Übersetzung eingehender Forward-Lookup-Abfragen mit Namen mit AD-Domänen an die Namen mit der Kubernetes-Domäne verantwortlich und leitet diese Abfrage an Kubernetes CoreDNS weiter. Beispielsweise würde eine eingehende Abfrage von compute-0-0.contoso.local zu compute-0-0.compute-0-svc.contoso.svc.cluster.local umgeschrieben und diese Anfrage an Kubernetes CoreDNS weitergeleitet. Bei umgekehrten Nachschlagevorgängen wird die Anforderung mit internen IPs, wie sie sind, an Kubernetes CoreDNS weitergeleitet, und die Antwort wird von dort zum AD-Domänenname umgeschrieben, bevor an den Client geantwortet wird.

Übersichtlichkeit in Pod-Konfigurationen

Da nur auf den internen BDC CoreDNS in /etc/resolv.conf aller BDC-Pods verwiesen wird, vereinfacht dies die Netzwerkansicht von den Pods. Die Komplexität wird stattdessen im internen CoreDNS ausgeblendet.

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

Der CoreDNS-Dienst, den BDC bereitstellt, verfügt über registrierte statische interne IP-Adressen, auf die über alle Pods zugegriffen werden kann. Dadurch wird sichergestellt, dass die Werte in /etc/resolv.conf nicht aktualisiert werden müssen.

Die Verwaltung des Dienstlastenausgleichs wird von Kubernetes beibehalten.

Wenn Dienste statt einzelner Pods abgefragt werden, erfolgt die Abfrage weiterhin über Kubernetes CoreDNS, sodass BDC nicht für die Implementierung des Lastenausgleichs speziell für AD-Domänen verantwortlich ist.

Wenn beispielsweise eine Forward-Lookup-Anforderung für compute-0-svc.contoso.local erfolgt, wird sie in compute-0-svc.contoso.svc.cluster.local umgeschrieben. Diese Anforderung wird an Kubernetes CoreDNS weitergeleitet, und der Lastenausgleich erfolgt dort. Eine Antwort ist eine IP-Adresse für eine der mehreren Computepoolinstanzen (Pod-Replikate).

Scalability

Da BDC keine Datensätze speichert, kann der interne BDC CoreDNS ohne Zustandsaufbewahrung und Datensatzreplikation über mehrere Replikate skaliert werden. Wenn die DNS-Einträge in BDC gespeichert werden, muss auch das Replizieren des Zustands über alle Pods hinweg von BDC übernommen werden.

Extern sichtbare Diensteinträge bleiben in AD DNS

Für Dienstendpunkte, auf die für Clients außerhalb des Kubernetes-Clusters zugegriffen werden muss, werden DNS-Einträge im AD-DNS-Server erstellt, da BDC bereitgestellt wird. Der Benutzer gibt die DNS-Namen ein, die über die Bereitstellungskonfigurationsprofile registriert werden sollen.

Self-deprovisioning

Nachdem BDC gelöscht wurde, gibt es keine zusätzliche dynamische Arbeit zum Löschen von DNS-Einträgen, wenn der Cluster aufgehoben wird. Die einzigen Einträge in Active Directory-Remote-DNS, die bereinigt werden müssen, sind für externe Dienste vorgesehen, und sie sind statisch. Die internen DNS-Einträge werden automatisch mit dem Cluster entfernt.

Next steps

• Bereitstellen von Big Data-Cluster für SQL Server im Active Directory-Modus
• Verwalten des Zugriffs auf Big Data-Cluster im Active Directory-Modus
• Bereitstellen mehrerer SQL Server Big Data-Cluster in derselben Active Directory-Domäne