Utiliser Cloud DNS pour GKE

Cette page explique comment utiliser Cloud DNS en tant que fournisseur DNS Kubernetes pour Google Kubernetes Engine (GKE).

L'utilisation de Cloud DNS en tant que fournisseur DNS ne permet pas aux clients situés à l'extérieur d'un cluster de résoudre et d'atteindre directement les services Kubernetes. Vous devez toujours exposer les services en externe à l'aide d'un équilibreur de charge et enregistrer leurs adresses IP externes de cluster sur votre infrastructure DNS.

Pour en savoir plus sur l'utilisation de kube-dns en tant que fournisseur DNS, consultez la section Détection de services et DNS.

Pour apprendre à utiliser une version personnalisée de kube-dns ou un fournisseur DNS personnalisé, consultez la page Configurer un déploiement kube-dns personnalisé.

Fonctionnement de Cloud DNS pour GKE

Cloud DNS peut être utilisé comme fournisseur DNS pour GKE. Il fournit la résolution DNS du pod et du service avec un DNS géré qui ne nécessite pas 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 mis en œuvre à l'aide de règles de stratégie de réponse.

L'utilisation de Cloud DNS en tant que fournisseur DNS pour GKE offre de nombreux avantages par rapport au DNS hébergé sur un cluster :

• Suppression de la surcharge liée à la gestion du serveur DNS hébergé par le cluster. Cloud DNS ne nécessite aucun scaling, surveillance ni gestion des instances DNS, car il s'agit d'un service entièrement géré, hébergé dans l'infrastructure Google hautement évolutive.
• Résolution locale des requêtes DNS sur chaque nœud GKE. Semblable à NodeLocal DNSCache, Cloud DNS met en cache les réponses DNS localement, offrant ainsi une résolution DNS à faible latence et haute évolutivité.

• Intégration à Google Cloud Observability pour la surveillance et la journalisation DNS. Pour plus d'informations, consultez la section 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é 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 service backend sélectionne les pods backend en cours d'exécution. Le fichier clouddns-controller crée un enregistrement DNS pour le service backend.

Le pod frontend envoie une requête DNS pour résoudre l'adresse IP du service nommé backend au serveur de métadonnées locales Compute Engine à 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.

Le plan de données Cloud DNS s'exécute localement dans chaque nœud GKE ou instance de machine virtuelle (VM) Compute Engine. Selon le type de service Kubernetes, Cloud DNS résout le nom du service en adresse IP virtuelle, pour les services IP de cluster, ou sur la liste des adresses IP de points de terminaison, pour les services sans adresse IP de cluster.

Une fois que le pod frontend a résolu l'adresse IP, il peut envoyer du trafic vers le service backend 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.local des 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. Le champ d'application additif à l'échelle du VPC est un mode supplémentaire activé en même temps que le champ d'application du cluster, que vous pouvez activer ou désactiver dans votre cluster sans affecter le temps d'activité ou les capacités DNS (champ d'application 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 :

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.

La convention d'attribution de noms utilisée pour ces ressources Cloud DNS est la suivante :

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 :

Pour savoir comment créer des domaines de simulation ou des serveurs de noms personnalisés en amont, consultez la section Ajouter des résolveurs personnalisés pour les domaines de simulation.

Zones gérées et zones de transfert

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 ..

Tarifs

Lorsque Cloud DNS est le fournisseur DNS pour les clusters GKE Standard, les requêtes DNS des pods du cluster GKE sont facturées selon la tarification Cloud DNS.

Les requêtes adressées à une zone DNS à l'échelle d'un VPC gérée par GKE sont facturées selon la tarification Cloud DNS standard.

Conditions requises

L'API Cloud DNS doit être activée dans votre projet.

Le champ d'application à l'échelle du cluster est soumis aux exigences suivantes dans Cloud DNS pour GKE :

• Pour l'environnement standard, GKE 1.24.7-gke.800, 1.25.3-gke.700 ou version ultérieure.

