Ce document vous aide à déterminer si Cloud DNS pour GKE est la solution DNS adaptée à votre cluster. Vous pouvez utiliser Cloud DNS pour gérer la résolution DNS des pods et des services en remplacement des fournisseurs DNS hébergés par le cluster, comme kube-dns.
Pour les clusters Autopilot, Cloud DNS est déjà le fournisseur DNS par défaut. Pour les clusters standards, vous pouvez passer de kube-dns à Cloud DNS.
Ce document s'adresse aux utilisateurs de GKE, y compris les développeurs, les administrateurs et les architectes. Pour en savoir plus sur les rôles courants et les exemples de tâches dans Google Cloud, consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
Ce document suppose que vous connaissez les concepts suivants :
Fonctionnement de Cloud DNS pour GKE
Lorsque vous utilisez Cloud DNS comme fournisseur DNS pour GKE, Cloud DNS fournit la résolution DNS des pods et des services, sans nécessiter de fournisseur DNS hébergé par le cluster. Les enregistrements DNS des pods et des services sont automatiquement provisionnés dans Cloud DNS pour les services de type "adresse IP de cluster", "sans adresse IP" et "nom externe".
Cloud DNS est compatible avec la spécification DNS de Kubernetes complète et fournit une résolution pour les enregistrements A, AAAA, SRV et PTR pour les services au sein d'un cluster GKE. Les enregistrements PTR sont implémentés à l'aide de règles de stratégie de réponse. L'utilisation de Cloud DNS en tant que fournisseur DNS pour GKE offre les avantages suivants par rapport au DNS hébergé sur un cluster :
- Surcharge réduite : élimine la nécessité de gérer les serveurs DNS hébergés par le cluster. Cloud DNS ne nécessite aucun scaling, surveillance ni gestion manuels des instances DNS, car il s'agit d'un service entièrement géré.
- Évolutivité et performances élevées : résout les requêtes localement pour chaque nœud GKE afin de fournir une résolution DNS à faible latence et hautement évolutive. Pour des performances optimales, en particulier dans les clusters à grande échelle, envisagez d'activer NodeLocal DNSCache, qui fournit une couche de mise en cache supplémentaire sur le nœud.
- Intégration à Google Cloud Observability : permet la surveillance et la journalisation DNS. Pour en savoir plus, consultez Activer et désactiver la journalisation pour les zones gérées privées.
Architecture
Lorsque Cloud DNS est le fournisseur DNS pour GKE, un contrôleur s'exécute en tant que pod géré par GKE. Ce pod s'exécute sur les nœuds du plan de contrôle de votre cluster et synchronise les enregistrements DNS du cluster dans une zone DNS privée gérée.
Le schéma suivant montre comment les plans de contrôle et plan de données Cloud DNS résolvent les noms de cluster:
Dans le schéma, le backend de service sélectionne les pods de backend en cours d'exécution. Le contrôleur clouddns crée un enregistrement DNS pour le backend du service.
Le frontend du pod envoie une requête DNS pour résoudre l'adresse IP du service nommé "backend" au serveur de métadonnées locales Compute Engine à l'adresse 169.254.169.254. Le serveur de métadonnées s'exécute localement sur le nœud, en envoyant des défauts de cache (miss) à Cloud DNS.
Cloud DNS résout le nom du service en différentes adresses IP en fonction du type de service Kubernetes. Pour les services ClusterIP, Cloud DNS résout le nom du service en adresse IP virtuelle. Pour les services sans adresse IP de cluster, il résout le nom du service en liste d'adresses IP de points de terminaison.
Une fois que le frontend du pod a résolu l'adresse IP, il peut envoyer du trafic vers le backend du service et tous les pods derrière le service.
Champs d'application DNS
Cloud DNS dispose des champs d'application DNS suivants. Un cluster ne peut pas fonctionner simultanément dans ces deux modes.
- À l'échelle du cluster GKE : les enregistrements DNS ne peuvent être résolus que dans le cluster, ce qui correspond au comportement de
kube-dns. Seuls les nœuds exécutés dans le cluster GKE peuvent résoudre les noms de services. Par défaut, les clusters ont des noms DNS se terminant par*.cluster.local. Ces noms DNS ne sont visibles que dans le cluster et ne chevauchent pas les noms DNS*.cluster.localdes autres clusters GKE dans le même projet. Il s'agit du mode par défaut.- Champ d'application Cloud DNS additif à l'échelle du VPC : le champ d'application Cloud DNS additif à l'échelle du VPC est une fonctionnalité facultative qui étend le champ d'application du cluster GKE pour permettre la résolution des services sans adresse IP de cluster à partir d'autres ressources du VPC, telles que des VM Compute Engine ou des clients sur site connectés à l'aide de Cloud VPN ou Cloud Interconnect. Ce mode est un mode supplémentaire activé en même temps que le champ d'application du cluster. Vous pouvez activer ou désactiver ce mode dans votre cluster sans affecter le temps d'activité DNS ni les capacités à l'échelle du cluster.
- À l'échelle du VPC : les enregistrements DNS peuvent être résolus sur l'ensemble du VPC. Les VM Compute Engine et les clients sur site peuvent se connecter à l'aide de Cloud Interconnect ou de Cloud VPN, et résoudre directement les noms des services GKE. Vous devez définir un domaine personnalisé unique pour chaque cluster, ce qui signifie que tous les enregistrements DNS de service et de pod sont uniques au sein du VPC. Ce mode réduit les frictions de communication entre les ressources GKE et non-GKE.
Le tableau suivant présente les différences entre les champs d'application DNS :
| Fonctionnalité | Champ d'application à l'échelle du cluster GKE | Champ d'application Cloud DNS additif à l'échelle du VPC | Champ d'application : VPC |
|---|---|---|---|
| Champ d'application de la visibilité DNS | Uniquement au sein du cluster GKE | Cluster uniquement, avec des services sans adresse IP pouvant être résolus sur le réseau VPC | Ensemble du réseau VPC |
| Résolution DNS de service sans adresse IP de cluster | Résolution dans le cluster | Résolution dans le cluster à l'aide du domaine "cluster.local" et dans le VPC à l'aide du suffixe du cluster | Résolution dans le cluster et dans le VPC à l'aide du suffixe de cluster |
| Exigence de domaine unique | Non. Utilise le domaine par défaut "*.cluster.local". | Oui, vous devez définir un domaine personnalisé unique. | Oui, vous devez définir un domaine personnalisé unique. |
| Configurer la configuration | Par défaut, aucune étape supplémentaire | Facultatif à la création du cluster Peut être activé ou désactivé à tout moment |
Doit être configuré lors de la création du cluster |
Ressources Cloud DNS
Lorsque vous utilisez Cloud DNS comme fournisseur DNS pour votre cluster GKE, le contrôleur Cloud DNS crée des ressources dans Cloud DNS pour votre projet. Les ressources créées par GKE dépendent du champ d'application Cloud DNS.
| Champ d'application | Transférer la zone de recherche | Zone de recherche inversée |
|---|---|---|
| Champ d'application : cluster | 1 zone privée par cluster et par zone Compute Engine (dans la région) | 1 zone de stratégie de réponse par cluster par zone Compute Engine (dans la région) |
| Champ d'application Cloud DNS additif à l'échelle du VPC | 1 zone privée par cluster par zone Compute Engine (dans la région) par cluster (zone globale) 1 zone privée à l'échelle d'un VPC par cluster (zone globale) |
1 zone de stratégie de réponse par cluster par zone Compute Engine (dans la région) par cluster (zone globale) 1 zone de stratégie de réponse à l'échelle d'un VPC par cluster (zone globale) |
| Champ d'application : VPC | 1 zone privée par cluster (zone globale) | 1 zone de stratégie de réponse par cluster (zone globale) |
La convention d'attribution de noms utilisée pour ces ressources Cloud DNS est la suivante :
| Champ d'application | Transférer la zone de recherche | Zone de recherche inversée |
|---|---|---|
| Champ d'application : cluster | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-CLUSTER_NAME-CLUSTER_HASH-rp |
| Champ d'application Cloud DNS additif à l'échelle du VPC | gke-CLUSTER_NAME-CLUSTER_HASH-dns
pour les zones à l'échelle d'un cluster
gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc
pour les zones à l'échelle d'un VPC
|
gke-CLUSTER_NAME-CLUSTER_HASH-rp
pour les zones à l'échelle d'un cluster
gke-NETWORK_NAME_HASH-rp pour les zones à l'échelle d'un VPC |
| Champ d'application : VPC | gke-CLUSTER_NAME-CLUSTER_HASH-dns |
gke-NETWORK_NAME_HASH-rp |
Outre les zones mentionnées dans le tableau précédent, le contrôleur Cloud DNS crée les zones suivantes dans votre projet, en fonction de votre configuration :
| Configuration DNS personnalisée | Type de zone | Convention d'attribution de noms aux zones |
|---|---|---|
| Domaine de simulation | Transfert (zone globale) | gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH |
| Serveurs de noms en amont personnalisés | Transfert (zone globale) | gke-CLUSTER_NAME-CLUSTER_HASH-upstream |
Pour savoir comment créer des domaines de simulation ou des serveurs de noms personnalisés en amont, consultez Ajouter des résolveurs personnalisés pour les domaines de simulation.
Zones gérées et zones de transfert
Pour les clusters qui utilisent la portée du cluster pour gérer le trafic DNS interne, le contrôleur Cloud DNS crée une zone DNS gérée dans chaque zone Compute Engine de la région à laquelle appartient le cluster.
Par exemple, si vous déployez un cluster dans la zone us-central1-c, le contrôleur Cloud DNS crée une zone gérée dans us-central1-a, us-central1-b, us-central1-c et us-central1-f.
Pour chaque stubDomain DNS, le contrôleur Cloud DNS crée une zone de transfert.
Cloud DNS traite chaque DNS en amont à l'aide d'une zone gérée avec le nom DNS ..
Quotas
Cloud DNS utilise des quotas pour limiter le nombre de ressources que GKE peut créer pour les entrées DNS. Les quotas et limites pour Cloud DNS peuvent être différents des limites de kube-dns pour votre projet.
Les quotas par défaut suivants sont appliqués à chaque zone gérée de votre projet lorsque vous utilisez Cloud DNS pour GKE :
| Ressource DNS Kubernetes | Ressource Cloud DNS correspondante | Quota |
|---|---|---|
| Nombre d'enregistrements DNS | Nombre maximal d'octets par zone gérée | 2 000 000 (50 Mo maximum pour une zone gérée) |
| Nombre de pods par service sans adresse IP de cluster (IPv4 ou IPv6) | Nombre d'enregistrements par jeu d'enregistrements de ressources | GKE 1.24 à 1.25 : 1 000 (IPv4 ou IPv6) GKE 1.26 et versions ultérieures : 3 500 pour IPv4 ; 2 000 pour IPv6 |
| Nombre de clusters GKE dans un projet | Nombre de stratégies de réponse par projet | 100 |
| Nombre d'enregistrements PTR par cluster | Nombre de règles par stratégie de réponse | 100 000 |
Limites de ressources
Les ressources Kubernetes que vous créez par cluster contribuent aux limites de ressources Cloud DNS, comme décrit dans le tableau suivant :
| Limite | Contribution à la limite |
|---|---|
| Jeux d'enregistrements de ressources par zone gérée | Nombre de services et nombre de points de terminaison de service sans adresse IP de cluster avec des noms d'hôte valides, par cluster. |
| Enregistrements par jeu d'enregistrements de ressources | Nombre de points de terminaison par service sans adresse IP de cluster. Sans incidence sur les autres types de services. |
| Nombre de règles par stratégie de réponse | Pour le champ d'application à l'échelle du cluster, nombre de services et nombre de points de terminaison de service sans adresse IP de cluster avec des noms d'hôte valides, par cluster. Pour le champ d'application à l'échelle du VPC, nombre de services et nombre de points de terminaison sans adresse IP de cluster avec les noms d'hôte de tous les clusters du VPC. |
Pour en savoir plus sur la création d'enregistrements DNS pour Kubernetes, consultez la page Découverte des services basée sur DNS de Kubernetes.
Plusieurs clusters par projet de service
À partir des versions 1.22.3-gke.700 et 1.21.6-gke.1500 de GKE, vous pouvez créer des clusters dans plusieurs projets de service faisant référence à un VPC dans le même projet hôte.
Compatibilité avec les domaines de simulation personnalisés et les serveurs de noms en amont
Cloud DNS pour GKE est compatible avec les domaines de simulation personnalisés et les serveurs de noms en amont configurés à l'aide de ConfigMap de kube-dns. Cette compatibilité n'est disponible que pour les clusters GKE Standard.
Cloud DNS traduit les valeurs stubDomains et upstreamNameservers en zones de transfert Cloud DNS.
Extensions de spécification
Pour améliorer la détection de services et la compatibilité avec différents clients et systèmes, vous pouvez utiliser des ajouts en plus de la spécification DNS Kubernetes générale.
Ports nommés
Cette section explique comment les ports nommés affectent les enregistrements DNS créés par Cloud DNS pour votre cluster Kubernetes. Kubernetes définit un ensemble minimal d'enregistrements DNS requis, mais Cloud DNS peut créer des enregistrements supplémentaires pour son propre fonctionnement et pour prendre en charge diverses fonctionnalités Kubernetes. Les tableaux suivants illustrent le nombre minimal d'ensembles d'enregistrements auxquels vous pouvez vous attendre, où "E" représente le nombre de points de terminaison et "P" représente le nombre de ports.
Cloud DNS peut créer des enregistrements supplémentaires.
| Type de pile d'adresses IP | Type de service | Jeux d'enregistrements |
|---|---|---|
| Pile unique | ClusterIP | $$2+P$$ |
| Headless | $$2+P+2E$$ |
|
| double pile | ClusterIP | $$3+P$$ |
| Headless | $$3+P+3E$$ |
|
| Pour en savoir plus sur les services à pile unique et à double pile, consultez Services à pile unique et à double pile. | ||
Enregistrements DNS supplémentaires créés par Cloud DNS
Cloud DNS peut créer des enregistrements DNS supplémentaires au-delà du nombre minimal d'ensembles d'enregistrements. Ces enregistrements ont plusieurs objectifs, y compris les suivants :
- Enregistrements SRV : pour la détection de services, Cloud DNS crée souvent des enregistrements SRV. Ces enregistrements fournissent des informations sur le port et le protocole du service.
- Enregistrements AAAA (pour la double pile) : dans les configurations à double pile qui utilisent à la fois IPv4 et IPv6, Cloud DNS crée des enregistrements A (pour IPv4) et AAAA (pour IPv6) pour chaque point de terminaison.
- Enregistrements internes : Cloud DNS peut créer des enregistrements internes pour sa propre gestion et optimisation. Ces enregistrements ne sont généralement pas directement pertinents pour les utilisateurs.
- Services LoadBalancer : pour les services de type
LoadBalancer, Cloud DNS crée des enregistrements associés à l'adresse IP de l'équilibreur de charge externe. - Services sans adresse IP de cluster : les services sans adresse IP de cluster ont une configuration DNS distincte. Chaque pod reçoit son propre enregistrement DNS, ce qui permet aux clients de se connecter directement aux pods. C'est pourquoi le numéro de port n'est pas multiplié dans le calcul des enregistrements de service sans adresse IP de cluster.
Exemple : Prenons l'exemple d'un service appelé my-http-server et situé dans l'espace de noms backend. Ce service expose deux ports, 80 et 8080, pour un déploiement avec trois pods. Par conséquent, E = 3 et P = 2.
| Type de pile d'adresses IP | Type de service | Jeux d'enregistrements |
|---|---|---|
| Pile unique | ClusterIP | $$2+2$$ |
| Headless | $$2+2+2*3$$ |
|
| double pile | ClusterIP | $$3+2$$ |
| Headless | $$3+2+3*3$$ |
En plus de ces enregistrements minimaux, Cloud DNS peut créer des enregistrements SRV et, dans le cas d'un réseau à double pile, des enregistrements AAAA. Si my-http-server est un service de type LoadBalancer, des enregistrements supplémentaires sont créés pour l'adresse IP de l'équilibreur de charge. Remarque : Cloud DNS ajoute des enregistrements DNS supplémentaires si nécessaire. Les enregistrements spécifiques qui sont créés dépendent de facteurs tels que le type de service et la configuration.
Problèmes connus
Cette section décrit les problèmes courants que vous pouvez rencontrer lorsque vous utilisez Cloud DNS avec GKE, ainsi que les solutions de contournement potentielles.
Terraform tente de recréer un cluster Autopilot en raison d'une modification de dns_config
Si vous utilisez terraform-provider-google ou terraform-provider-google-beta, il se peut que Terraform tente de recréer un cluster Autopilot. Cette erreur se produit car les clusters Autopilot nouvellement créés qui exécutent les versions 1.25.9-gke.400, 1.26.4-gke.500, 1.27.1-gke.400 ou ultérieures utilisent Cloud DNS en tant que fournisseur DNS au lieu de kube-dns.
Ce problème est résolu dans la version 4.80.0 du fournisseur Terraform de Google Cloud.
Si vous ne pouvez pas mettre à jour la version de terraform-provider-google ou terraform-provider-google-beta, vous pouvez ajouter le paramètre lifecycle.ignore_changes à la ressource pour vous assurer que google_container_cluster ignore les modifications apportées à dns_config :
lifecycle {
ignore_changes = [
dns_config,
]
}
La résolution DNS échoue après la migration de kube-dns vers Cloud DNS avec NodeLocal DNSCache activé
Cette section décrit un problème connu pour les clusters GKE qui se trouvent dans Cloud DNS et pour lesquels NodeLocal DNSCache est activé au niveau du cluster.
Lorsque NodeLocal DNSCache est activé sur le cluster et que vous migrez de kube-dns vers Cloud DNS, votre cluster peut rencontrer des erreurs de résolution intermittentes.
Si vous utilisez kube-dns avec NodeLocal DNSCache activé sur le cluster, NodeLocal DNSCache est configuré pour écouter les deux adresses : l'adresse NodeLocal DNSCache et l'adresse kube-dns.
Pour vérifier l'état de NodeLocal DNSCache, exécutez la commande suivante :
kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind
Le résultat ressemble à ce qui suit :
bind 169.254.20.10 x.x.x.10
bind 169.254.20.10 x.x.x.10
Si GKE Dataplane V2 est activé sur le cluster et que celui-ci utilise kube-dns, NodeLocal DNSCache s'exécute dans un réseau isolé et est configuré pour écouter toutes les adresses IP des pods (0.0.0.0). Le résultat ressemble à ce qui suit :
bind 0.0.0.0
bind 0.0.0.0
Une fois le cluster mis à jour vers Cloud DNS, la configuration NodeLocal DNSCache est modifiée. Pour vérifier la configuration de NodeLocal DNSCache, exécutez la commande suivante :
kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind
Le résultat ressemble à ce qui suit :
bind 169.254.20.10
bind 169.254.20.10
Le workflow suivant explique les entrées du fichier resolv.conf avant et après la migration et la recréation des nœuds :
Avant la migration
- Le fichier
resolv.confdes pods est configuré sur l'adresse IPkube-dns(par exemple,x.x.x.10). - Les pods NodeLocal DNSCache interceptent les requêtes DNS des pods et écoutent les éléments suivants :
- (DPv1) les deux adresses (bind 169.254.20.10 x.x.x.10).
- (DPv2) toutes les adresses IP de pods (liaison 0.0.0.0).
- NodeLocal DNSCache fonctionne comme un cache et la charge minimale est placée sur les pods
kube-dns.
Après la migration
- Une fois le plan de contrôle mis à jour pour utiliser Cloud DNS, les pods conservent le fichier
resolv.confconfiguré sur l'adresse IPkube-dns(par exemple,x.x.x.10). Les pods conservent cette configurationresolv.confjusqu'à ce que leur nœud soit recréé. Lorsque Cloud DNS avec NodeLocal DNSCache est activé, les pods doivent être configurés pour utiliser169.254.20.10comme serveur de noms. Toutefois, cette modification ne s'applique qu'aux pods sur les nœuds qui ont été créés ou recréés après la migration vers Cloud DNS. - Les pods NodeLocal DNSCache écoutent uniquement l'adresse NodeLocal DNSCache (bind 169.254.20.10). Les requêtes ne sont pas envoyées aux pods NodeLocal DNSCache.
- Toutes les requêtes des pods sont directement envoyées aux pods
kube-dns. Cette configuration génère un trafic élevé sur les pods.
Après la recréation d'un nœud ou la mise à niveau d'un pool de nœuds
- Le fichier
resolv.confdes pods est configuré pour utiliser l'adresse IP NodeLocal DNSCache (169.254.20.10). - Les pods NodeLocal DNSCache écoutent uniquement l'adresse NodeLocal DNSCache (bind 169.254.20.10) et reçoivent les requêtes DNS des pods sur cette adresse IP.
Lorsque les pools de nœuds utilisent l'adresse IP kube-dns dans le fichier resolv.conf avant la recréation du pool de nœuds, une augmentation du trafic de requêtes DNS entraîne également une augmentation du trafic sur les pods kube-dns. Cette augmentation peut entraîner des échecs intermittents des requêtes DNS. Pour minimiser les erreurs, vous devez planifier cette migration pendant les périodes d'indisponibilité.
Étapes suivantes
- Configurez Cloud DNS pour GKE.
- Utiliser NodeLocal DNSCache dans GKE
- Résolvez les problèmes liés au DNS GKE.