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 Domänennamen in IP-Adressen übersetzt. DNS ist so allgegenwärtig und zuverlässig, dass Sie an den meisten Tagen nicht einmal darüber nachdenken. Aber wenn es DNS-Probleme gibt, stoppt alles. Für moderne Anwendungen ist es von entscheidender Bedeutung, sicherzustellen, dass DNS funktioniert, insbesondere in Microservices-Architekturen, in denen Dienste ständig hoch- und heruntergefahren werden.
In einem früheren Beitrag haben wir über die Definition von DNS-Einträgen für zwei Subdomänen gesprochen, die Anwendungen entsprechen, die im selben Cluster ausgeführt werden ( unit-demo.marketing.net für die Marketing- App und unit-demo.engineering.net für die Engineering -App) und zum selben Cluster-Einstiegspunkt aufgelöst werden – nämlich der externen IP-Adresse des NGINX Ingress Controllers des Clusters. Das Server Name Indication (SNI)-Routing wird auf dem NGINX Ingress Controller konfiguriert, um Verbindungen basierend auf dem von den Benutzern angeforderten Domänennamen zu authentifizieren und an die entsprechende Anwendung weiterzuleiten.
Viele Organisationen müssen diesen Anwendungsfall jedoch erweitern und Anwendungen in mehreren Kubernetes-Clustern bereitstellen, die möglicherweise über verschiedene Regionen der Cloud-Anbieter verteilt sind. Damit externer Datenverkehr neue Clusterregionen erreichen kann, müssen Sie DNS-Zonen erstellen, die in diese Regionen aufgelöst werden.
In der Vergangenheit war für diesen Vorgang die Nutzung eines Drittanbieters (wie etwa GoDaddy oder DNSExit) erforderlich, um manuell ein Domänenregister zu erstellen und die Hostdatensätze entsprechend zu aktualisieren. Jetzt automatisiert das ExternalDNS Kubernetes-Projekt den Prozess, indem es Kubernetes-Ressourcen über öffentliche DNS-Server auffindbar macht. Das bedeutet, dass Sie die Kubernetes-API verwenden, um eine Liste von DNS-Anbietern zu konfigurieren.
Mit einer Integration zwischen ExternalDNS und NGINX Ingress Controller können Sie DNS- A-
Einträge so verwalten, dass DNS-Namen von 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 in verschiedenen Clustern automatisch zu erkennen, ohne das NetOps-Team (das normalerweise für DNS zuständig ist) einzubeziehen.
In diesem Beitrag zeigen wir, wie Sie Beispielkonfigurationsdateien aus unserem GitHub-Repository verwenden, um ExternalDNS in den NGINX Ingress Controller zu integrieren.
Um ExternalDNS mit NGINX Ingress Controller zu implementieren, beginnen wir mit dem Basisfall, in dem Entwickler einen Ingress-Controller konfigurieren, um Kubernetes-Apps extern verfügbar zu machen. Clients können keine Verbindung zu den Apps herstellen, bis der konfigurierte Domänenname zum öffentlichen Einstiegspunkt des Kubernetes-Clusters aufgelöst wird.
NGINX Ingress Controller interagiert mit dem DNS-Anbieter über die zwischengeschaltete ExternalDNS-Kubernetes-Bereitstellung 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 Kontrollpfad dar, über den App-Besitzer externe DNS-Einträge mit VirtualServer-Ressourcen in der NGINX Ingress Controller-Konfiguration verwalten und externes DNS auf den DNS-Anbieter zugreift.
Führen Sie die Schritte in den folgenden Abschnitten aus, um ExternalDNS und NGINX Ingress Controller zu integrieren.
<meine‑Domäne>
in den folgenden Schritten. (Es gibt zahlreiche Artikel zur Registrierung einer Domain, darunter auch diesen Leitfaden von PCMag .)Stellen Sie den NGINX Ingress Controller mithilfe von Manifesten oder Helm-Diagrammen bereit. Fügen Sie der Bereitstellungsspezifikation das Äquivalent dieser Befehlszeilenargumente hinzu:
-enable-external-dns
– Aktiviert die Integration mit ExternalDNS.-external-service=nginx-ingress
– Weist den NGINX Ingress Controller an, seinen öffentlichen Einstiegspunkt für die Aufzeichnung in A-
Einträgen bekannt zu geben, die vom DNS-Anbieter verwaltet werden. Der Hostname des öffentlichen Einstiegspunkts wird zum externen Dienst nginx-ingress
aufgelöst.Erstellen Sie bei Bedarf eine DNS-Zone in einem von ExternalDNS unterstützten Provider . Dieser Befehl ist für den in der Beispielbereitstellung verwendeten Anbieter, Google Cloud DNS.
$ gcloud dns managed-zones erstellt "external-dns-<meine-Domäne>" --dns-name "externes DNS.<meine-Domäne>." --description "Zone wird automatisch von ExternalDNS verwaltet"
Klonen Sie das GitHub-Repository für die Beispielbereitstellung und stellen Sie 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
Aktualisieren Sie die folgenden Argumente in der ExternalDNS-Bereitstellungsspezifikation (in den Zeilen 59–62 in external-dns-gcloud.yaml für die Beispielbereitstellung):
--domain-filter
– Der Name der Domain, die in Schritt 4 des vorherigen Abschnitts (in der Beispielbereitstellung, externer DNS.<meine-Domäne>
). Entfernen Sie alle vorhandenen Werte, sodass nur diese Domäne verwendet wird.--provider
– Der DNS-Anbieter (in der Beispielbereitstellung google
für Google DNS).--google-project
– Der Name des Google-Projekts, das Sie für die Beispielbereitstellung verwenden (nur erforderlich, wenn Sie mehr als ein Google-Projekt haben).--txt-owner-id
– Die von Ihnen gewählte ID (eindeutig für die Beispielbereitstellung).Notiz: Die Argumente, die Sie in die ExternalDNS-Bereitstellungsspezifikation aufnehmen müssen, können je nach gewähltem DNS-Anbieter variieren. Eine Liste mit Tutorials zum Bereitstellen von ExternalDNS im Cluster mit verschiedenen DNS-Anbietern finden Sie in der ExternalDNS-Dokumentation .
Stellen Sie ExternalDNS im Cluster bereit und überprüfen Sie, ob die Bereitstellung erfolgreich ausgeführt wird (die Ausgabe ist zur besseren Lesbarkeit auf zwei Zeilen verteilt).
$ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide NAME BEREIT STATUS ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 Wird ausgeführt ... ... STARTET DAS ALTER NEU ... 0 1 m
Als Nächstes konfigurieren wir eine VirtualServer-Ressource mit einer Ingress-Lastausgleichsregel, die externe Verbindungen in unsere Kubernetes-Anwendungen weiterleitet.
Legen Sie in app-virtual-server.yaml das Host-
Feld fest (Zeile 6):
6 Host: ingress.external-dns.<meine-Domäne>
Die Zuordnung zwischen diesem Wert und dem Wert des Domänenfilters
in Zeile 59 von external-dns-gcloud.yaml (festgelegt in Schritt 2 im vorherigen Abschnitt) ermöglicht die automatische Aktualisierung von DNS-Einträgen.
Wenden Sie app-virtual-server.yaml an und überprüfen Sie, ob der VirtualServer richtig konfiguriert ist.
$ kubectl apply -f app-secret.yaml und kubectl apply -f app-virtual-server.yaml
$ kubectl get vs
NAME STAAT HOST IP
cafe Gültiger ingress.external-dns.<meine-Domäne> 34.168.X.Y
Überprüfen Sie, ob der DNS-Zone ein DNS-Eintrag vom Typ A
hinzugefügt wurde. Insbesondere muss die IP-Adresse im DATA-
Feld mit dem IP-
Feld in der Ausgabe des Befehls kubectl
get
vs
im vorherigen Schritt übereinstimmen (die externe IP-Adresse des Dienstes vom Typ LoadBalancer
, der NGINX Ingress Controller verfügbar macht, oder das Äquivalent in einer lokalen Bereitstellung).
$ gcloud dns record-sets list --zone external-dns-<meine-Domäne> -name ingress.external-dns.<meine-Domäne> --Typ ANAME TYP TTL DATEN
ingress.external-dns.<meine-Domäne>. A 300 34.168. X . Y
Um zu überprüfen, ob der VirtualServer-Hostname auf dem lokalen Computer 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.<meine-Domäne> --name externer DNS.<meine-Domäne>. --Typ NSNAME TYP TTL DATEN
externer DNS.<meine-Domäne>. NS 21600 meine-ns-domains
$ dig +short @meine-ns-domains ingress.external-dns.<meine-Domäne>
34.168.X.Y
Überprüfen Sie, ob Sie auf den VirtualServer-Hostnamen zugreifen können, da dieser nun dem globalen Internet zugänglich ist.
$ curl -i --insecure https://ingress.external-dns.<meine-Domäne>/TeeHTTP/1.1 200 OK
Server: nginx/1.23.0
Datum: Tag , TT MM JJJJ hh : mm : ss TZ Inhaltstyp: Text/Plain Inhaltslänge: 160 Verbindung: Keep-Alive Läuft ab: Tag , TT MM JJJJ hh : mm : ss TZ Cache-Control: no-cache
Sie können die Architektur schnell skalieren und mehrere Cluster automatisch erkennen, indem Sie die Erstellung externer DNS-Einträge automatisieren und diese im Diagramm in neue Cluster-Einstiegspunkte ( Kubernetes-Cluster 1 und Kubernetes-Cluster 2 ) auflösen. Wiederholen Sie die Anweisungen unter „NGINX Ingress Controller und ExternalDNS bereitstellen“ und „NGINX Ingress Controller konfigurieren“ .
Sie können in Ihrer CI/CD-Pipeline auch Infrastructure-as-Code- Tools verwenden, um mithilfe von ExternalDNS und NGINX Ingress Controller neue Cluster zu generieren und für externen Datenverkehr verfügbar zu machen. Darüber hinaus können Sie mehrere DNS-Zonen oder sogar mehrere DNS-Anbieter verwalten, je nachdem, wie die Erkennung aktiviert ist.
Es kann schwierig sein, die Produktivität mit Sicherheitsmaßnahmen in Einklang zu bringen, die Verstöße eindämmen. Das Auferlegen von Beschränkungen für DevOps-Teams führt häufig zu Reibereien zwischen ihnen und den NetOps-/SecOps-Teams. Das ideale Gleichgewicht ist in jeder Organisation anders und NGINX bietet die Flexibilität, ein Gleichgewicht herzustellen, das Ihren Prioritäten und Anforderungen entspricht.
In der Vergangenheit verließen sich App-Besitzer auf NetOps-Teams, um ihre Anwendungen mit externen Systemen zu verbinden. Durch die Verwendung der ExternalDNS-Integration mit NGINX können Entwickler und DevOps-Teams auffindbare Anwendungen selbst bereitstellen und so die Markteinführungszeit für Innovationen verkürzen.
Eine umfassende Anleitung zum Einstieg in NGINX in Kubernetes finden Sie in unserem kostenlosen E-Book „Verwaltung des Kubernetes-Verkehrs mit F5 NGINX“: Ein praktischer Leitfaden .
Sie können auch noch heute loslegen, indem Sie eine 30-tägige kostenlose Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS anfordern oder uns kontaktieren, um Ihre Anwendungsfälle zu besprechen .
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."