Utilizzo di Cloud DNS per GKE


Questa pagina spiega come utilizzare Cloud DNS come provider DNS Kubernetes per Google Kubernetes Engine (GKE).

L'utilizzo di Cloud DNS come provider DNS non abilita i client al di fuori di un per risolvere e raggiungere direttamente i servizi Kubernetes. Devi ancora esporre I servizi esternamente utilizzano un bilanciatore del carico e registrano il cluster esterno gli indirizzi IP dell'infrastruttura DNS.

Per ulteriori informazioni sull'utilizzo di kube-dns come provider DNS, consulta Service Discovery e DNS.

Per scoprire come utilizzare una versione personalizzata di kube-dns o un provider DNS personalizzato, vedi Configurazione di un deployment kube-dns personalizzato.

Come funziona Cloud DNS per GKE

Cloud DNS può essere utilizzato come provider DNS per GKE, fornendo una risoluzione DNS di pod e servizi con DNS gestito che non richiede un provider DNS ospitato in un cluster. record DNS per pod Il provisioning dei servizi viene eseguito automaticamente in Cloud DNS per l'indirizzo IP del cluster, headless e nomi esterni Service.

Cloud DNS supporta l'architettura Specifica DNS di Kubernetes e fornisce la risoluzione per i record A, AAAA, SRV e PTR per i servizi all'interno di un cluster GKE. I record PTR vengono implementati utilizzando regole dei criteri di risposta.

L'utilizzo di Cloud DNS come provider DNS per GKE offre numerose Vantaggi rispetto al DNS ospitato in un cluster:

  • Elimina l'overhead associato alla gestione del server DNS ospitato sul cluster. Cloud DNS non richiede scalabilità, monitoraggio o gestione delle istanze DNS, un servizio completamente gestito ospitato nell'infrastruttura di Google a scalabilità elevata.
  • Risoluzione locale delle query DNS su ciascun nodo GKE. Simile a NodeLocal DNSCache, Cloud DNS memorizza nella cache le risposte DNS localmente, fornendo latenza e una risoluzione DNS ad alta scalabilità.

Architettura

Quando Cloud DNS è il provider DNS per GKE, viene eseguito un controller gestito da GKE. Questo pod viene eseguito sui nodi del piano di controllo del cluster e sincronizza i record DNS del cluster in un DNS privato gestito zona di destinazione.

Il seguente diagramma mostra come il piano di controllo e il piano dati di Cloud DNS risolvere i nomi dei cluster:

Un pod richiede l'indirizzo IP di un servizio utilizzando Cloud DNS.
Diagramma: risoluzione dei nomi dei cluster

Nel diagramma, il servizio backend seleziona i pod backend in esecuzione. L'clouddns-controller crea un record DNS per il servizio backend.

Il pod frontend invia una richiesta DNS per risolvere l'indirizzo IP del servizio denominato backend alla Server di metadati locale di Compute Engine su 169.254.169.254. Il server di metadati viene eseguito localmente sul nodo, inviando la cache non riesce a far fronte a Cloud DNS.

Il piano dati Cloud DNS viene eseguito localmente all'interno di ciascun nodo GKE di macchina virtuale (VM) Compute Engine. In base al tipo di servizio Kubernetes, Cloud DNS risolve il nome del servizio nella sua istanza l'indirizzo IP, per i servizi IP cluster, o l'elenco di indirizzi IP degli endpoint, per i servizi headless.

Una volta che il pod frontend ha risolto l'indirizzo IP, il pod può inviare traffico a del servizio backend e di eventuali pod dietro al servizio.

Ambiti DNS

Cloud DNS prevede due tipi di ambiti DNS: Ambito del cluster GKE e ambito del Virtual Private Cloud (VPC). Un cluster non possono funzionare contemporaneamente in entrambe le modalità.

  • Ambito cluster GKE: i record DNS sono risolvibile solo all'interno del cluster, che è lo stesso comportamento di kube-dns. Solo i nodi in esecuzione nel cluster GKE possono risolvere i nomi dei servizi. Per impostazione predefinita, i cluster hanno nomi DNS che terminano con *.cluster.local. Questi DNS sono visibili solo all'interno del cluster e non si sovrappongono o sono in conflitto con *.cluster.local nomi DNS per altri cluster GKE nello stesso luogo progetto. Questa è la modalità predefinita.

    • VPC additivo di Cloud DNS ambito:

      L'ambito VPC additivo di Cloud DNS è una funzionalità facoltativa che estende Ambito del cluster GKE per rendere i servizi headless risolvibili da altri di risorse nel VPC, ad esempio VM di Compute Engine o risorse on-premise e client connessi tramite Cloud VPN o Cloud Interconnect. Additivo L'ambito VPC è una modalità aggiuntiva che è abilitata insieme nell'ambito del cluster, che puoi abilitare o disabilita nel cluster senza influire sul DNS. l'uptime o la capacità (ambito cluster).

  • Ambito VPC: i record DNS sono risolvibili all'interno dell'intero VPC. alle VM di Compute Engine i client on-premise possono connettersi tramite Cloud Interconnect o Cloud VPN direttamente i nomi dei servizi GKE. Devi impostare un valore dominio personalizzato unico per ogni cluster, il che significa che tutti i record DNS di servizi e pod sono univoci del VPC. Questa modalità riduce gli attriti di comunicazione tra risorse GKE e non GKE.

