Réconciliation DNS entre Active Directory et Kubernetes dans les déploiements de clusters Big Data

Cet article décrit certains des défis et des solutions permettant de prendre en charge l’intégration d’Active Directory lors du déploiement de clusters Big Data.

Overview

Lorsque le cluster Big Data n’est pas déployé avec l’intégration d’Active Directory, nous nous appuyons sur le service Kubernetes CoreDNS pour les résolutions DNS internes. Kubernetes utilise un domaine interne tel que <namespace>.svc.cluster.local. Il crée des enregistrements A (recherche vers l’avant) et PTR (recherche inversée) dans le serveur DNS avec des noms dans ce domaine.

Toutefois, lorsque le mode Active Directory est activé, un nouveau domaine entre dans l’image avec son propre ensemble de serveurs DNS. Pendant la résolution de noms interne, cela peut entraîner une confusion quant aux serveurs DNS à utiliser pour les recherches directes et inverses.

Challenges

• Lorsque de nouveaux pods Kubernetes sont déployés, les entrées DNS doivent être ajoutées dans les deux ensembles de serveurs DNS. Kubernetes s’occupe de l’enregistrement des entrées dans son coreDNS. Toutefois, le flux de travail de déploiement BDC est chargé d’ajouter les entrées requises dans les serveurs DNS du contrôleur de domaine Active Directory. De même, lorsqu’un cluster Big Data est supprimé, le workflow doit s’assurer que ces entrées sont supprimées.
• Les serveurs DNS Active Directory sont externes au cluster Kubernetes. Toutefois, BDC possède son propre espace IP à l’intérieur de Kubernetes et ne peut pas créer d’enregistrements pour cet espace IP dans un serveur DNS situé en externe, car cet espace IP n’est pas visible en dehors des limites du cluster.
• Lorsque des événements de basculement se produisent dans le cluster Kubernetes, les enregistrements dans les serveurs DNS AD doivent également être mis à jour.
• En plus des noms de pods, les noms de service Kubernetes doivent également être adressables via les recherches de noms de domaine AD. Cela crée un défi supplémentaire dans le DNS Active Directory, car un nom de service peut être mappé à plusieurs adresses IP de pod.
• La propagation et les retards de réplication des mises à jour d’enregistrement dans les serveurs DNS Active Directory organisationnels peuvent être significatifs et au-delà du contrôle des flux de travail de gestion BDC. Cela peut affecter la fonctionnalité BDC immédiatement au moment du déploiement et du basculement. Au contraire, Kubernetes CoreDNS est plus rapide et efficace en raison de sa localité.

Solution

Pour contourner les défis mentionnés précédemment, la solution implémentée dans BDC implique un nouveau service CoreDNS interne géré dans l’espace de noms BDC. Il s’agit du seul service DNS auquel les pods de l’espace de noms BDC sont accessibles pour les résolutions de noms. La complexité de plusieurs domaines est masquée derrière le nouveau service CoreDNS.

Par exemple, dans le diagramme suivant, les pods utilisent le serveur BDC CoreDNS pour résoudre les noms. Les pods n’interagissent pas directement avec le serveur Kubernetes CoreDNS ou le serveur DNS AD.

Voici quelques-uns des détails de l’implémentation qui précisent le fonctionnement de cette conception dans BDC :

Gestion centralisée de plusieurs domaines

La complexité de ce qui se passe sur les recherches de noms reste cachée derrière le service DNS interne de manière centralisée. Cela évite de charger la gestion de plusieurs domaines sur des pods individuels et simplifie la conception.

Aucun enregistrement pour les pods internes dans des serveurs DNS externes

En conséquence de ce principe de conception, BDC n’a pas besoin de créer et de gérer des enregistrements A et PTR pour les pods dans l’espace IP Kubernetes dans des serveurs DNS externes.

Aucune duplication d’enregistrements

Enregistrements DNS internes dans plusieurs emplacements. Le seul stockage pour ces enregistrements est Kubernetes CoreDNS. Le CoreDNS interne BDC effectue une réécriture et un transfert de calcul des requêtes DNS vers Kubernetes CoreDNS.

Computational rewriting

Étant donné que BDC ne stocke pas d’enregistrements, BDC est responsable de la traduction des requêtes de recherche vers l’avant entrantes avec des noms ayant un domaine AD vers les noms avec le domaine Kubernetes et transfère cette requête à Kubernetes CoreDNS. Par exemple, une requête compute-0-0.contoso.local entrante serait réécrite compute-0-0.compute-0-svc.contoso.svc.cluster.local et cette requête serait transférée vers Kubernetes CoreDNS. En cas de recherche inversée, la requête est transférée telle quelle, avec les adresses IP internes, vers Kubernetes CoreDNS. Ensuite, la réponse est réécrite en utilisant le nom de domaine AD avant d'être renvoyée au client.

Simplicité dans les configurations de pods

Étant donné que seul le COREDNS BDC interne est référencé dans /etc/resolv.conf de tous les pods BDC, cela simplifie l’affichage réseau des pods. La complexité sera masquée dans le CoreDNS interne à la place.

Adresse IP statique et fiable pour le service DNS

Le service CoreDNS déployé par BDC a enregistré une adresse IP interne statique accessible à partir de tous les pods. Cela garantit que les valeurs dans /etc/resolv.conf ne doivent pas être mises à jour.

La gestion de l’équilibre de charge du service est conservée par Kubernetes

Lorsque des recherches se produisent pour les services au lieu de pods individuels, elles vont toujours à Kubernetes CoreDNS, de sorte que BDC n’est pas responsable de l’implémentation de l’équilibrage de charge spécialement pour le domaine AD.

Par exemple, si une requête de recherche directe arrive pour compute-0-svc.contoso.local, elle sera réécrite en compute-0-svc.contoso.svc.cluster.local. Cette requête est transférée à Kubernetes CoreDNS et l’équilibrage de charge se produit là-bas. Une réponse est une adresse IP pour l’une des plusieurs instances de pool de calcul (réplicas de pod).

Scalability

Étant donné que BDC ne stocke pas d'enregistrements, le CoreDNS interne de BDC peut être mis à l'échelle sans conservation d'état ni réplication d'enregistrements sur plusieurs réplicas. Si les enregistrements DNS sont stockés dans BDC, la réplication de l’état sur tous les pods doit également être prise en charge par BDC.

Les entrées de service visibles en externe restent dans AD DNS

Pour les points de terminaison de service qui doivent être accessibles aux clients en dehors du cluster Kubernetes, les entrées DNS sont créées dans le serveur DNS AD au fur et à mesure que BDC est déployé. L’utilisateur entre les noms DNS à inscrire via les profils de configuration de déploiement.

Self-deprovisioning

Une fois bdc supprimé, il n’existe aucun travail dynamique supplémentaire pour supprimer les entrées DNS lorsque le cluster est déprovisionné. Les seules entrées dans le DNS Active Directory distant qui doivent être nettoyées sont destinées aux services externes et sont statiques en nombre. Les entrées DNS internes seront automatiquement supprimées avec le cluster.

Next steps

• Déploiement de clusters Big Data SQL Server en mode Active Directory
• Gestion de l’accès à un cluster Big Data en mode Active Directory
• Déployer plusieurs clusters Big Data SQL Server dans le même domaine Active Directory