Utiliser Cloud DNS pour GKE


Cette page explique comment utiliser Cloud DNS pour Google Kubernetes Engine (GKE).

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

Le DNS à l'échelle du VPC est en disponibilité générale dans les versions 364.0.0 et ultérieures de Google Cloud CLI, et en version bêta dans les versions antérieures. Le champ d'application du cluster GKE est disponible en version Bêta dans les versions 341.0.0 et ultérieures de la CLI Google Cloud.

Aperçu

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 "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 Google hébergé.
  • 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 à la suite Google Cloud Operations pour la surveillance et la journalisation DNS.

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 synchronise les enregistrements DNS du cluster dans une zone DNS gérée et privé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:

Un pod demande l'adresse IP d'un service à l'aide de Cloud DNS
Schéma : résoudre 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 l'adresse IP du service 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.

Le plan de données Cloud DNS s'exécute localement dans chaque 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 ou en liste d'adresses IP de point de terminaison.

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 possède deux types de champs d'application DNS : à l'échelle du cluster GKE et à l'échelle du VPC (cloud privé virtuel). Un cluster ne peut pas fonctionner simultanément dans ces deux modes.

Le champ d'application de VPC est en disponibilité générale pour les versions 364.0.0 et ultérieures de Google Cloud CLI. Le champ d'application du cluster est en version bêta.

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

Tarifs

Lorsque Cloud DNS est le fournisseur DNS pour GKE, les requêtes DNS des pods du cluster GKE sont facturées selon la tarification Cloud DNS. Les requêtes DNS adressées à une zone DNS à l'échelle du cluster gérées par GKE ne sont pas facturées en version bêta. La facturation commence en phase de disponibilité générale.

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.

Exigences

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

  • GKE version 1.18 ou ultérieure pour les nouveaux clusters ou GKE version 1.19 ou ultérieure pour les clusters existants.
  • Le DNS à l'échelle du VPC est en disponibilité générale dans les versions 364.0.0 et ultérieures de Google Cloud CLI, et en version bêta dans les versions antérieures. Le champ d'application du cluster GKE est disponible en version Bêta dans les versions 341.0.0 et ultérieures de la CLI Google Cloud.

Restrictions

Cloud DNS pour GKE présente les restrictions suivantes :

  • Vous ne devez pas joindre un parc si le cluster GKE est configuré avec un DNS à l'échelle d'un cluster ou d'un DNS à l'échelle d'un VPC en tant que résolveur de nom de service dans le cluster. Cela entraînerait une résolution de nom incorrecte pour les services multiclusters.
  • Uniquement disponible pour les clusters GKE sur Google Cloud.
  • Une fois que vous avez activé Cloud DNS pour GKE dans un cluster, vous ne pouvez pas le désactiver dans le cluster et kube-dns continue de s'exécuter dans le cluster. Vous pouvez désactiver kube-dns en redimensionnant le déploiement kube-dns et 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.
  • Cloud DNS est une infrastructure mondiale avec des dépendances globales, à la différence des fournisseurs DNS comme kube-dns, où l'infrastructure DNS entière existe localement au sein du cluster.
  • 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.
  • 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.
  • En mode 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.
  • Des quotas et limites pour Cloud DNS s'appliquent et peuvent être différents des limites de kube-dns pour votre projet.
  • Le contrôleur Cloud DNS écrase toutes les modifications manuelles que vous apportez aux enregistrements DNS dans la zone DNS lorsque le contrôleur redémarre.

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étection de services basée sur DNS de Kubernetes.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Assurez-vous d'avoir activé l'API Google Kubernetes Engine.
  • Activer l'API Google Kubernetes Engine
  • Assurez-vous d'avoir installé Google Cloud CLI.
  • Configurez les paramètres par défaut de Google Cloud CLI pour votre projet en utilisant l'une des méthodes suivantes :
    • Utilisez gcloud init si vous souhaitez suivre les étapes de définition des paramètres par défaut du projet.
    • Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

    gcloud init

    1. Exécutez gcloud init et suivez les instructions :

      gcloud init

      Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

      gcloud init --console-only
    2. Suivez les instructions pour autoriser gcloud CLI à utiliser votre compte Google Cloud.
    3. Créez ou sélectionnez une configuration.
    4. Choisissez un projet Google Cloud.
    5. Choisissez une zone Compute Engine par défaut.
    6. Choisissez une région Compute Engine par défaut.

    gcloud config

    1. Définissez votre ID de projet par défaut :
      gcloud config set project PROJECT_ID
    2. Définissez votre région Compute Engine par défaut (par exemple, us-central1) :
      gcloud config set compute/region COMPUTE_REGION
    3. Définissez votre zone Compute Engine par défaut (par exemple, us-central1-c) :
      gcloud config set compute/zone COMPUTE_ZONE
    4. Mettez à jour gcloud vers la dernière version :
      gcloud components update

    En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

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.

