Multi-Cluster-DNS mit dem NGINX Ingress Controller automatisieren

Amir RawdatLösungsingenieur

Anwendungen können ihren Zweck nicht erfüllen, wenn Benutzer sie nicht finden können. Das Domain Name System (DNS) ist die Internettechnologie, die Apps und Websites „findet“, indem sie Domainnamen in IP-Adressen übersetzt. DNS ist so allgegenwärtig und zuverlässig, dass man sich die meiste Zeit keine Gedanken darüber macht. Doch wenn DNS-Probleme auftreten, kommt alles zum Stillstand. Für moderne Anwendungen ist es entscheidend, dass DNS zuverlässig funktioniert – insbesondere in Microservices-Architekturen, in denen Dienste ständig hoch- und heruntergefahren werden.

In einem früheren Beitrag haben wir erläutert, wie DNS-Einträge für zwei Subdomains definiert werden, die Anwendungen entsprechen, die im selben Cluster ausgeführt werden (unit-demo.marketing.net für die Marketing-Anwendung und unit-demo.engineering.net für die Engineering-Anwendung) und auf denselben Cluster-Einstiegspunkt verweisen – nämlich auf die externe IP-Adresse des NGINX Ingress Controllers des Clusters. Auf dem NGINX Ingress Controller ist Server-Name-Indication-Routing (SNI) konfiguriert, um Verbindungen anhand des von den Benutzern angeforderten Domainnamens zu authentifizieren und an die entsprechende Anwendung weiterzuleiten.

Viele Unternehmen müssen diesen Anwendungsfall jedoch erweitern und Anwendungen in mehreren Kubernetes-Clustern bereitstellen, die über verschiedene Regionen eines Cloud-Anbieters verteilt sein können. Damit externer Datenverkehr neue Cluster-Regionen erreichen kann, müssen Sie DNS-Zonen erstellen, die auf diese Regionen verweisen.

In der Vergangenheit musste für diesen Prozess ein Drittanbieter (wie GoDaddy oder DNSExit) genutzt werden, um manuell eine Domainregistrierung zu erstellen und die Hosteinträge entsprechend zu aktualisieren. Heute automatisiert das Kubernetes-Projekt ExternalDNS diesen Prozess, indem es Kubernetes-Ressourcen über öffentliche DNS-Server auffindbar macht. Das bedeutet, dass Sie über die Kubernetes-API eine Liste von DNS-Anbietern konfigurieren.

Durch die Integration von ExternalDNS und NGINX Ingress Controller können Sie DNS-A-Einträge so verwalten, dass DNS-Namen aus Hostnamen abgeleitet werden, die in einer standardmäßigen Kubernetes-Ingress-Ressource oder einer benutzerdefinierten NGINX-VirtualServer-Ressource deklariert sind. Entwickler und DevOps-Teams können diese Integration in ihren CI/CD-Pipelines nutzen, um Anwendungen über verschiedene Cluster hinweg automatisch zu erkennen, ohne das NetOps-Team (das üblicherweise für DNS zuständig ist) einbeziehen zu müssen.

In diesem Beitrag zeigen wir, wie Sie Beispielkonfigurationsdateien aus unserem GitHub-Repository verwenden, um ExternalDNS in den NGINX Ingress Controller zu integrieren.

Die Basisarchitektur

Zur Implementierung von ExternalDNS mit dem NGINX Ingress Controller gehen wir vom grundlegenden Anwendungsfall aus, bei dem Entwickler einen Ingress Controller so konfigurieren, dass Kubernetes-Anwendungen extern erreichbar sind. Clients können erst dann eine Verbindung zu den Anwendungen herstellen, wenn der konfigurierte Domainname auf den öffentlichen Zugangspunkt des Kubernetes-Clusters verweist.

Der NGINX Ingress Controller interagiert über das zwischengeschaltete ExternalDNS-Kubernetes-Deployment mit dem DNS-Anbieter und ermöglicht so die automatische Erkennung von Kubernetes-Anwendungen mithilfe externer DNS-Einträge. Im Diagramm stellen die schwarzen Linien den Datenpfad dar, über den externe Benutzer auf Anwendungen im Kubernetes-Cluster zugreifen. Die violetten Linien stellen den Steuerungspfad dar, über den Anwendungseigentümer externe DNS-Einträge mithilfe von VirtualServer-Ressourcen in der Konfiguration des NGINX Ingress Controllers verwalten und ExternalDNS auf den DNS-Anbieter zugreift.

Integration von ExternalDNS und NGINX Ingress Controller

Führen Sie die in den folgenden Abschnitten beschriebenen Schritte aus, um ExternalDNS und den NGINX Ingress Controller zu integrieren.

• Voraussetzungen
• NGINX Ingress Controller und ExternalDNS bereitstellen
• NGINX Ingress Controller konfigurieren

