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

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 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 sur son adresse IP virtuelle, pour les services IP de cluster, ou la liste des adresses IP des 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 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.

  • À 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 répertorie les différences entre le champ d'application du cluster GKE, le champ d'application Cloud DNS additif à l'échelle du VPC, et le champ d'application à l'échelle du VPC:

Sélection 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 dans le cluster GKE S'étend sur l'ensemble du réseau VPC Tout le réseau VPC
Résolution des services sans adresse IP de cluster Résolu dans le cluster Résolu dans le cluster à l'aide de "cluster.local" et sur le VPC à l'aide du suffixe de cluster Résolu dans le cluster et sur le VPC à l'aide du suffixe de cluster
Exigence de domaine unique Non. Utilise le paramètre "*.cluster.local" par défaut. Oui, vous devez définir un domaine personnalisé unique Oui, vous devez définir un domaine personnalisé unique
Paramétrer la configuration Par défaut, aucune étape supplémentaire Facultatif lors de la création du cluster
Peut être activé/désactivé à tout moment		 Doit être configuré lors de la création du cluster

Ressources Cloud DNS

Lorsque vous utilisez Cloud DNS en tant que 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.

Niveau d'accès Transférer la zone de recherche Zone de recherche inversée
Champ d'application : cluster Une zone privée par cluster et par zone Compute Engine (dans la région) Une zone de stratégie de réponse par cluster et 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 :

Niveau d'accès 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 du 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 cluster
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 de zone
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 en savoir plus sur la création de domaines de simulation personnalisés ou de serveurs de noms en amont personnalisés, consultez la section Ajouter des résolveurs personnalisés pour les domaines de simulation.

Zones gérées et zones de transfert

Pour diffuser 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 la version standard, GKE version 1.24.7-gke.800, 1.25.3-gke.700 ou ultérieure
  • Pour Autopilot, version 1.25.9-gke.400, 1.26.4-gke.500 ou ultérieure de GKE.
  • 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 version 1.24.7-gke.800, 1.25.3-gke.700 ou 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 de 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 de cluster est accepté. 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 un champ d'application de VPC additif.
  • 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 automatiquement effectuée 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 option n'est disponible que dans le mode 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 option n'est disponible que dans le mode 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 lors du passage de kube-dns au 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 lors de l'utilisation de Cloud DNS pour GKE:

Ressource DNS Kubernetes Ressource Cloud DNS correspondante Quotas
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/IPv6) Nombre d'enregistrements par jeu d'enregistrements de ressources GKE 1.24 à 1.25: 1000 (IPv4/IPv6)
GKE 1.26 et versions ultérieures: 3 500/2 000 (IPv4/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é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.

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

Cluster GKE Autopilot

Les nouveaux clusters Autopilot dans les versions 1.25.9-gke.400, 1.26.4-gke.500 ou ultérieures sont définis par défaut sur 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

Créez un cluster à l'aide de l'option --cluster-dns :

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

Remplacez les éléments suivants :

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

Console

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans le volet de navigation, cliquez sur Réseau sous Cluster.

  4. Dans la section Fournisseur DNS, cliquez sur Cloud DNS.

  5. Sélectionnez Capacité en nombre de clusters.

  6. Configurez le cluster selon vos besoins.

  7. Cliquez sur Créer.

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 du cluster Cloud DNS, recréez les clusters Autopilot dans les versions 1.25.9-gke.400, 1.26.4-gke.500 ou ultérieures.

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.

gcloud

  1. Mettez à jour le cluster existant :

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

    Remplacez l'élément suivant :

    La réponse est semblable à ce qui suit :

    All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
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 mis à niveau votre pool de nœuds ou ajouté de nouveaux pools de 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 \
    --location=COMPUTE_LOCATION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • POOL_NAME : nom du pool de nœuds à mettre à niveau.

    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.

Console

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Mise en réseau, dans le champ Fournisseur DNS, cliquez sur Modifier le fournisseur DNS.

  4. Cliquez sur Cloud DNS.

  5. Cliquez sur Capacité en nombre de clusters.

  6. Cliquez sur Enregistrer les modifications.

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.

Pour activer le champ d'application à l'échelle du VPC de Cloud DNS dans un cluster existant, procédez comme suit:

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

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 au VPC de résoudre les noms dans Cloud DNS, y compris les services GKE si le cluster utilise le DNS à l'échelle du VPC.

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

La migration n'est possible que dans GKE Standard et non sur 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.

gcloud

  1. Mettez à jour le cluster existant :

    gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=vpc \
    --cluster-dns-domain=CUSTOM_DOMAIN \
    --location=COMPUTE_LOCATION

    Remplacez l'élément suivant :

    • CLUSTER_NAME : nom du cluster.
    • COMPUTE_LOCATION : emplacement Compute Engine du cluster.
    • 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 :

    All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
shortly after enabling Cloud DNS.
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. Vos pods n'utilisent pas Cloud DNS pour la résolution DNS tant que vous n'avez pas mis à niveau votre pool de nœuds ou ajouté de nouveaux pools de 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

    Remplacez l'élément suivant :

    • CLUSTER_NAME : nom du cluster.
    • POOL_NAME : nom du pool de nœuds à mettre à niveau.

    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.

Console

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Mise en réseau, dans le champ Fournisseur DNS, cliquez sur Modifier le fournisseur DNS.

  4. Cliquez sur Cloud DNS.

  5. Cliquez sur À l'échelle d'un VPC.

  6. Cliquez sur Enregistrer les modifications.

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.

    Le cache local NodeNode DNS ne transfère la requête à Cloud DNS que lorsque le cache local ne contient pas d'entrée pour le nom recherché.

    Cluster GKE standard

    nameserver 169.254.169.254

    Le pod utilise 169.254.169.254 en tant que 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 section 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.

  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éé par défaut avec Cloud DNS. Consultez les exigences 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

Mettez à jour le cluster pour utiliser kube-dns:

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

Console

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Mise en réseau, dans le champ Fournisseur DNS, cliquez sur Modifier le fournisseur DNS.

  4. Cliquez sur Kube-dns.

  5. Cliquez sur Enregistrer les modifications.

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

Ainsi, le champ d'application de cluster Cloud DNS sera activé pour votre cluster afin de fournir la 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 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 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 le cluster Autopilot en raison de la modification de dns_config.

Si vous utilisez terraform-provider-google ou terraform-provider-google-beta, vous risquez de rencontrer un problème lorsque 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 les règles 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 les règles 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