• Pour Autopilot, GKE 1.25.9-gke.400, 1.26.4-gke.500 version ou ultérieure.
• Google Cloud CLI version 411.0.0 ou ultérieure.

Le champ d'application additif à l'échelle du VPC est soumis aux exigences suivantes dans Cloud DNS pour GKE :

• Pour l'environnement standard, GKE 1.24.7-gke.800, 1.25.3-gke.700 ou version ultérieure.

• Pour Autopilot, la version 1.28 de GKE ou une version ultérieure.
• Google Cloud CLI version 471.0.0.
• Le cluster GKE doit utiliser le champ d'application du cluster Cloud DNS comme fournisseur DNS par défaut.

Le champ d'application à l'échelle du VPC est soumis aux exigences suivantes dans Cloud DNS pour GKE :

• Pour l'environnement standard, GKE version 1.19 ou ultérieure.
• Google Cloud CLI version 364.0.0 ou ultérieure.
• L'API Cloud DNS doit être activée dans votre projet.

Restrictions et limitations

Les limites suivantes s'appliquent :

• Le champ d'application à l'échelle du VPC n'est pas compatible avec les clusters Autopilot. Seul le champ d'application à l'échelle du cluster est compatible. Si vous devez résoudre les noms de services sans adresse IP de cluster exécutés dans des clusters GKE Autopilot, vous devez utiliser le champ d'application additif à l'échelle du VPC.

• Cloud DNS n'est pas conforme à un régime de conformité de niveau d'impact 4 (IL4). Cloud DNS pour GKE ne peut pas être utilisé dans une charge de travail Assured Workloads avec un régime de conformité IL4. Vous devez utiliser kube-dns dans ce type d'environnement réglementé. Pour les clusters GKE Autopilot, la sélection de kube-dns ou Cloud DNS est effectuée automatiquement en fonction de votre régime de conformité.
• Les modifications manuelles des zones DNS privées gérées ne sont pas acceptées et sont écrasées par le contrôleur Cloud DNS. Les modifications apportées aux enregistrements DNS dans ces zones ne persistent pas lorsque le contrôleur redémarre.

• Une fois que vous avez activé Cloud DNS pour GKE dans un cluster, kube-dns continue de s'exécuter dans le cluster. Vous pouvez désactiver kube-dns en procédant à un scaling du déploiement kube-dns et de l'autoscaler à zéro.

• Vous ne pouvez pas modifier le champ d'application DNS dans un cluster après l'avoir défini avec l'option --cluster-dns-scope. Si vous devez modifier le champ d'application DNS, recréez le cluster avec un champ d'application DNS différent.

• Les domaines de simulation personnalisés et les configurations de serveur DNS en amont s'appliquent aux configurations DNS des pods et des nœuds. Les pods utilisant des réseaux ou des processus hôte qui s'exécutent directement sur l'hôte utilisent également le domaine de simulation et les configurations de serveur de noms en amont. Cette fonctionnalité n'est disponible que dans l'édition Standard.
• Les domaines de simulation personnalisés et les serveurs de noms en amont configurés via ConfigMap de kube-dns sont automatiquement appliqués à Cloud DNS pour le DNS à l'échelle du cluster. Le DNS à l'échelle du VPC ignore le fichier ConfigMap de kube-dns et vous devez appliquer ces configurations directement sur Cloud DNS. Cette fonctionnalité n'est disponible que dans l'édition Standard.

• Il n'existe pas de chemin de migration de kube-dns vers le champ d'application à l'échelle du VPC, l'opération occasionne une interruption. Recréez le cluster lorsque vous passez de kube-dns à un champ d'application VPC, ou inversement.
• Pour le champ d'application à l'échelle du VPC, la plage d'adresses IP secondaire utilisée par les services ne doit pas être partagée avec d'autres clusters de ce sous-réseau.
• Pour le champ d'application à l'échelle du VPC, la stratégie de réponse associée à un enregistrement PTR est associée au réseau VPC. Si d'autres stratégies de réponse sont liées au réseau du cluster, la résolution des enregistrements PTR échoue pour les adresses IP du service Kubernetes.

