Automatisation du DNS multi-cluster avec NGINX Ingress Controller

Les applications ne peuvent pas remplir leur fonction si les utilisateurs ne peuvent pas les trouver. Le système de noms de domaine (DNS) est la technologie Internet qui « trouve » des applications et des sites Web en traduisant les noms de domaine en adresses IP. Le DNS est tellement omniprésent et fiable que la plupart du temps, vous n’y pensez même pas. Mais quand il y a des problèmes de DNS, tout s'arrête. S'assurer que le DNS fonctionne est essentiel pour les applications modernes, en particulier dans les architectures de microservices où les services sont constamment en rotation.

Dans un article précédent , nous avons parlé de la définition d'enregistrements DNS pour deux sous-domaines qui correspondent à des applications exécutées dans le même cluster ( unit-demo.marketing.net pour l'application Marketing et unit-demo.engineering.net pour l'application Engineering ) et qui se résolvent sur le même point d'entrée du cluster, à savoir l'adresse IP externe du contrôleur d'entrée NGINX du cluster. Le routage SNI (Server Name Indication) est configuré sur NGINX Ingress Controller pour authentifier et acheminer les connexions vers l'application appropriée en fonction du nom de domaine demandé par les utilisateurs.

Mais de nombreuses organisations doivent étendre ce cas d’utilisation et déployer des applications dans plusieurs clusters Kubernetes, qui peuvent être répartis dans plusieurs régions de fournisseurs de cloud. Pour que le trafic externe atteigne de nouvelles régions de cluster, vous devez créer des zones DNS qui résolvent ces régions.

Par le passé, ce processus nécessitait l’utilisation d’un fournisseur tiers (tel que GoDaddy ou DNSExit) pour créer manuellement un registre de domaine et mettre à jour les enregistrements d’hôte de manière appropriée. Désormais, le projet ExternalDNS Kubernetes automatise le processus en rendant les ressources Kubernetes détectables via des serveurs DNS publics. Cela signifie que vous utilisez l'API Kubernetes pour configurer une liste de fournisseurs DNS.

Avec une intégration entre ExternalDNS et NGINX Ingress Controller , vous pouvez gérer les enregistrements DNS A de telle sorte que les noms DNS soient dérivés des noms d'hôtes déclarés dans une ressource Kubernetes Ingress standard ou une ressource personnalisée NGINX VirtualServer . Les développeurs et les équipes DevOps peuvent tirer parti de cette intégration dans leurs pipelines CI/CD pour découvrir automatiquement des applications sur différents clusters, sans impliquer l'équipe NetOps (qui possède généralement le DNS).

Dans cet article, nous montrons comment utiliser des exemples de fichiers de configuration de notre référentiel GitHub pour intégrer ExternalDNS avec NGINX Ingress Controller.

L'architecture de base

Pour implémenter ExternalDNS avec NGINX Ingress Controller, nous commençons par le cas de base où les développeurs configurent un contrôleur Ingress pour exposer en externe les applications Kubernetes. Les clients ne peuvent pas se connecter aux applications tant que le nom de domaine configuré ne correspond pas au point d’entrée public du cluster Kubernetes.

NGINX Ingress Controller interagit avec le fournisseur DNS via le déploiement Kubernetes ExternalDNS intermédiaire, permettant la découverte automatique des applications Kubernetes à l'aide d'enregistrements DNS externes. Dans le diagramme, les lignes noires représentent le chemin de données sur lequel les utilisateurs externes accèdent aux applications du cluster Kubernetes. Les lignes violettes représentent le chemin de contrôle sur lequel les propriétaires d’applications gèrent les enregistrements DNS externes avec les ressources VirtualServer dans la configuration NGINX Ingress Controller et les accès DNS externes au fournisseur DNS.

Intégration d'ExternalDNS et du contrôleur d'entrée NGINX

Effectuez les étapes des sections suivantes pour intégrer ExternalDNS et NGINX Ingress Controller.

• Prérequis
• Déployer NGINX Ingress Controller et ExternalDNS
• Configurer le contrôleur d'entrée NGINX

Prérequis