Voraussetzungen

1. Erstellen Sie mindestens eine registrierte Domain. Ersetzen Sie in den folgenden Schritten <my‑domain> durch deren Namen. (Es gibt zahlreiche Artikel zur Registrierung einer Domain, darunter diesen Leitfaden von PCMag.)
2. Stellen Sie den NGINX Ingress Controller mithilfe von Manifesten oder Helm-Charts bereit. Fügen Sie die entsprechenden Befehlszeilenargumente zur Bereitstellungsspezifikation hinzu:
   • -enable-external-dns – Aktiviert die Integration mit ExternalDNS.
   • -external-service=nginx-ingress – Weist den NGINX Ingress Controller an, seinen öffentlichen Einstiegspunkt zur Eintragung in die vom DNS-Anbieter verwalteten A-Einträge bekannt zu geben. Der Hostname des öffentlichen Einstiegspunkts wird zum externen Dienst nginx-ingress aufgelöst.
3. Wenn Sie den Kubernetes-Cluster lokal bereitstellen, richten Sie einen externen Load Balancer ein. Eine Anleitung zur Bereitstellung von NGINX als externem Load Balancer mit BGP finden Sie in unserem kostenlosen E-Book „Get Me to the Cluster“. Alternativ können Sie F5 BIG‑IP oder MetalLB verwenden.
4. Erstellen Sie bei Bedarf eine DNS-Zone bei einem von ExternalDNS unterstützten Anbieter. Dieser Befehl gilt für den in der Beispielbereitstellung verwendeten Anbieter Google Cloud DNS.

$ gcloud dns managed-zones create "external-dns-<my-domain>" --dns-name "external-dns.<my-domain>." --description "Zone automatically managed by ExternalDNS"

NGINX Ingress Controller und ExternalDNS bereitstellen

1. Klonen Sie das GitHub-Repository für die Beispielbereitstellung und stellen Sie den NGINX Ingress Controller bereit.

$ git clone https://github.com/nginxinc/NGINX-Demos.git && cd NGINX-Demos/external-dns-nginx-ingress/ 
$ kubectl apply -f nginx-ingress.yaml && kubectl apply -f loadbalancer.yaml

1. Aktualisieren Sie die folgenden Argumente in der ExternalDNS-Bereitstellungsspezifikation (bei der Beispielbereitstellung in den Zeilen 59–62 von „external-dns-gcloud.yaml“): Hinweis: Welche Argumente Sie in die ExternalDNS-Bereitstellungsspezifikation aufnehmen müssen, hängt möglicherweise vom gewählten DNS-Anbieter ab. Eine Liste mit Anleitungen zur Bereitstellung von ExternalDNS im Cluster mit verschiedenen DNS-Anbietern finden Sie in der ExternalDNS-Dokumentation.
   • --domain-filter – Der Name der Domain, die in Schritt 4 des vorherigen Abschnitts erstellt wurde (in der Beispielbereitstellung external-dns.<my-domain>). Entfernen Sie alle vorhandenen Werte, sodass nur diese Domain verwendet wird.
   • --provider – Der DNS-Anbieter (in der Beispielbereitstellung google für Google DNS).
   • --google-project – Der Name des Google-Projekts für die Beispielbereitstellung (nur erforderlich, wenn Sie mehr als ein Google-Projekt haben).
   • --txt-owner-id – Die von Ihnen gewählte ID (eindeutig für die Beispielbereitstellung).
2. Stellen Sie ExternalDNS im Cluster bereit und überprüfen Sie, ob die Bereitstellung erfolgreich ausgeführt wird (zur besseren Lesbarkeit ist die Ausgabe auf zwei Zeilen verteilt).

$ kubectl apply -f external-dns-gcloud.yaml$ kubectl get pods -o wide
NAME                                READY  STATUS    ...
external-dns-4hrytf7f98f-ffuffjbf7  1/1    Running   ...
    ... RESTARTS   AGE
    ... 0          1m

NGINX Ingress Controller konfigurieren

Als Nächstes konfigurieren wir eine VirtualServer-Ressource mit einer Ingress-Lastverteilungsregel, die externe Verbindungen an unsere Kubernetes-Anwendungen weiterleitet.

1. Legen Sie in „app-virtual-server.yaml“ das Feld „host“ fest (Zeile 6):

 6    host: ingress.external-dns.<my-domain>

1. Die Übereinstimmung zwischen diesem Wert und dem Wert von domain-filter in Zeile 59 der Datei external-dns-gcloud.yaml (festgelegt in Schritt 2 im vorherigen Abschnitt) ermöglicht die automatische Aktualisierung der DNS-Einträge.
2. Wenden Sie app-virtual-server.yaml an und überprüfen Sie, ob der VirtualServer korrekt konfiguriert ist.