• Si vous essayez de créer un service sans adresse IP de cluster avec un nombre de pods dépassant le quota autorisé, Cloud DNS ne crée pas de jeux d'enregistrements ni d'enregistrements pour le service.

Quotas

Cloud DNS utilise des quotas pour limiter le nombre de ressources que GKE peut créer pour les entrées DNS. Des 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 :

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 :

Pour en savoir plus sur la création d'enregistrements DNS pour Kubernetes, consultez la page Détection de services basée sur DNS de Kubernetes.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

• Activez l'API Cloud DNS dans votre projet.

  Activer l'API Cloud DNS

Activer le DNS à l'échelle du cluster

Dans le DNS à l'échelle d'un cluster, seuls les nœuds exécutés dans le cluster GKE peuvent résoudre les noms de service, et ces noms ne créent pas de conflit entre les clusters. Ce comportement est identique à celui de kube-dns dans les clusters GKE, ce qui signifie que vous pouvez migrer des clusters kube-dns vers un champ d'application de cluster Cloud DNS sans temps d'arrêt ni modifications de vos applications.

Le schéma suivant montre comment Cloud DNS crée une zone DNS privée pour un cluster GKE. Seuls les processus et les pods exécutés sur les nœuds du cluster peuvent résoudre les enregistrements DNS du cluster, car seuls les nœuds sont dans le champ d'application DNS.

Activer le DNS à l'échelle d'un cluster dans un nouveau cluster

Cluster GKE Autopilot

Les nouveaux clusters Autopilot dans la version 1.25.9-gke.400, 1.26.4-gke.500 ou ultérieure utilisent par défaut le champ d'application de cluster Cloud DNS.

Cluster GKE standard

Vous pouvez créer un cluster GKE standard avec le champ d'application de cluster Cloud DNS activé à l'aide de gcloud CLI ou de la console Google Cloud :

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION

Activer le DNS à l'échelle d'un cluster dans un cluster existant

Cluster GKE Autopilot

Vous ne pouvez pas migrer un cluster GKE Autopilot existant de kube-dns vers le champ d'application de cluster Cloud DNS. Pour activer le champ d'application à l'échelle du cluster Cloud DNS, recréez les clusters Autopilot dans la version 1.25.9-gke.400, 1.26.4-gke.500 ou ultérieure.

Cluster GKE standard

Vous pouvez migrer un cluster GKE Standard existant de kube-dns vers le champ d'application de cluster Cloud DNS à l'aide de gcloud CLI ou de la console Google Cloud dans un cluster GKE Standard.

Lorsque vous migrez un cluster existant, les nœuds du cluster n'utilisent pas Cloud DNS en tant que fournisseur DNS tant que vous ne les avez pas recréés.

Une fois que vous avez activé Cloud DNS pour un cluster, les paramètres ne s'appliquent que si vous mettez à niveau des pools de nœuds existants ou si vous ajoutez de nouveaux pools de nœuds au cluster. Lorsque vous mettez à niveau un pool de nœuds, les nœuds sont recréés.

Vous pouvez également migrer des clusters qui exécutent des applications sans interrompre la communication des clusters en activant Cloud DNS en tant que fournisseur DNS dans chaque pool de nœuds séparément. Un sous-ensemble de nœuds est opérationnel en permanence, car certains pools de nœuds utilisent kube-dns et d'autres utilisent Cloud DNS.

Dans les étapes suivantes, vous allez activer Cloud DNS pour un cluster, puis mettre à niveau vos pools de nœuds. La mise à niveau de vos pools de nœuds recrée les nœuds. Les nœuds utilisent ensuite Cloud DNS pour la résolution DNS au lieu de kube-dns.

Activer le champ d'application Cloud DNS additif à l'échelle du VPC

Cette section décrit la procédure à suivre pour activer ou désactiver le champ d'application Cloud DNS additif à l'échelle du VPC en tant que module complémentaire au champ d'application de cluster Cloud DNS.