La tabella seguente elenca le differenze tra l'ambito dei cluster GKE, Ambito VPC additivo di Cloud DNS e ambito VPC:

Funzionalità Ambito del cluster GKE Ambito VPC additivo di Cloud DNS Ambito VPC
Ambito della visibilità DNS Solo all'interno del cluster GKE Si estende all'intera rete VPC Intera rete VPC
Risoluzione del servizio headless Risolvebile all'interno del cluster Risolvebile all'interno del cluster utilizzando "cluster.local" e nel VPC utilizzando il suffisso del cluster Risolvebile all'interno del cluster e nel VPC utilizzando il suffisso del cluster
Requisito di dominio univoco No. Utilizza il valore predefinito "*.cluster.local" Sì, devi impostare un dominio personalizzato univoco Sì, devi impostare un dominio personalizzato univoco
Configura configurazione Impostazione predefinita, nessun passaggio aggiuntivo Facoltativo al momento della creazione del cluster
Puoi abilitare/disabilitare in qualsiasi momento
Deve essere configurato durante la creazione del cluster

Risorse Cloud DNS

Quando utilizzi Cloud DNS come provider DNS per GKE cluster, il controller Cloud DNS crea risorse per il tuo progetto. Le risorse utilizzate da GKE dipende dall'ambito di Cloud DNS.

Ambito Zona di ricerca diretta Inverti zona di ricerca
Ambito cluster 1 zona privata per cluster per zona Compute Engine (nella regione) 1 zona del criterio di risposta per cluster per zona Compute Engine (nella regione)
Ambito VPC additivo di Cloud DNS 1 zona privata per cluster per zona Compute Engine (nella regione) per cluster (zona globale)
1 zona privata con ambito VPC per cluster (zona globale)
1 zona del criterio di risposta per cluster per zona Compute Engine (nella regione) per cluster (zona globale)
1 Zona dei criteri di risposta con ambito VPC per cluster (zona globale)
Ambito VPC 1 zona privata per cluster (zona globale) 1 zona del criterio di risposta per cluster (zona globale)

La convenzione di denominazione utilizzata per queste risorse Cloud DNS è la seguente:

Ambito Zona di ricerca diretta Inverti zona di ricerca
Ambito cluster gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-CLUSTER_NAME-CLUSTER_HASH-rp
Ambito VPC additivo di Cloud DNS gke-CLUSTER_NAME-CLUSTER_HASH-dns per le zone con ambito cluster
gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc per le zone con ambito VPC
gke-CLUSTER_NAME-CLUSTER_HASH-rp per le zone con ambito cluster
gke-NETWORK_NAME_HASH-rp per le zone con ambito cluster
Ambito VPC gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-NETWORK_NAME_HASH-rp

Oltre alle zone menzionate nella tabella precedente, crea le seguenti zone nel progetto, a seconda delle configurazione:

Configurazione DNS personalizzata Tipo di zona Convenzione di denominazione delle zone
Dominio Stub Inoltro (zona globale) gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH
Server dei nomi upstream personalizzati Inoltro (zona globale) gke-CLUSTER_NAME-CLUSTER_HASH-upstream

Per ulteriori informazioni su come creare domini stub personalizzati o upstream personalizzati server dei nomi, vedi Aggiunta di resolver personalizzati per i domini stub.

Zone gestite e zone di forwarding

Per gestire il traffico DNS interno, il controller Cloud DNS crea una zona DNS gestita in ogni Zona Compute Engine della regione a cui appartiene il cluster.

Ad esempio: se esegui il deployment di un cluster nella zona us-central1-c, Cloud DNS controller crea una zona gestita in us-central1-a, us-central1-b, us-central1-c e us-central1-f.

Per ogni stubDomain DNS, il controller Cloud DNS ne crea uno zona di inoltro.

Cloud DNS elabora ogni DNS upstream utilizzando una zona gestita con il nome DNS ..

Prezzi

Se Cloud DNS è il provider DNS per i cluster GKE Standard, le query DNS vengono I pod all'interno del cluster GKE vengono fatturati in base Prezzi di Cloud DNS.

Query a una zona DNS con ambito VPC gestita da GKE e vengono fatturati utilizzando i prezzi standard di Cloud DNS.

Requisiti

L'API Cloud DNS deve essere abilitata nel tuo progetto.

Cloud DNS per GKE prevede i seguenti requisiti per nell'ambito del cluster:

  • Per Standard, GKE versione 1.24.7-gke.800, 1.25.3-gke.700 o versioni successive.
  • Per Autopilot, GKE versione 1.25.9-gke.400, 1.26.4-gke.500 o versioni successive.
  • Google Cloud CLI versione 411.0.0 o successive.