1. Créez au moins un domaine enregistré. Remplacez son nom par <mon‑domaine> dans les étapes ci-dessous. (Il existe de nombreux articles disponibles sur la façon d'enregistrer un domaine, y compris ce guide de PCMag .)

2. Déployez NGINX Ingress Controller à l’aide de manifestes ou de graphiques Helm . Ajoutez l’équivalent de ces arguments de ligne de commande dans la spécification de déploiement :

   • -enable-external-dns – Active l’intégration avec ExternalDNS.
   • -external-service=nginx-ingress – Indique au contrôleur d’entrée NGINX d’annoncer son point d’entrée public pour l’enregistrement dans les enregistrements A gérés par le fournisseur DNS. Le nom d'hôte du point d'entrée public correspond au service externe nginx-ingress .
3. Si vous déployez le cluster Kubernetes sur site, provisionnez un équilibreur de charge externe. Nous fournissons des instructions pour déployer NGINX en tant qu'équilibreur de charge externe avec BGP dans notre eBook gratuit Get Me to the Cluster . Alternativement, vous pouvez utiliser F5 BIG‑IP ou MetalLB .

4. Si nécessaire, créez une zone DNS chez un fournisseur pris en charge par ExternalDNS . Cette commande est destinée au fournisseur utilisé dans l'exemple de déploiement, Google Cloud DNS.

   $ gcloud dns managed-zones crée "external-dns-<mon-domaine>" --dns-name "dns-externe.<mon-domaine>." --description "Zone gérée automatiquement par ExternalDNS"
   

Déployer NGINX Ingress Controller et ExternalDNS

1. Clonez le référentiel GitHub pour l’exemple de déploiement et déployez NGINX Ingress Controller.

   $ 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
   

2. Mettez à jour les arguments suivants dans la spécification de déploiement ExternalDNS (sur les lignes 59 à 62 dans external-dns-gcloud.yaml pour l'exemple de déploiement) :

   • --filtre-de-domaine – Le nom du domaine créé en Étape 4 de la section précédente (dans l’exemple de déploiement, DNS externe.<mon-domaine>). Supprimez toutes les valeurs existantes afin que seul ce domaine soit utilisé.
   • --provider – Le fournisseur DNS (dans l’exemple de déploiement, google pour Google DNS).
   • --google-project – Le nom du projet Google que vous utilisez pour l'exemple de déploiement (obligatoire uniquement si vous avez plusieurs projets Google).
   • --txt-owner-id – L’ID que vous choisissez (unique pour l’exemple de déploiement).

   Note: Les arguments que vous devez inclure dans la spécification de déploiement ExternalDNS peuvent varier en fonction du fournisseur DNS que vous choisissez. Pour obtenir une liste de didacticiels sur le déploiement d'ExternalDNS sur le cluster avec différents fournisseurs DNS, consultez la documentation ExternalDNS .

3. Déployez ExternalDNS dans le cluster et vérifiez que le déploiement s'exécute correctement (la sortie est répartie sur deux lignes pour plus de lisibilité).

   $ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide NOM ÉTAT PRÊT ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 En cours d'exécution ... ... REDÉMARRE L'ÂGE... 0 1m
   

Configurer le contrôleur d'entrée NGINX

Ensuite, nous configurons une ressource VirtualServer avec une règle d’équilibrage de charge Ingress qui achemine les connexions externes vers nos applications Kubernetes.

1. Dans app-virtual-server.yaml , définissez le champ hôte (ligne 6) :

    6 hôte : ingress.external-dns.<mon-domaine>
   

   Le mappage entre cette valeur et la valeur de domain-filter sur la ligne 59 de external-dns-gcloud.yaml (définie à l'étape 2 de la section précédente) est ce qui permet la mise à jour automatique des enregistrements DNS.

2. Appliquez app-virtual-server.yaml et vérifiez que le VirtualServer est correctement configuré.

   $ kubectl apply -f app-secret.yaml et kubectl apply -f app-virtual-server.yaml
   $ kubectl obtenir contre 
   NOM ÉTAT HÔTE IP 
   cafe Valide ingress.external-dns.<mon-domaine>  34.168.X.Y
   

3. Vérifiez qu'un enregistrement DNS de type A a été ajouté à la zone DNS. En particulier, l’adresse IP dans le champ DATA doit correspondre au champ IP dans la sortie de la commande kubectl get vs à l’étape précédente (l’adresse IP externe du service de type LoadBalancer qui expose NGINX Ingress Controller, ou l’équivalent dans un déploiement sur site).

   $ liste des ensembles d'enregistrements DNS de gcloud --zone external-dns-<mon-domaine> -nom ingress.external-dns.<mon-domaine> --type ANOM TYPE TTL DONNÉES
   ingress.external-dns.<mon-domaine>.  Un 300 34.168. X . Y
   

4. Pour valider que le nom d'hôte VirtualServer peut être résolu sur la machine locale, obtenez les serveurs de noms attribués à la zone DNS (dans ce cas my-ns-domains ).

   $ liste des ensembles d'enregistrements DNS de gcloud --zone external-dns.<mon-domaine> --nom dns-externe.<mon-domaine>. --type NSNOM TYPE TTL DONNÉES
   external-dns.<mon-domaine>.   NS 21600 mes-ns-domaines
   
   $ creuser +court @mes-ns-domaines ingress.external-dns.<mon-domaine>
   34.168.X.Y
   

5. Utilisez les enregistrements DNS récupérés à l’étape précédente comme serveurs de noms dédiés pour votre domaine enregistré. Cela définit votre domaine enregistré comme zone parent de la zone DNS créée à l'étape 4 des Conditions préalables .

6. Vérifiez que vous pouvez accéder au nom d’hôte du serveur virtuel maintenant qu’il est exposé à l’Internet global.

   $ curl -i --insecure https://ingress.external-dns.<mon-domaine>/théHTTP/1.1 200 OK
   Serveur : nginx/1.23.0
   Date : Jour , JJ MM AAAA hh : mm : ss TZ Type de contenu : texte/plain Longueur du contenu : 160 Connexion : keep-alive Expire : Jour , JJ MM AAAA hh : mm : ss TZ Cache-Control : no-cache
   

Mise à l'échelle de plusieurs clusters Kubernetes

Vous pouvez rapidement faire évoluer l'architecture et découvrir automatiquement plusieurs clusters en automatisant la création d'enregistrements DNS externes et en les résolvant en nouveaux points d'entrée de cluster ( Kubernetes Cluster 1 et Kubernetes Cluster 2 ) dans le diagramme. Répétez les instructions dans Déployer NGINX Ingress Controller et ExternalDNS et Configurer NGINX Ingress Controller .

Vous pouvez également utiliser des outils d’infrastructure en tant que code dans votre pipeline CI/CD pour générer et exposer de nouveaux clusters au trafic externe à l’aide d’ExternalDNS et de NGINX Ingress Controller. De plus, vous pouvez gérer plusieurs zones DNS, voire plusieurs fournisseurs DNS, selon la manière dont la découverte est activée.

Conclusion

Il peut être difficile d’équilibrer la productivité avec les mesures de sécurité qui atténuent les violations. Imposer des restrictions aux équipes DevOps provoque souvent des frictions entre elles et les équipes NetOps/SecOps. L’équilibre idéal diffère dans chaque organisation, et NGINX offre la flexibilité nécessaire pour établir un équilibre qui répond à vos priorités et à vos exigences.

Par le passé, les propriétaires d’applications comptaient sur les équipes NetOps pour connecter leurs applications à des systèmes externes. En utilisant l'intégration ExternalDNS avec NGINX, les développeurs et les équipes DevOps sont habilités à déployer eux-mêmes des applications détectables, contribuant ainsi à accélérer la mise sur le marché de l'innovation.

Pour un guide complet sur la mise en route de NGINX dans Kubernetes, téléchargez notre eBook gratuit Gestion du trafic Kubernetes avec F5 NGINX : Un guide pratique .

Vous pouvez également commencer dès aujourd'hui en demandant un essai gratuit de 30 jours de NGINX Ingress Controller avec NGINX App Protect WAF et DoS ou nous contacter pour discuter de vos cas d'utilisation .