Automatiser le DNS multicluster avec NGINX Ingress Controller

Amir RawdatIngénieur solutions

Les applications ne peuvent pas remplir leur rôle si les utilisateurs ne parviennent pas à les trouver. Le système de noms de domaine (DNS) est la technologie Internet qui permet de « trouver » les applications et les sites web en traduisant les noms de domaine en adresses IP. Le DNS est si omniprésent et fiable que, la plupart du temps, on n’y pense même pas. Mais dès qu’un problème DNS survient, tout s’arrête. Il est essentiel de garantir le bon fonctionnement du DNS pour les applications modernes, en particulier dans les architectures de microservices où les services sont constamment lancés et arrêtés.

Dans un article précédent, nous avons expliqué comment définir des enregistrements DNS pour deux sous-domaines correspondant à 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 pointant vers le même point d’entrée du cluster, à savoir l’adresse IP externe du contrôleur Ingress NGINX du cluster. Le routage par indication du nom du serveur (SNI) est configuré sur le contrôleur Ingress NGINX afin d’authentifier et d’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’usage et déployer des applications dans plusieurs clusters Kubernetes, qui peuvent être répartis entre différentes régions d’un fournisseur de cloud. Pour que le trafic externe puisse atteindre les nouvelles régions des clusters, vous devez créer des zones DNS qui pointent vers ces régions.

Auparavant, ce processus nécessitait de faire appel à un fournisseur tiers (tel que GoDaddy ou DNSExit) pour créer manuellement un registre de domaine et mettre à jour les enregistrements d’hôtes de manière appropriée. Désormais, le projet Kubernetes ExternalDNS automatise ce processus en rendant les ressources Kubernetes détectables via des serveurs DNS publics. Vous pouvez ainsi utiliser l’API Kubernetes pour configurer une liste de fournisseurs DNS.

Grâce à l’intégration entre ExternalDNS et NGINX Ingress Controller, vous pouvez gérer les enregistrements DNS A de sorte que les noms DNS soient dérivés des noms d’hôte déclarés dans une ressource Ingress Kubernetes standard ou dans une ressource personnalisée NGINX VirtualServer. Les équipes de développement et DevOps peuvent exploiter cette intégration dans leurs pipelines CI/CD afin de détecter automatiquement les applications dans différents clusters, sans faire intervenir l’équipe NetOps (qui gère généralement le DNS).

Dans cet article, nous vous montrons comment utiliser les exemples de fichiers de configuration disponibles dans notre dépôt GitHub pour intégrer ExternalDNS à NGINX Ingress Controller.

L’architecture de base

Pour mettre en œuvre ExternalDNS avec NGINX Ingress Controller, nous partons du cas de base dans lequel les développeurs configurent un contrôleur Ingress afin d’exposer les applications Kubernetes à l’extérieur. Les clients ne peuvent pas se connecter aux applications tant que le nom de domaine configuré ne pointe pas vers le point d’entrée public du cluster Kubernetes.

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

Intégration d’ExternalDNS et de NGINX Ingress Controller

Suivez les étapes décrites dans les sections suivantes pour intégrer ExternalDNS et NGINX Ingress Controller.

• Prérequis
• Déployer le contrôleur Ingress NGINX et ExternalDNS
• Configurer le contrôleur Ingress NGINX

Prérequis

1. Créez au moins un nom de domaine enregistré. Remplacez <my‑domain> par son nom dans les étapes ci-dessous. (De nombreux articles expliquent comment enregistrer un nom de domaine, notamment ce guide de PCMag.)
2. Déployez NGINX Ingress Controller à l’aide de manifestes ou de charts 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 à NGINX Ingress Controller de publier son point d’entrée public afin qu’il soit enregistré dans les enregistrements A gérés par le fournisseur DNS. Le nom d’hôte du point d’entrée public est résolu vers le service externe nginx-ingress.
3. Si vous déployez le cluster Kubernetes sur site, provisionnez un équilibreur de charge externe. Notre e-book gratuit Get Me to the Cluster explique comment déployer NGINX en tant qu’équilibreur de charge externe avec BGP. Vous pouvez également utiliser F5 BIG‑IP ou MetalLB.
4. Si nécessaire, créez une zone DNS auprès d’un fournisseur pris en charge par ExternalDNS. Cette commande concerne le fournisseur utilisé dans l’exemple de déploiement, Google Cloud DNS.

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