Cloud DNS per GKE prevede i seguenti requisiti per gli additive Ambito VPC:

  • Per Standard, GKE versione 1.24.7-gke.800, 1.25.3-gke.700 o versioni successive.
  • Per Autopilot, GKE versione 1.28 o successive.
  • Google Cloud CLI versione 471.0.0.
  • Il cluster GKE deve utilizzare un cluster Cloud DNS come provider DNS predefinito.

Cloud DNS per GKE prevede i seguenti requisiti per Ambito VPC:

  • Per Standard, GKE versione 1.19 o successive.
  • Google Cloud CLI versione 364.0.0 o successive.
  • L'API Cloud DNS deve essere abilitata nel tuo progetto.

Restrizioni e limitazioni

Si applicano le seguenti limitazioni:

  • L'ambito VPC non è supportato sui cluster Autopilot, è supportato solo l'ambito del cluster. Se devi risolvere i problemi relativi ai nomi dei servizi headless in esecuzione nei cluster GKE Autopilot, devi usare un ambito VPC additivo.
  • Cloud DNS non è conforme alla conformità Impact Level 4 (IL4) dell'IA. Cloud DNS per GKE non può essere utilizzato in Carico di lavoro di Assured con un regime di conformità IL4. Devi utilizzare kube-dns in queste applicazioni completamente gestito di Google Cloud. Per i cluster GKE Autopilot, la selezione di kube-dns o Cloud DNS viene eseguito automaticamente in base alla conformità dell'IA.
  • Le modifiche manuali alle zone DNS private gestite non sono supportate e sono sovrascritto dal controller Cloud DNS. Modifiche ai record DNS in quelle zone non rimangono persistenti al riavvio del controller.
  • Non puoi modificare l'ambito DNS in un cluster dopo averlo impostato l'ambito con il flag --cluster-dns-scope. Se devi modificare Nell'ambito DNS, ricrea il cluster con un ambito DNS diverso.
  • Domini stub personalizzati e configurazioni di server DNS upstream alle configurazioni DNS di pod e nodi. Pod che utilizzano il networking host o processi che vengono eseguiti direttamente sull'host, anch'essi utilizzano il dominio stub configurazioni dei nameserver a monte. Questa opzione è supportata solo nella versione standard.
  • Domini stub personalizzati e server dei nomi upstream configurati tramite Configmap kube-dns vengono applicate automaticamente a Cloud DNS per il DNS nell'ambito del cluster. Il DNS nell'ambito VPC ignora il ConfigMap kube-dns e devi applicare queste configurazioni direttamente su Cloud DNS. Questa opzione è supportata solo nella versione standard.
  • Non esiste un percorso di migrazione da kube-dns all'ambito VPC, l'operazione è dirompente. Ricrea il cluster quando si passa da kube-dns a VPC o viceversa.
  • Per l'ambito VPC, l'intervallo di indirizzi IP secondari per i servizi deve non verranno condivisi con altri cluster nella subnet.
  • Per l'ambito VPC, il criterio di risposta associato a un PTR è collegato alla rete VPC. Se ci sono altri criteri di risposta associati alla rete del cluster, la risoluzione del record PTR ha esito negativo per gli indirizzi IP dei servizi Kubernetes.
  • Se provi a creare un servizio headless con un numero di pod che supera consentita, Cloud DNS non crea set di record o record il Servizio.

Quote

Cloud DNS usa le quote per limitare il numero di risorse che GKE può creare delle voci DNS. Quote e limiti per Cloud DNS potrebbe essere diverso dai limiti di kube-dns per il tuo progetto.

Le seguenti quote predefinite vengono applicate a ogni zona gestita nel tuo progetto quando utilizzi Cloud DNS per GKE:

Risorsa DNS di Kubernetes Risorsa Cloud DNS corrispondente Quota
Numero di record DNS Byte massimi per zona gestita 2.000.000 (50 MB max per una zona gestita)
Numero di pod per servizio headless (IPv4/IPv6) Numero di record per set di record di risorse GKE da 1.24 a 1.25: 1000 (IPv4/IPv6)
GKE 1.26 e versioni successive: 3500/2000 (IPv4/IPv6)
Numero di cluster GKE in un progetto Numero di criteri di risposta per progetto 100
Numero di record PTR per cluster Numero di regole per criterio di risposta 100.000

Limiti delle risorse

Le risorse Kubernetes che crei per cluster contribuiscono a Limiti delle risorse Cloud DNS, come descritto in la tabella seguente:

Limite Contributo per la limitazione
Set di record di risorse per zona gestita Numero di servizi più il numero di endpoint di servizio headless con nomi host validi, per cluster.
Record per set di record di risorse Numero di endpoint per servizio headless. Non influisce sulle altre i tipi di servizi.
Numero di regole per criterio di risposta Per l'ambito del cluster, il numero di servizi più il numero di headless degli endpoint di servizio con nomi host validi per cluster. Per l'ambito VPC, il numero di servizi più il numero di endpoint headless con nomi host di tutti i cluster nel in un VPC.