Pods sur différents nœuds résolvant des services dans le cluster GKE
Schéma : DNS à l'échelle du cluster

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

Vous pouvez créer un cluster avec Cloud DNS activé à l'aide de la commande suivante :

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --cluster-version=VERSION \
    --region=COMPUTE_REGION

Remplacez l'élément suivant :

  • CLUSTER_NAME : nom du cluster.
  • VERSION : version de GKE, qui doit être 1.18 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner un canal de publication. La version disponible doit correspondre à la version 1.18 ou ultérieure.
  • COMPUTE_REGION : région Compute Engine du nouveau cluster. Pour les clusters zonaux, utilisez --zone=COMPUTE_ZONE.

L'option --cluster-dns-scope=cluster est facultative dans la commande, car cluster est la valeur par défaut.

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

Vous pouvez migrer un cluster GKE existant de kube-dns vers le champ d'application de cluster Cloud DNS.

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 qu'aux nouveaux nœuds GKE qui sont ajoutés 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.

  1. Mettez à jour le cluster existant :

    gcloud beta container clusters update CLUSTER_NAME \
        --cluster-dns=clouddns \
        --cluster-dns-scope=cluster
    

    Remplacez CLUSTER_NAME par le nom du cluster.

    La réponse est semblable à ce qui suit :

    Enabling CloudDNS is a one-way operation. Once enabled, this
    configuration cannot be disabled. All the node pools in the cluster
    need to be re-created by the user to start using CloudDNS for DNS
    lookups. It is highly recommended to complete this step shortly after
    enabling CloudDNS.
    Do you want to continue (Y/n)?
    

    Une fois la confirmation effectuée, le contrôleur Cloud DNS s'exécute sur le plan de contrôle GKE, mais vos pods n'utilisent pas Cloud DNS pour la résolution DNS tant que vous n'avez pas recréé les nœuds ou ajouté des nœuds au cluster.

  2. Mettez à niveau les pools de nœuds du cluster pour qu'ils utilisent Cloud DNS :

    gcloud beta container clusters upgrade CLUSTER_NAME \
        --node-pool=POOL_NAME \
        --cluster-version=VERSION
    

    Remplacez l'élément suivant :

    • CLUSTER_NAME : nom du cluster.
    • POOL_NAME : nom du pool de nœuds à mettre à niveau.
    • VERSION : version de GKE, qui doit être 1.18 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner un canal de publication. La version disponible doit correspondre à la version 1.18 ou ultérieure.

    Si le pool de nœuds et le plan de contrôle exécutent la même version, mettez d'abord le plan de contrôle à jour, comme décrit dans la section Mettre à jour manuellement le plan de contrôle, puis effectuez la mise à niveau du pool de nœuds.

    Confirmez la réponse et répétez cette commande pour chaque pool de nœuds du cluster. Si votre cluster ne comporte qu'un seul pool de nœuds, omettez l'option --node-pool.

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

    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, le pod utilise kube-dns. Si le résultat est 169.254.20.10, le pod utilise NodeLocalDNS. 169.254.169.254 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.

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

Clients résolvant des services sans adresse IP en dehors du cluster GKE
Schéma : DNS à l'échelle d'un VPC

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 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 d'un VPC dans un nouveau cluster

Vous pouvez activer le DNS à l'échelle du VPC dans un nouveau cluster à l'aide de gcloud CLI. La commande que vous utilisez dépend de votre version de Google Cloud CLI.