Activer le champ d'application Cloud DNS additif à l'échemme du VPC dans un nouveau cluster

Vous pouvez activer le DNS à l'échelle du VPC dans un nouveau cluster GKE à l'aide de gcloud CLI ou de la console Google Cloud.

Pour Autopilot

gcloud container clusters create-auto CLUSTER_NAME \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster.
• UNIQUE_CLUSTER_DOMAIN : nom d'un domaine. Vous devez vous assurer que ce nom est unique au sein du VPC, car GKE ne confirme pas cette valeur. Vous ne pouvez pas modifier cette valeur après l'avoir définie. Vous ne devez pas utiliser un domaine se terminant par ".local" sous peine de rencontrer des échecs de résolution DNS.

Pour Standard

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns-scope=cluster \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster.
• UNIQUE_CLUSTER_DOMAIN : nom d'un domaine. Vous devez vous assurer que ce nom est unique au sein du VPC, car GKE ne confirme pas cette valeur. Vous ne pouvez pas modifier cette valeur après l'avoir définie. Vous ne devez pas utiliser un domaine se terminant par ".local" sous peine de rencontrer des échecs de résolution DNS.

Activer le champ d'application Cloud DNS additif à l'échelle du VPC dans un cluster existant

Pour activer le champ d'application Cloud DNS additif à l'échelle du VPC dans un cluster existant, vous devez d'abord activer Cloud DNS pour un cluster, puis mettre à niveau vos pools de nœuds. La mise à niveau de vos pools de nœuds recrée les nœuds. Les nœuds utilisent ensuite Cloud DNS pour la résolution DNS au lieu de kube-dns.

Activez le champ d'application Cloud DNS additif à l'échelle du VPC dans un cluster existant :

gcloud container clusters update CLUSTER_NAME \
    --enable-additive-vpc-scope \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster.
• UNIQUE_CLUSTER_DOMAIN : nom d'un domaine. Vous devez vous assurer que ce nom est unique au sein du VPC, car GKE ne confirme pas cette valeur. Vous ne pouvez pas modifier cette valeur après l'avoir définie. Vous ne devez pas utiliser un domaine se terminant par ".local" sous peine de rencontrer des échecs de résolution DNS.

Activer le DNS à l'échelle du VPC

Dans le DNS à l'échelle d'un VPC, les noms DNS d'un cluster peuvent être résolus sur l'ensemble du VPC. Tout client du VPC peut résoudre les enregistrements DNS de cluster.

Le DNS à l'échelle du VPC s'applique aux cas d'utilisation suivants :

• Détection de services sans adresse IP de cluster pour les clients non-GKE au sein du même VPC.
• Résolution de service GKE à partir de clients cloud tiers ou sur site Pour en savoir plus, consultez la page Règle de serveur entrant.
• Résolution de service dans laquelle un client peut choisir le cluster qu'il souhaite communiquer à l'aide du domaine DNS de cluster personnalisé

Dans le schéma suivant, deux clusters GKE utilisent le DNS à l'échelle d'un VPC dans le même VPC. Les deux clusters disposent d'un domaine DNS personnalisé, .cluster1 et .cluster2, au lieu du domaine .cluster.local par défaut. Une VM communique avec le service de backend sans adresse IP de cluster en résolvant backend.default.svc.cluster1. Cloud DNS résout le service sans adresse IP de pod aux adresses IP individuelles du service, et la VM communique directement avec les adresses IP des pods.

Vous pouvez également effectuer ce type de résolution à partir d'autres réseaux lorsqu'ils sont connectés au VPC via Cloud Interconnect ou Cloud VPN. Les règles de serveur DNS permettent aux clients des réseaux connectés au VPC de résoudre les noms dans Cloud DNS, y compris les services GKE si le cluster utilise le DNS à l'échelle d'un VPC.

Activer le DNS à l'échelle du VPC dans un cluster existant