Per saperne di più su come vengono creati i record DNS per Kubernetes, consulta Scoperta dei servizi basati su DNS di Kubernetes.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Abilita il DNS nell'ambito del cluster

Nel DNS dell'ambito del cluster, solo i nodi in esecuzione nel cluster GKE possono risolvere nomi dei servizi e i nomi dei servizi non sono in conflitto tra i cluster. Questo comportamento è uguale a kube-dns nei cluster GKE, il che significa di poter eseguire la migrazione di cluster da kube-dns all'ambito dei cluster Cloud DNS senza tempi di inattività o modifiche alle applicazioni.

Il seguente diagramma mostra in che modo Cloud DNS crea una zona DNS privata per un cluster GKE. Solo processi e pod in esecuzione sui nodi il cluster può risolvere i record DNS del cluster, perché solo i nodi sono nell'ambito DNS.

Pod su nodi diversi che risolvono i servizi all'interno del cluster GKE.
Diagramma: DNS nell'ambito del cluster

Abilita il DNS nell'ambito del cluster in un nuovo cluster

Cluster GKE Autopilot

Nuovi cluster Autopilot nella versione 1.25.9-gke.400, 1.26.4-gke.500 o in seguito per impostazione predefinita l'ambito del cluster Cloud DNS.

Cluster GKE Standard

Puoi creare un cluster GKE Standard con Cloud DNS ambito del cluster abilitato utilizzando gcloud CLI o la console Google Cloud:

gcloud

Crea un cluster utilizzando il flag --cluster-dns:

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

Sostituisci quanto segue:

Il flag --cluster-dns-scope=cluster è facoltativo nel comando perché cluster è il valore predefinito.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Nel riquadro di navigazione, in Cluster, fai clic su Networking.

  4. Nella sezione Provider DNS, fai clic su Cloud DNS.

  5. Seleziona Ambito del cluster.

  6. Configura il cluster in base alle tue esigenze.

  7. Fai clic su Crea.

Abilita il DNS nell'ambito del cluster in un cluster esistente

Cluster GKE Autopilot

Non puoi eseguire la migrazione di un cluster GKE Autopilot esistente da kube-dns all'ambito del cluster Cloud DNS. Per abilitare Cloud DNS nell'ambito del cluster, ricrea i cluster Autopilot nella versione 1.25.9-gke.400, 1.26.4-gke.500 o versioni successive.

Cluster GKE Standard

Puoi eseguire la migrazione di un cluster GKE Standard esistente da kube-dns all'ambito del cluster Cloud DNS utilizzando gcloud CLI o Console Google Cloud in un cluster GKE Standard.

Quando esegui la migrazione di un cluster esistente, i nodi al suo interno non utilizzano Cloud DNS come provider DNS finché non ricrei i nodi.

Dopo aver abilitato Cloud DNS per un cluster, le impostazioni si applicano solo se eseguire l'upgrade dei pool di nodi esistenti o aggiungere nuovi pool di nodi in un cluster Kubernetes. Quando esegui l'upgrade di un pool di nodi, i nodi vengono ricreati.

Puoi anche eseguire la migrazione di cluster in cui sono eseguite applicazioni interrompendo la comunicazione tra cluster abilitando Cloud DNS come provider DNS ogni pool di nodi separatamente. Un sottoinsieme di nodi è sempre operativo poiché alcuni pool di nodi utilizzano kube-dns, mentre altri pool di nodi utilizzano Cloud DNS.

Nei passaggi seguenti, abilita Cloud DNS per un cluster ed esegui l'upgrade dai pool di nodi. L'upgrade dei pool di nodi ricrea i nodi. I nodi quindi usare Cloud DNS per la risoluzione DNS anziché kube-dns.

gcloud

  1. Aggiorna il cluster esistente:

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

    Sostituisci quanto segue:

    La risposta è simile alla seguente:

    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)?
    

    Dopo la conferma, il controller Cloud DNS viene eseguito ma i tuoi pod non utilizzano Cloud DNS per la risoluzione DNS finché non esegui l'upgrade del pool di nodi o non aggiungi un nuovo nodo pool al cluster.

  2. Esegui l'upgrade dei pool di nodi nel cluster per utilizzare Cloud DNS:

    gcloud container clusters upgrade CLUSTER_NAME \
        --node-pool=POOL_NAME \
        --location=COMPUTE_LOCATION
    

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster.
    • POOL_NAME: il nome del pool di nodi di cui eseguire l'upgrade.

    Se il pool di nodi e il piano di controllo eseguono la stessa versione, esegui l'upgrade sul piano di controllo, come descritto Upgrade manuale del piano di controllo ed eseguire l'upgrade del pool di nodi.

    Conferma la risposta e ripeti questo comando per ogni pool di nodi nel in un cluster Kubernetes. Se il tuo cluster ha un pool di nodi, ometti il flag --node-pool.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster da modificare.

  3. In Networking, nel campo Provider DNS, fai clic su Modifica provider DNS.

  4. Fai clic su Cloud DNS.

  5. Fai clic su Ambito del cluster.

  6. Fai clic su Salva modifiche.