Vous pouvez créer un cluster sur lequel Cloud DNS est activé à l'aide de la commande suivante :

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=vpc \
    --cluster-version=VERSION \
    --cluster-dns-domain=CUSTOM_DOMAIN \
    --region=COMPUTE_REGION

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster.
  • VERSION : version de GKE, qui doit être 1.18 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner un canal de publication. La version disponible doit correspondre à la version 1.18 ou ultérieure.
  • COMPUTE_REGION : région Compute Engine du nouveau cluster. Pour les clusters zonaux, utilisez --zone=COMPUTE_ZONE.
  • CUSTOM_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 un cluster existant

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

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 qu'aux nouveaux nœuds GKE qui sont ajoutés 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.

  1. Mettez à jour le cluster existant :

    gcloud container clusters update CLUSTER_NAME \
        --cluster-dns=clouddns \
        --cluster-dns-scope=vpc \
        --cluster-dns-domain=CUSTOM_DOMAIN \
        --region=COMPUTE_REGION
    

    Remplacez l'élément suivant :

    • CLUSTER_NAME : nom du cluster.
    • COMPUTE_REGION : région Compute Engine du nouveau cluster. Pour les clusters zonaux, utilisez --zone=COMPUTE_ZONE.
    • CUSTOM_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.

    La réponse est semblable à ce qui suit :

    Enabling CloudDNS is a one-way operation. Once enabled, this
    configuration cannot be disabled. All the node pools in the cluster
    need to be re-created by the user to start using CloudDNS for DNS
    lookups. It is highly recommended to complete this step shortly after
    enabling CloudDNS.
    Do you want to continue (Y/n)?
    

    Une fois la confirmation effectuée, le contrôleur Cloud DNS s'exécute sur le plan de contrôle GKE, mais vos pods n'utilisent pas Cloud DNS pour la résolution DNS tant que vous n'avez pas recréé les nœuds ou ajouté des nœuds au cluster.

  2. Mettez à niveau les pools de nœuds du cluster pour qu'ils utilisent Cloud DNS :

    gcloud container clusters upgrade CLUSTER_NAME \
        --node-pool=POOL_NAME \
        --cluster-version=VERSION
    

    Remplacez l'élément suivant :

    • CLUSTER_NAME : nom du cluster.
    • POOL_NAME : nom du pool de nœuds à mettre à niveau.
    • VERSION : version de GKE, qui doit être 1.18 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner un canal de publication. La version disponible doit correspondre à la version 1.18 ou ultérieure.

    Si le pool de nœuds et le plan de contrôle exécutent la même version, mettez d'abord le plan de contrôle à jour, comme décrit dans la section Mettre à jour manuellement le plan de contrôle, puis effectuez la mise à niveau du pool de nœuds.

    Confirmez la réponse et répétez cette commande pour chaque pool de nœuds du cluster. Si votre cluster ne comporte qu'un seul pool de nœuds, omettez l'option --node-pool.

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

    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, le pod utilise kube-dns. Si le résultat est 169.254.20.10, le pod utilise NodeLocal DNSCache. 169.254.169.254 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.

Vérifier le Cloud DNS

Pour vérifier que Cloud DNS pour GKE fonctionne correctement pour votre cluster, procédez comme suit :

  1. Déployez un exemple d'application sur votre cluster à l'aide de la commande suivante :

    kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
    
  2. Exposez l'exemple d'application avec un service à l'aide de la commande suivante :

    kubectl expose pod dns-test --name dns-test-svc --port 8080
    
  3. 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.

Résoudre le nom du service

Connectez-vous à un pod à l'aide de kubectl exec et résolvez le nom du service à l'aide de la commande nslookup pour vérifier que Cloud DNS diffuse les enregistrements DNS dans votre cluster :

Capacité en nombre de clusters

kubectl exec -it dns-test -- nslookup dns-test-svc

Le résultat ressemble à ce qui suit :

Server:   169.254.169.254
Address:  169.254.169.254#53

Non-authoritative answer:
Name: dns-test-svc.default.svc.cluster.local
Address: 10.47.255.11

La réponse indique que Cloud DNS a résolu le nom du service dns-test-svc en adresse IP virtuelle du cluster, 10.47.255.11.

Champ d'application d'un VPC

kubectl exec -it dns-test -- nslookup dns-test-svc

Le résultat ressemble à ce qui suit :

Server:   169.254.169.254
Address:  169.254.169.254#53

Non-authoritative answer:
Name: dns-test-svc.default.svc.cluster1
Address: 10.47.255.11

La réponse indique que Cloud DNS a résolu le nom du service dns-test-svc en adresse IP virtuelle du cluster, 10.47.255.11.

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 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 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 le champ d'application de cluster GKE.

Cloud DNS traduit les valeurs stubDomains et upstreamNameservers en zones de transfert Cloud DNS.

Dépannage

Consultez la page Déboguer la résolution DNS pour obtenir des informations générales sur l'analyse des problèmes de DNS de Kubernetes et la page Dépannage pour en savoir plus sur l'analyse des problèmes liés à Cloud DNS.

Vous pouvez également activer la journalisation Cloud DNS.

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. Pour créer des clusters, Cloud DNS pour GKE nécessite la version 1.18 ou ultérieure, ou GKE 1.19 ou version ultérieure pour les clusters existants.

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, le pod utilise kube-dns. Si le résultat est 169.254.20.10, le pod utilise NodeLocalDNS.

  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.

Étape suivante