La migration n'est possible que dans GKE Standard et non dans GKE Autopilot.

Cluster GKE Autopilot

Vous ne pouvez pas migrer un cluster GKE Autopilot de kube-dns vers le champ d'application Cloud DNS à l'échelle du VPC.

Cluster GKE standard

Vous pouvez migrer un cluster GKE existant de kube-dns vers le champ d'application d'un VPC Cloud DNS à l'aide de la gcloud CLI ou de la console Google Cloud.

Une fois que vous avez activé Cloud DNS pour un cluster, les paramètres ne s'appliquent que si vous mettez à niveau des pools de nœuds existants ou si vous ajoutez de nouveaux pools de nœuds au cluster. Lorsque vous mettez à niveau un pool de nœuds, les nœuds sont recréés.

Dans les étapes suivantes, vous allez activer Cloud DNS pour un cluster, puis mettre à niveau vos pools de nœuds. La mise à niveau de vos pools de nœuds recrée les nœuds. Les nœuds utilisent ensuite Cloud DNS pour la résolution DNS au lieu de kube-dns.

Vérifier le Cloud DNS

Vérifiez que Cloud DNS pour GKE fonctionne correctement pour votre cluster :

1. Vérifiez que les nœuds utilisent Cloud DNS en vous connectant à un pod sur un nœud et en exécutant la commande cat /etc/resolv.conf :

   kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
   

   Remplacez POD_NAME par le nom du pod.

   En fonction du mode du cluster, le résultat ressemble à ce qui suit :

   Cluster GKE Autopilot

   nameserver 169.254.20.10
   

   Étant donné que NodeLocal DNSCache est activé par défaut dans GKE Autopilot, le pod utilise NodeLocal DNSCache.

   NodeLocal DNSCache ne transfère la requête à Cloud DNS que lorsque le cache local ne contient aucune entrée pour le nom recherché.

   Cluster GKE standard

   nameserver 169.254.169.254
   

   Le pod utilise 169.254.169.254 comme nameserver, qui est l'adresse IP du serveur de métadonnées sur lequel le plan de données Cloud DNS écoute les requêtes sur le port 53. Les nœuds n'utilisent plus l'adresse du service kube-dns pour la résolution DNS, et toutes les résolutions DNS se produisent sur le nœud local.

   Si le résultat est une adresse IP semblable à 10.x.y.10, le pod utilise kube-dns. Consultez la page Dépannage pour comprendre pourquoi votre pod utilise toujours kube-dns.

   Si le résultat est 169.254.20.10, cela signifie que vous avez activé NodeLocal DNSCache dans votre cluster, alors le pod utilise NodeLocal DNSCache.

2. Déployez un exemple d'application sur votre cluster :

   kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

3. Exposez l'exemple d'application avec un service :

   kubectl expose pod dns-test --name dns-test-svc --port 8080
   

4. Vérifiez que le service a bien été déployé :

   kubectl get svc dns-test-svc
   

   Le résultat ressemble à ce qui suit :

   NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
   dns-test-svc   ClusterIP   10.47.255.11    <none>        8080/TCP   6m10s
   

   La valeur de CLUSTER-IP correspond à l'adresse IP virtuelle de votre cluster. Dans cet exemple, l'adresse IP virtuelle est 10.47.255.11.

5. Vérifiez que votre nom de service a été créé en tant qu'enregistrement dans la zone DNS privée de votre cluster :

   gcloud dns record-sets list \
       --zone=PRIVATE_DNS_ZONE \
       --name=dns-test-svc.default.svc.cluster.local.
   

   Remplacez PRIVATE_DNS_ZONE par le nom de la zone DNS gérée.

   Le résultat ressemble à ce qui suit :

   NAME: dns-test-svc.default.svc.cluster.local.
   TYPE: A
   TTL: 30
   DATA: 10.47.255.11
   

Désactiver Cloud DNS pour GKE

Cluster GKE Autopilot