Abilita ambito VPC additivo di Cloud DNS

Questa sezione descrive i passaggi per abilitare o disabilitare l'additivo Cloud DNS nell'ambito VPC, come componente aggiuntivo dell'ambito del cluster Cloud DNS.

Abilita l'ambito VPC additivo di Cloud DNS in un nuovo cluster

Puoi abilitare il DNS con ambito VPC in un nuovo cluster GKE utilizzando gcloud CLI o la console Google Cloud.

Per Autopilot

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • UNIQUE_CLUSTER_DOMAIN: il nome di un dominio. Devi assicurarti questo nome è univoco all'interno del VPC perché GKE non conferma questo valore. Una volta impostato, questo valore non può essere modificato. Non devi utilizzare un dominio che termina con ".local", altrimenti potresti riscontrare DNS gli errori di risoluzione.

Per standard

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • UNIQUE_CLUSTER_DOMAIN: il nome di un dominio. Devi Assicurati che questo nome sia univoco all'interno del VPC perché GKE non conferma questo valore. Una volta impostato, questo valore non può essere modificato. Non devi utilizzare un dominio che termina con ".local", altrimenti potresti riscontrare DNS gli errori di risoluzione.

Abilita l'ambito VPC additivo di Cloud DNS in un cluster esistente

Per abilitare l'ambito VPC aggiuntivo di Cloud DNS in un cluster esistente, devi prima abilitare Cloud DNS per un cluster, quindi eseguire l'upgrade dei pool di nodi. L'upgrade dei pool di nodi ricrea i nodi. I nodi utilizzano quindi Risoluzione DNS di Cloud DNS anziché kube-dns.

Per abilitare l'ambito VPC aggiuntivo di Cloud DNS in un cluster esistente:

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • UNIQUE_CLUSTER_DOMAIN: il nome di un dominio. Devi assicurati che questo nome sia univoco all'interno del VPC GKE non conferma questo valore. Non puoi modificare questa impostazione dopo l'impostazione. Non devi utilizzare un dominio che termina con ".local", o potrebbero verificarsi errori di risoluzione DNS.

Abilita DNS in ambito VPC

Nel DNS in ambito VPC, i nomi DNS di un cluster sono risolvibili all'interno l'intero VPC. Qualsiasi client nel VPC può risolvere record DNS del cluster.

Il DNS in ambito VPC consente i seguenti casi d'uso:

  • Service Discovery headless per client non GKE all'interno dello stesso in un VPC.
  • Risoluzione del servizio GKE da cloud on-premise o di terze parti clienti. Per ulteriori informazioni, vedi Criterio del server in entrata.
  • Risoluzione del servizio in cui un client può decidere quale cluster comunicare usando il dominio DNS del cluster personalizzato.

Nel diagramma seguente, due cluster GKE utilizzano VPC con il DNS di ambito nello stesso VPC. Entrambi i cluster hanno un dominio DNS personalizzato, .cluster1 e .cluster2, anziché il dominio .cluster.local predefinito. R La VM comunica con il servizio di backend headless risolvendo backend.default.svc.cluster1. Cloud DNS risolve il servizio headless in i singoli IP dei pod nel servizio e la VM comunica direttamente IP dei pod.

Client che passano ai servizi headless dall'esterno del cluster GKE.
Diagramma: DNS nell'ambito VPC

Puoi eseguire questo tipo di risoluzione anche da altre reti quando sono connesse al VPC tramite Cloud Interconnect o Cloud VPN. Criteri del server DNS abilita i client delle reti connesse al VPC per in Cloud DNS, che include i servizi GKE se utilizza il DNS in ambito VPC.

Abilita il DNS in ambito VPC in un cluster esistente

La migrazione è supportata solo in GKE Standard e non su GKE Autopilot.

Cluster GKE Autopilot

Non puoi eseguire la migrazione di un cluster GKE Autopilot da kube-dns a nell'ambito VPC di Cloud DNS.

Cluster GKE Standard

Puoi eseguire la migrazione di un cluster GKE esistente da kube-dns a L'ambito VPC di Cloud DNS utilizzando gcloud CLI la console Google Cloud.

Dopo aver abilitato Cloud DNS per un cluster, le impostazioni si applicano solo se eseguire l'upgrade dei pool di nodi esistenti o aggiungere nuovi pool di nodi in un cluster Kubernetes. Quando esegui l'upgrade di un pool di nodi, i nodi vengono ricreati.