$ kubectl apply -f app-secret.yaml && kubectl apply -f app-virtual-server.yaml
$ kubectl get vs 
NAME   STATE   HOST                              IP            
cafe   Valid   ingress.external-dns.<my-domain>  34.168.X.Y

1. Überprüfen Sie, ob der DNS-Zone ein DNS-Eintrag vom Typ A hinzugefügt wurde. Insbesondere muss die IP-Adresse im Feld DATA mit dem Feld IP in der Ausgabe des Befehls kubectl get vs aus dem vorherigen Schritt übereinstimmen (der externen IP-Adresse des Dienstes vom Typ LoadBalancer, der den NGINX Ingress Controller verfügbar macht, beziehungsweise dem entsprechenden Wert bei einer lokalen Bereitstellung).

$ gcloud dns record-sets list --zone external-dns-<my-domain> -name ingress.external-dns.<my-domain> --type ANAME                               TYPE     TTL     DATA
ingress.external-dns.<my-domain>.  A        300     34.168.X.Y

1. Um zu überprüfen, ob der Hostname des VirtualServers auf dem lokalen Rechner aufgelöst werden kann, rufen Sie die der DNS-Zone zugewiesenen Nameserver ab (in diesem Fall „my-ns-domains“).

$ gcloud dns record-sets list --zone external-dns.<my-domain> --name external-dns.<my-domain>. --type NSNAME                        TYPE      TTL     DATA
external-dns.<my-domain>.   NS        21600   my-ns-domains

$ dig +short @my-ns-domains ingress.external-dns.<my-domain>
34.168.X.Y

1. Verwenden Sie die im vorherigen Schritt abgerufenen DNS-Einträge als dedizierte Nameserver für Ihre registrierte Domain. Dadurch wird Ihre registrierte Domain als übergeordnete Zone der DNS-Zone festgelegt, die in Schritt 4 unter „Voraussetzungen“ erstellt wurde.
2. Überprüfen Sie, ob Sie auf den Hostnamen des VirtualServers zugreifen können, nachdem dieser nun über das globale Internet erreichbar ist.

$ curl -i --insecure https://ingress.external-dns.<my-domain>/teaHTTP/1.1 200 OK
Server: nginx/1.23.0
Date: Day, DD MM YYYY hh:mm:ss TZ
Content-Type: text/plain
Content-Length: 160
Connection: keep-alive
Expires: Day, DD MM YYYY hh:mm:ss TZ
Cache-Control: no-cache

Mehrere Kubernetes-Cluster horizontal skalieren

Sie können die Architektur schnell skalieren und mehrere Cluster automatisch erkennen, indem Sie die Erstellung externer DNS-Einträge automatisieren und diese den neuen Cluster-Einstiegspunkten (Kubernetes-Cluster 1 und Kubernetes-Cluster 2) im Diagramm zuordnen. Wiederholen Sie die Anweisungen unter NGINX Ingress Controller und ExternalDNS bereitstellen und NGINX Ingress Controller konfigurieren.

Sie können auch Infrastructure-as-Code-Tools in Ihrer CI/CD-Pipeline verwenden, um neue Cluster zu erstellen und sie mithilfe von ExternalDNS und dem NGINX Ingress Controller für externen Datenverkehr zugänglich zu machen. Darüber hinaus können Sie mehrere DNS-Zonen oder sogar mehrere DNS-Anbieter verwalten, je nachdem, wie die Erkennung aktiviert ist.

Fazit

Produktivität und Sicherheitsmaßnahmen zur Eindämmung von Sicherheitsverletzungen miteinander in Einklang zu bringen, kann schwierig sein. Einschränkungen für DevOps-Teams führen häufig zu Spannungen zwischen ihnen und den NetOps-/SecOps-Teams. Wie die optimale Balance aussieht, ist von Unternehmen zu Unternehmen unterschiedlich. NGINX bietet die nötige Flexibilität, um eine Balance zu schaffen, die Ihren Prioritäten und Anforderungen entspricht.

In der Vergangenheit waren Anwendungsverantwortliche auf NetOps-Teams angewiesen, um ihre Anwendungen mit externen Systemen zu verbinden. Durch die ExternalDNS-Integration mit NGINX können Entwickler und DevOps-Teams selbstständig auffindbare Anwendungen bereitstellen und so Innovationen schneller auf den Markt bringen.

Einen umfassenden Leitfaden für den Einstieg in NGINX in Kubernetes finden Sie in unserem kostenlosen E-Book Kubernetes-Datenverkehr mit F5 NGINX verwalten: Ein praktischer Leitfaden.

Sie können auch noch heute loslegen, indem Sie eine kostenlose 30-Tage-Testversion des NGINX Ingress Controller mit NGINX App Protect WAF und DoS anfordern oder uns kontaktieren, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Amir RawdatLösungsingenieur

Weitere Blogbeiträge von Amir Rawdat