Vous ne pouvez pas désactiver Cloud DNS dans un cluster GKE Autopilot créé avec Cloud DNS par défaut. Consultez les conditions requises pour en savoir plus sur les clusters GKE Autopilot utilisant Cloud DNS par défaut.

Cluster GKE standard

Vous pouvez désactiver Cloud DNS à l'aide de gcloud CLI ou de la console Google Cloud dans un cluster GKE Standard.

gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=default

Désactiver le champ d'application Cloud DNS additif à l'échelle du VPC

Lorsque vous désactivez le champ d'application Cloud DNS additif à l'échelle du VPC pour votre cluster, seuls les enregistrements DNS des zones privées associées au réseau VPC sont supprimés. Les enregistrements des zones DNS privées du cluster GKE resteront gérés par Cloud DNS pour GKE jusqu'à ce que le service sans adresse IP de cluster soit supprimé du cluster.

Pour désactiver le champ d'application Cloud DNS additif à l'échelle du VPC, exécutez la commande suivante:

gcloud container clusters update CLUSTER_NAME \
    --disable-additive-vpc-scope

Remplacez CLUSTER_NAME par le nom du cluster.

Votre cluster avec le champ d'application de cluster Cloud DNS activé continuera de fournir une résolution DNS à partir du cluster.

Effectuer un nettoyage

Après avoir terminé les exercices de cette page, procédez comme suit pour supprimer les ressources afin d'éviter que des frais inutiles ne vous soient facturés sur votre compte :

1. Supprimez le service :

   kubectl delete service dns-test-svc
   

2. Supprimez le pod :

   kubectl delete Pod dns-test
   

3. Vous pouvez également supprimer le cluster.

Utiliser Cloud DNS avec un VPC partagé

Cloud DNS pour GKE est compatible avec le VPC partagé à la fois pour le champ d'application VPC et le champ d'application de cluster.

Le contrôleur GKE crée une zone privée gérée dans le même projet que le cluster GKE.

Le compte de service GKE pour le cluster GKE n'a pas besoin d'IAM (Identity and Access Management) pour gérer le DNS en dehors de son propre projet, car la zone gérée et le cluster GKE résident dans le même projet.

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.

Si vous possédez déjà des clusters utilisant un VPC partagé et le champ d'application à l'échelle du VPC de Cloud DNS, vous devez les migrer manuellement en procédant comme suit :

• Mettez à niveau vos clusters existants sur lesquels le VPC partagé est activé vers la version 1.22.3-gke.700 ou 1.21.6-gke.1500 ou ultérieure de GKE.
• Migrez la stratégie de réponse du projet de service vers le projet hôte. Vous n'avez besoin d'effectuer cette migration qu'une seule fois par réseau VPC partagé.

Vous pouvez migrer votre stratégie de réponse à l'aide de Google Cloud Console.

Effectuez les étapes suivantes dans votre projet de service :

1. Accédez à la page Zones Cloud DNS.

   Accéder aux zones Cloud DNS

2. Cliquez sur l'onglet Zones de stratégie de réponse.

3. Cliquez sur la stratégie de réponse pour votre réseau VPC. Vous pouvez identifier la stratégie de réponse par sa description, dont la syntaxe est de type "Stratégie de réponse pour les clusters GKE sur le réseau NETWORK_NAME".

4. Cliquez sur l'onglet Utilisée par.

5. Cliquez sur delete en regard du nom de votre projet hôte pour supprimer la liaison réseau.

6. Cliquez sur l'onglet Règles de stratégie de réponse.

7. Sélectionnez toutes les entrées du tableau.

8. Cliquez sur Supprimer les règles de stratégie de réponse.

9. Cliquez sur delete Supprimer la stratégie de réponse.

Une fois la stratégie de réponse supprimée, le contrôleur DNS crée automatiquement la stratégie de réponse dans le projet hôte. Les clusters d'autres projets de service partagent cette stratégie de réponse.

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.

Problèmes connus