Nei passaggi seguenti, abilita Cloud DNS per un cluster ed esegui l'upgrade dai pool di nodi. L'upgrade dei pool di nodi ricrea i nodi. I nodi quindi usare Cloud DNS per la risoluzione DNS anziché kube-dns.

gcloud

  1. Aggiorna il cluster esistente:

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

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster.
    • COMPUTE_LOCATION: il Località di Compute Engine per il cluster.
    • CUSTOM_DOMAIN: il nome di un dominio. Devi assicurati che questo nome sia univoco all'interno del VPC GKE non conferma questo valore. Non puoi modificare questa impostazione dopo l'impostazione. Non devi utilizzare un dominio che termina con ".local", o potrebbero verificarsi errori di risoluzione DNS.

    La risposta è simile alla seguente:

    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)?
    

    Dopo la conferma, il controller Cloud DNS viene eseguito dal piano di controllo GKE. I tuoi pod non utilizzano Cloud DNS per Risoluzione DNS fino a quando non esegui l'upgrade del pool di nodi o non aggiungi nuovi pool di nodi nel cluster.

  2. Esegui l'upgrade dei pool di nodi nel cluster per utilizzare Cloud DNS:

    gcloud container clusters upgrade CLUSTER_NAME \
        --node-pool=POOL_NAME
    

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster.
    • POOL_NAME: il nome del pool di nodi di cui eseguire l'upgrade.

    Se il pool di nodi e il piano di controllo eseguono la stessa versione, esegui l'upgrade sul piano di controllo, come descritto Upgrade manuale del piano di controllo ed eseguire l'upgrade del pool di nodi.

    Conferma la risposta e ripeti questo comando per ogni pool di nodi nel in un cluster Kubernetes. Se il tuo cluster ha un pool di nodi, ometti il flag --node-pool.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster da modificare.

  3. In Networking, nel campo Provider DNS, fai clic su Modifica provider DNS.

  4. Fai clic su Cloud DNS.

  5. Fai clic su Ambito VPC.

  6. Fai clic su Salva modifiche.

Verifica Cloud DNS

Verifica che Cloud DNS per GKE funzioni correttamente per il tuo cluster:

  1. Verifica che i tuoi nodi utilizzino Cloud DNS connettendoti a un pod su un nodo ed eseguendo il comando cat /etc/resolv.conf:

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

    Sostituisci POD_NAME con il nome del pod.

    In base alla modalità cluster, l'output è simile al seguente:

    Cluster GKE Autopilot

    nameserver 169.254.20.10
    

    Poiché NodeLocal DNSCache è abilitata per impostazione predefinita in GKE Autopilot, NodeLocal DNSCache.

    Solo se nella cache locale non è presente una voce per il nome cercato, NodeLocal DNSCache inoltra la richiesta a Cloud DNS.

    Cluster GKE Standard

    nameserver 169.254.169.254
    

    Il pod utilizza 169.254.169.254 come nameserver, ovvero l'indirizzo IP del server di metadati dove il piano dati di Cloud DNS rimane in ascolto delle richieste sulla porta 53. I nodi non utilizzano più l'indirizzo del servizio kube-dns per il DNS e tutta la risoluzione DNS si verifica sul nodo locale.

    Se l'output è un indirizzo IP simile a 10.x.y.10, il pod usa kube-dns. Consulta le Risoluzione dei problemi per capire perché il tuo pod utilizza ancora kube-dns.

    Se l'output è 169.254.20.10, significa che hai abilitato NodeLocal DNSCache in del cluster, il pod utilizza NodeLocal DNSCache:

  2. Esegui il deployment di un'applicazione di esempio nel tuo cluster:

    kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
    
  3. Esposizione dell'applicazione di esempio con un servizio:

    kubectl expose pod dns-test --name dns-test-svc --port 8080
    
  4. Verifica che il deployment del servizio sia andato a buon fine:

    kubectl get svc dns-test-svc
    

    L'output è simile al seguente:

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

    Il valore di CLUSTER-IP è l'indirizzo IP virtuale del tuo cluster. In questo Ad esempio, l'indirizzo IP virtuale è 10.47.255.11.

  5. Verifica che il nome del tuo servizio sia stato creato come record nel Zona DNS per il cluster:

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

    Sostituisci PRIVATE_DNS_ZONE con il nome dell'account gestito zona DNS.

    L'output è simile al seguente:

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

Disabilita Cloud DNS per GKE

Cluster GKE Autopilot

Non puoi disabilitare Cloud DNS in un GKE Autopilot creato con Cloud DNS per impostazione predefinita. Consulta le requisiti per saperne di più sui cluster GKE Autopilot Cloud DNS per impostazione predefinita.

Cluster GKE Standard

Puoi disabilitare l'ambito del cluster Cloud DNS utilizzando gcloud CLI nella console Google Cloud in un cluster GKE Standard.

gcloud

Aggiorna il cluster per utilizzare kube-dns:

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

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic sul nome del cluster da modificare.

  3. In Networking, nel campo Provider DNS, fai clic su Modifica provider DNS.

  4. Fai clic su Kube-dns.

  5. Fai clic su Salva modifiche.