Déployer le contrôleur Ingress NGINX et ExternalDNS

1. Clonez le dépôt GitHub pour l’exemple de déploiement, puis 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

1. Mettez à jour les arguments suivants dans la spécification de déploiement d’ExternalDNS (aux lignes 59 à 62 du fichier external-dns-gcloud.yaml pour l’exemple de déploiement) : Remarque : les arguments à inclure dans la spécification de déploiement d’ExternalDNS peuvent varier selon le fournisseur DNS choisi. Pour obtenir une liste de tutoriels expliquant comment déployer ExternalDNS sur le cluster avec différents fournisseurs DNS, consultez la documentation d’ExternalDNS.
   • --domain-filter – Le nom du domaine créé à l’étape 4 de la section précédente (dans l’exemple de déploiement, external-dns.<my-domain>). 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 (requis uniquement si vous disposez de plusieurs projets Google).
   • --txt-owner-id – L’identifiant de votre choix (propre au déploiement d’exemple).
2. 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 en faciliter la lecture).

$ 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

Configurer le contrôleur Ingress 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 host (ligne 6) :

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

1. La correspondance entre cette valeur et celle de domain-filter à la ligne 59 du fichier external-dns-gcloud.yaml (définie à l’étape 2 de la section précédente) 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 && 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. Vérifiez qu’un enregistrement DNS de type « A » a été ajouté à la zone DNS. En particulier, l’adresse IP du champ « DATA » doit correspondre au champ « IP » dans la sortie de la commande kubectl get vs de l’étape précédente (l’adresse IP externe du service de type « LoadBalancer » qui expose NGINX Ingress Controller, ou son équivalent dans un déploiement sur site).

$ 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. Pour vérifier que le nom d’hôte du VirtualServer peut être résolu sur la machine locale, récupérez les serveurs de noms attribués à la zone DNS (dans ce cas, « 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. Utilisez les enregistrements DNS récupérés à l’étape précédente comme serveurs de noms dédiés pour votre domaine enregistré. Votre domaine enregistré devient ainsi la zone parente de la zone DNS créée à l’étape 4 de la section « Prérequis ».
2. Vérifiez que vous pouvez accéder au nom d’hôte du VirtualServer maintenant qu’il est exposé à l’Internet mondial.

$ 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

Mise à l’échelle de plusieurs clusters Kubernetes

Vous pouvez rapidement faire évoluer l’architecture et détecter automatiquement plusieurs clusters en automatisant la création d’enregistrements DNS externes et leur résolution vers les nouveaux points d’entrée des clusters (Cluster Kubernetes 1 et Cluster Kubernetes 2) dans le schéma. Répétez les instructions des sections « 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 créer de nouveaux clusters et les exposer au trafic externe à l’aide d’ExternalDNS et de NGINX Ingress Controller. Vous pouvez en outre gérer plusieurs zones DNS, voire plusieurs fournisseurs DNS, selon la manière dont la découverte est activée.

Conclusion

Trouver un équilibre entre la productivité et les mesures de sécurité visant à limiter les failles peut s’avérer difficile. Imposer des restrictions aux équipes DevOps crée souvent des tensions avec les équipes NetOps/SecOps. L’équilibre idéal varie d’une organisation à l’autre, et NGINX offre la flexibilité nécessaire pour établir un équilibre conforme à vos priorités et à vos exigences.

Auparavant, les responsables d’applications s’appuyaient sur les équipes NetOps pour connecter leurs applications à des systèmes externes. Grâce à l’intégration d’ExternalDNS avec NGINX, les développeurs et les équipes DevOps peuvent déployer eux-mêmes des applications détectables, ce qui contribue à accélérer la mise sur le marché des innovations.

Pour consulter un guide complet sur la prise en main de NGINX dans Kubernetes, téléchargez gratuitement notre livre numérique « Gestion du trafic Kubernetes avec F5 NGINX : 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 la protection contre les attaques DoS, ou en choisissant de nous contacter pour discuter de vos cas d’utilisation.

À propos de l’auteur

Amir RawdatIngénieur solutions

Autres articles de Amir Rawdat