Terraform prévoit de recréer un cluster Autopilot en raison de la 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 exécutant 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 plutôt que 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 lifecycle.ignore_changes à la ressource pour vous assurer que google_container_cluster ignore les modifications apportées à dns_config :

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Dépannage

Pour savoir comment activer la journalisation DNS, consultez la page Activer et désactiver la journalisation pour les zones gérées privées.

Pour en savoir plus sur la résolution des problèmes DNS, consultez la page Résoudre les problèmes liés au DNS dans GKE.

Impossible de mettre à jour un cluster existant ou de créer un cluster avec Cloud DNS activé

Vérifiez que vous utilisez la bonne version. Cloud DNS pour GKE nécessite la version 1.19 ou ultérieure de GKE pour les clusters utilisant le champ d'application VPC, ou GKE 1.24.7-gke.800, 1.25.3-gke.700 ou ultérieure pour les clusters utilisant le champ d'application de cluster.

Les pods utilisent kube-dns même après l'activation de Cloud DNS sur un cluster existant

Assurez-vous d'avoir mis à jour ou recréé vos pools de nœuds après avoir activé Cloud DNS sur le cluster. Jusqu'à la fin de cette étape, les pods continuent à utiliser kube-dns.

Le pod ne parvient pas à résoudre les résolutions DNS

1. Vérifiez que le pod utilise Cloud DNS en vous connectant à un pod et en exécutant la commande cat /etc/resolv.conf :

   kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
   

   Remplacez POD_NAME par le nom du pod.

   Le résultat ressemble à ce qui suit :

   nameserver 169.254.169.254
   

   Si le résultat est une adresse IP semblable à 10.x.y.10 ou 34.118.224.10 (uniquement dans les clusters GKE Autopilot avec les versions 1.27 et ultérieures), le pod utilise kube-dns. Si le résultat est 169.254.20.10, le pod utilise NodeLocal DNSCache.

2. Vérifiez que la zone gérée existe et qu'elle contient l'entrée DNS requise :

   gcloud dns managed-zones list --format list
   

   Le résultat ressemble à ce qui suit :

    - creationTime: 2021-02-12T19:24:37.045Z
      description: Private zone for GKE cluster "cluster1" with cluster suffix "cluster.local" in project "project-243723"
      dnsName: cluster.local.
      id: 5887499284756055830
      kind: dns#managedZone
      name: gke-cluster1-aa94c1f9-dns
      nameServers: ['ns-gcp-private.googledomains.com.']
      privateVisibilityConfig: {'kind': 'dns#managedZonePrivateVisibilityConfig'}
      visibility: private
   

   La valeur de name dans la réponse indique que Google Cloud a créé une zone privée nommée gke-cluster1-aa94c1f9-dns.

3. Vérifiez que Cloud DNS contient des entrées pour votre cluster :

   gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME
   

   Remplacez l'élément suivant :

   • ZONE_NAME : nom de la zone privée.
   • SERVICE_NAME : nom du service.

   Le résultat indique que Cloud DNS contient un enregistrement A pour le domaine dns-test.default.svc.cluster.local. et l'adresse IP de votre cluster, 10.47.255.11 :

   dns-test.default.svc.cluster.local.                A     30     10.47.255.11
   

4. Activez la journalisation Cloud DNS pour effectuer le suivi des requêtes. Chaque entrée de journal contient des informations sur la requête, y compris la latence DNS.

Les résolutions DNS sur les nœuds échouent après l'activation de Cloud DNS sur un cluster

Si vous activez Cloud DNS au niveau du cluster dans un cluster GKE comportant des serveurs de simulation personnalisés ou des serveurs de noms en amont, la configuration personnalisée s'applique à la fois aux nœuds et aux pods du cluster, car Cloud DNS ne peut pas faire la distinction entre les requêtes DNS de pod et de nœud. Les résolutions DNS sur les nœuds peuvent échouer si le serveur en amont personnalisé ne peut pas résoudre les requêtes.

Impossible de mettre à jour un cluster existant ou de créer un cluster avec le champ d'application Cloud DNS additif à l'échelle du VPC activé.