Disabilita ambito VPC additivo di Cloud DNS

Quando disabiliti l'ambito VPC additivo di Cloud DNS per il tuo , solo i record DNS nelle zone private collegate al cluster La rete VPC verrà eliminata. I record nelle zone DNS private per il cluster GKE rimarranno gestiti da Cloud DNS GKE, fino a quando il servizio headless non viene eliminato dal cluster.

Per disabilitare l'ambito VPC additivo di Cloud DNS, esegui questo comando:

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

Sostituisci CLUSTER_NAME con il nome del cluster.

In questo modo il tuo cluster con l'ambito cluster Cloud DNS rimarrà abilitato per fornire risoluzione DNS dall'interno del cluster.

Esegui la pulizia

Dopo aver completato gli esercizi in questa pagina, segui questa procedura per rimuovere ed evitare addebiti indesiderati sul tuo account:

  1. Elimina il servizio:

    kubectl delete service dns-test-svc
    
  2. Elimina il pod:

    kubectl delete Pod dns-test
    
  3. Puoi anche elimina il cluster.

Utilizza Cloud DNS con un VPC condiviso

Cloud DNS per GKE supporta il VPC condiviso sia per VPC e nell'ambito del cluster.

Il controller GKE crea una zona privata gestita progetto come cluster GKE.

L'account di servizio GKE per il cluster GKE non richiede Identity and Access Management (IAM) per DNS al di fuori del proprio progetto perché la zona gestita e il cluster GKE si trovano all'interno dello stesso progetto.

Più di un cluster per progetto di servizio

A partire dalle versioni GKE 1.22.3-gke.700, 1.21.6-gke.1500, puoi crea cluster in più progetti di servizio che fanno riferimento a un VPC nello stesso progetto host.

Se hai già dei cluster che utilizzano il VPC condiviso nell'ambito VPC di Cloud DNS, devi eseguirne manualmente la migrazione con seguenti passaggi:

  • Esegui l'upgrade dei cluster esistenti con VPC condiviso abilitato alla versione GKE 1.22.3-gke.700+ o 1.21.6-gke.1500+.
  • Esegui la migrazione del criterio di risposta dal progetto di servizio al progetto host. Tu devono eseguire questa migrazione una sola volta per rete VPC condiviso.

Puoi eseguire la migrazione del criterio di risposta utilizzando la console Google Cloud.

Nel progetto di servizio, segui questi passaggi:

  1. Vai alla pagina Zone Cloud DNS.

    Vai alle zone Cloud DNS

  2. Fai clic sulla scheda Zone del criterio di risposta.

  3. Fai clic sul criterio di risposta per la tua rete VPC. Puoi identificare il criterio di risposta attraverso la descrizione, che è simile "Criterio di risposta per i cluster GKE sulla rete NETWORK_NAME."

  4. Fai clic sulla scheda Utilizzato da.

  5. Accanto al nome del progetto host, fai clic su per rimuovere l'associazione di rete.

  6. Fai clic sulla scheda Regole del criterio di risposta.

  7. Seleziona tutte le voci della tabella.

  8. Fai clic su Rimuovi le regole del criterio di risposta.

  9. Fai clic su Elimina criterio di risposta.

Dopo aver eliminato il criterio di risposta, il controller DNS crea la risposta. automaticamente nel progetto host. Cluster di altri progetti di servizio condividi questo criterio di risposta.

Supporta domini stub personalizzati e server dei nomi upstream

Cloud DNS per GKE supporta domini stub personalizzati e upstream e i server dei nomi configurati con kube-dns ConfigMap. Questo supporto è per i cluster GKE Standard.

Cloud DNS converte i valori stubDomains e upstreamNameservers nelle zone di forwarding di Cloud DNS.

Problemi noti

Terraform prevede di ricreare il cluster Autopilot a causa di una modifica a dns_config

Se utilizzi terraform-provider-google o terraform-provider-google-beta, potrebbe verificarsi un problema in cui Terraform tenta di ricreare Autopilot. Questo errore si verifica perché i nuovi Autopilot versione 1.25.9-gke.400, 1.26.4-gke.500, 1.27.1-gke.400 o versioni successive utilizzano Cloud DNS come provider DNS anziché kube-dns.

Questo problema è risolto nella versione 4.80.0 del provider Terraform di Google Cloud.

Se non riesci ad aggiornare la versione di terraform-provider-google o terraform-provider-google-beta, puoi aggiungere lifecycle.ignore_changes a la risorsa per garantire che google_container_cluster ignori le modifiche apportate dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Risoluzione dei problemi

Per scoprire come abilitare il logging DNS, consulta Attivazione e disattivazione del logging per zone gestite private.

Per ulteriori informazioni sulla risoluzione dei problemi relativi al DNS, consulta Risoluzione dei problemi relativi al DNS in GKE.