Vérifiez que vous utilisez la bonne version. Le champ d'application Cloud DNS additif à l'échelle du VPC nécessite la version 1.28 de GKE ou une version ultérieure.

Le pod ne parvient pas à résoudre les résolutions DNS

1. Vérifiez que le pod utilise Cloud DNS en vous connectant à un pod et en exécutant la commande cat /etc/resolv.conf :

   kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
   

   Remplacez POD_NAME par le nom du pod.

   Le résultat ressemble à ce qui suit :

   nameserver 169.254.169.254
   

   Si le résultat est une adresse IP semblable à 10.x.y.10 ou 34.118.224.10 (uniquement dans les clusters GKE Autopilot avec les versions 1.27 et ultérieures), le pod utilise kube-dns. Si le résultat est 169.254.20.10, le pod utilise NodeLocal DNSCache.

2. Vérifiez que la zone gérée existe et qu'elle contient l'entrée DNS requise :

   gcloud dns managed-zones list --format list
   

   Le résultat ressemble à ce qui suit :

   gke-cluster-1-cbdc0678-dns  cluster.local.   Private zone for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "PROJECT_NAME" with scope "CLUSTER_SCOPE"  private
   gke-cluster-1-cbdc-dns-vpc  CLUSTER_DOMAIN.  Private zone for GKE cluster "cluster-1" with cluster suffix "CLUSTER_DOMAIN." in project "PROJECT_NAME" with scope "VPC_SCOPE"     private
   

   La valeur de name dans la réponse indique que Google Cloud a créé une zone privée nommée gke-cluster1-aa94c1f9-dns.

3. Vérifiez que Cloud DNS contient des entrées pour votre cluster dans les deux zones gérées :

   gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME
   

   Remplacez les éléments suivants :

   • ZONE_NAME : nom de la zone privée.
   • SERVICE_NAME : nom du service.

   Le résultat ressemble à ce qui suit :

   my-service.default.svc.cluster.local.                A     30     10.47.255.11
   

   La valeur de name dans la réponse indique que Google Cloud a créé une zone privée nommée gke-cluster1-aa94c1f9-dns.

4. Pour les résolutions DNS inverses, vérifiez que Cloud DNS contient des entrées pour votre cluster dans ResponsePolicies :

   gcloud dns response-policies list --format="table(responsePolicyName, description)"
   

   Le résultat ressemble à ce qui suit :

     gke-NETWORK_HASH-rp        Response Policy for GKE clusters on network "VPC_NAME".
     gke-cluster-1-52c8f518-rp  Response Policy for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "khamed-gke-dev" with scope "CLUSTER_SCOPE".
   

   La valeur de name dans la réponse indique que Google Cloud a créé une zone privée nommée gke-cluster1-aa94c1f9-rp.

5. Pour les résolutions DNS inverses, vérifiez que Cloud DNS contient des entrées pour votre cluster dans ResponsePolicies :

     gcloud dns response-policies rules list ZONE_NAME --format="table(localData.localDatas[0].name, localData.localDatas[0].rrdatas[0])"
   

   Remplacez ZONE_NAME par le nom de la zone privée.

   Le résultat ressemble à ce qui suit :

     1.240.27.10.in-addr.arpa.    kubernetes.default.svc.cluster.local.
     52.252.27.10.in-addr.arpa.   default-http-backend.kube-system.svc.cluster.local.
     10.240.27.10.in-addr.arpa.   kube-dns.kube-system.svc.cluster.local.
     146.250.27.10.in-addr.arpa.  metrics-server.kube-system.svc.cluster.local.
   

Étapes suivantes

• Consultez une présentation de la façon dont GKE fournit le DNS géré.
• Consultez la page DNS pour les services et les pods pour obtenir une présentation générale de l'utilisation du DNS dans les clusters Kubernetes.
• Découvrez les champs d'application et les hiérarchies dans Cloud DNS.
• Découvrez comment activer et désactiver la journalisation pour les zones gérées privées.