Impossibile aggiornare il cluster esistente o creare un cluster con Cloud DNS abilitato

Assicurati di utilizzare la versione corretta. Cloud DNS per GKE richiede GKE 1.19 o versioni successive per i cluster che utilizzano l'ambito VPC, oppure GKE versione 1.24.7-gke.800, 1.25.3-gke.700 o successive per i cluster utilizzando l'ambito del cluster.

I pod utilizzano kube-dns anche dopo l'abilitazione di Cloud DNS su un cluster esistente

Assicurati di aver eseguito l'upgrade o la creazione di nuovi pool di nodi dopo aver abilitato Cloud DNS nella in un cluster Kubernetes. Finché questo passaggio non viene completato, i pod continuano a utilizzare kube-dns.

Il pod non è in grado di risolvere le ricerche DNS

  1. Verifica che il pod utilizzi Cloud DNS connettendoti a un pod ed eseguendo il comando cat /etc/resolv.conf:

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

    Sostituisci POD_NAME con il nome del pod.

    L'output è simile al seguente:

    nameserver 169.254.169.254
    

    Se l'output è un indirizzo IP simile a 10.x.y.10 o 34.118.224.10 (solo nei cluster GKE Autopilot con versione 1.27 e successive), il pod usa kube-dns. Se l'output è 169.254.20.10, il pod sta usando NodeLocal DNSCache.

  2. Verifica che la zona gestita esista e contenga la voce DNS necessaria:

    gcloud dns managed-zones list --format list
    

    L'output è simile al seguente:

     - 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
    

    Il valore name nella risposta indica che Google Cloud ha creato una zona privata denominata gke-cluster1-aa94c1f9-dns.

  3. Verifica che Cloud DNS contenga le voci per il tuo cluster:

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

    Sostituisci quanto segue:

    • ZONE_NAME: il nome della zona privata.
    • SERVICE_NAME: il nome del servizio.

    L'output mostra che Cloud DNS contiene un record A per il dominio dns-test.default.svc.cluster.local. e l'indirizzo IP del tuo cluster, 10.47.255.11:

    dns-test.default.svc.cluster.local.                A     30     10.47.255.11
    
  4. Abilita il logging di Cloud DNS per monitorare query. Ogni voce di log contiene informazioni sulla query, tra cui una latenza di pochi millisecondi.

Le ricerche DNS sui nodi non riescono dopo aver abilitato Cloud DNS su un cluster

Se abiliti Cloud DNS con ambito in un cluster GKE che ha domini stub personalizzati o server dei nomi upstream, la configurazione personalizzata si applica nodi e pod nel cluster perché Cloud DNS non è in grado di distinguere tra le richieste DNS di pod e nodi. Le ricerche DNS sui nodi potrebbero non riuscire se un server upstream personalizzato non è in grado di risolvere le query.

Impossibile aggiornare il cluster esistente o creare un cluster con l'ambito VPC aggiuntivo di Cloud DNS abilitato

Assicurati di utilizzare la versione corretta. L'ambito VPC additivo Cloud DNS richiede GKE versione 1.28 o successiva.

Il pod non è in grado di risolvere le ricerche DNS

  1. Verifica che il pod utilizzi Cloud DNS connettendoti a un pod ed eseguendo il comando cat /etc/resolv.conf:

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

    Sostituisci POD_NAME con il nome del pod.

    L'output è simile al seguente:

    nameserver 169.254.169.254
    

    Se l'output è un indirizzo IP simile a 10.x.y.10 o 34.118.224.10 (solo nei cluster GKE Autopilot con versione 1.27 e successive), il pod usa kube-dns. Se l'output è 169.254.20.10, il pod sta usando NodeLocal DNSCache.

  2. Verifica che la zona gestita esista e contenga la voce DNS necessaria:

    gcloud dns managed-zones list --format list
    

    L'output è simile al seguente:

    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
    

    Il valore name nella risposta indica che Google Cloud ha creato una zona privata denominata gke-cluster1-aa94c1f9-dns.

  3. Verifica che Cloud DNS contenga le voci per il tuo cluster in entrambe le zone ManagedZone:

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

    Sostituisci quanto segue:

    • ZONE_NAME: il nome della zona privata.
    • SERVICE_NAME: il nome del servizio.

    L'output è simile al seguente:

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

    Il valore name nella risposta indica che Google Cloud ha creato una zona privata denominata gke-cluster1-aa94c1f9-dns.

  4. Per le ricerche DNS inverse, verifica che Cloud DNS contenga voci per il tuo cluster in ResponsePolicies:

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

    L'output è simile al seguente:

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

    Il valore name nella risposta indica che Google Cloud ha creato una zona privata denominata gke-cluster1-aa94c1f9-rp.

  5. Per le ricerche DNS inverse, verifica che Cloud DNS contenga voci per il tuo cluster in ResponsePolicies:

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

    Sostituisci ZONE_NAME con il nome della zona privata.

    L'output è simile al seguente:

      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.
    

Passaggi successivi