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 consente ai client esterni a un cluster di risolvere e raggiungere direttamente i servizi Kubernetes. Devi comunque esporre i servizi esterni utilizzando un bilanciatore del carico e registrare i relativi indirizzi IP esterni del cluster nella tua 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, consulta Configurazione di un deployment personalizzato di kube-dns.

Come funziona Cloud DNS per GKE

Cloud DNS può essere utilizzato come provider DNS per GKE, fornendo la risoluzione DNS dei pod e dei servizi con DNS gestito che non richiede un provider DNS ospitato in cluster. I record DNS per i pod e i servizi vengono eseguiti automaticamente in Cloud DNS per l'indirizzo IP del cluster, i servizi headless e i servizi di nomi esterni.

Cloud DNS supporta la specifica DNS di Kubernetes completa 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 le regole del criterio di risposta.

L'utilizzo di Cloud DNS come provider DNS per GKE offre molti vantaggi rispetto al DNS ospitato nel cluster:

  • Rimuove il sovraccarico della gestione del server DNS ospitato nel cluster. Cloud DNS non richiede scalabilità, monitoraggio o gestione delle istanze DNS perché è un servizio completamente gestito ospitato nell'infrastruttura di Google altamente scalabile.
  • Risoluzione locale delle query DNS su ogni nodo GKE. Come NodeLocal DNSCache, Cloud DNS memorizza nella cache le risposte DNS localmente, fornendo una risoluzione DNS a bassa latenza e ad alta scalabilità.

Architettura

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

Il seguente diagramma mostra come il piano di controllo e il piano di dati di Cloud DNS risolvono 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. clouddns-controller crea un record DNS per il servizio backend.

Il pod frontend invia una richiesta DNS per risolvere l'indirizzo IP del servizio chiamato backend al server di metadati locale di Compute Engine all'indirizzo 169.254.169.254. Il server dei metadati viene eseguito localmente sul nodo e invia le mancate corrispondenze della cache a Cloud DNS.

Il piano dati di Cloud DNS viene eseguito localmente in ogni nodo GKE o istanza di macchina virtuale (VM) Compute Engine. A seconda del tipo di servizio Kubernetes, Cloud DNS risolve il nome del servizio nel relativo indirizzo IP virtuale per i servizi ClusterIP o nell'elenco di indirizzi IP degli endpoint per i servizi headless.

Dopo che il pod frontend ha risolto l'indirizzo IP, può inviare traffico al servizio backend e a tutti i pod da cui dipende il servizio.

Ambiti DNS

Cloud DNS dispone dei seguenti ambiti DNS. Un cluster non può funzionare in più modalità contemporaneamente.

  • Ambito del cluster GKE: i record DNS sono risolvibili solo all'interno del cluster, come per 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 nomi DNS sono visibili solo all'interno del cluster e non si sovrappongono o sono in conflitto con i nomi DNS *.cluster.local di altri cluster GKE nello stesso progetto. Questa è la modalità predefinita.

    • Ambito VPC additivo Cloud DNS:

      L'ambito VPC additivo di Cloud DNS è una funzionalità facoltativa che estende l'ambito del cluster GKE per rendere i servizi headless risolvibili da altre risorse nel VPC, ad esempio le VM Compute Engine o i client on-premise connessi utilizzando Cloud VPN o Cloud Interconnect. L'ambito VPC additivo è una modalità aggiuntiva abilitata insieme all'ambito cluster che puoi abilitare o disattivare nel tuo cluster senza influire sul tempo di attività o sulle funzionalità DNS (ambito cluster).

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

La seguente tabella elenca le differenze tra gli ambiti DNS:

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 dei problemi relativi ai servizi headless Risolvibile all'interno del cluster Risolubile all'interno del cluster utilizzando "cluster.local" e nella VPC utilizzando il suffisso del cluster Risolvibile all'interno del cluster e nella VPC utilizzando il suffisso del cluster
Requisito di dominio univoco No. Viene utilizzato il valore predefinito "*.cluster.local" Sì, devi impostare un dominio personalizzato univoco Sì, devi impostare un dominio personalizzato univoco
Configurazione di Setup Predefinito, nessun passaggio aggiuntivo Facoltativo al momento della creazione del cluster
Può essere attivato/disattivato in qualsiasi momento		 Deve essere configurato durante la creazione del cluster

Risorse Cloud DNS

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

Ambito Zona di ricerca in avanti Zona di ricerca inversa
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 basata su VPC per cluster (zona globale) 		1 zona di criteri di risposta per cluster per zona Compute Engine (nella regione) per cluster (zona globale)
1 zona di criteri di risposta basata su 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 in avanti Zona di ricerca inversa
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 basate su cluster
gke-NETWORK_NAME_HASH-rp per le zone basate su cluster
Ambito VPC gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-NETWORK_NAME_HASH-rp

Oltre alle zone menzionate nella tabella precedente, il controller Cloud DNS crea le seguenti zone nel progetto, a seconda della 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
Nameserver upstream personalizzati Inoltro (zona globale) gke-CLUSTER_NAME-CLUSTER_HASH-upstream

Per scoprire di più su come creare domini stub o server dei nomi upstream personalizzati, consulta Aggiunta di risolutori personalizzati per i domini stub.

Zone gestite e zone di inoltro

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, il controller Cloud DNS 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 crea una zona di inoltro.

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

Prezzi

Quando Cloud DNS è il provider DNS per i cluster GKE Standard, le query DNS provenienti dai pod all'interno del cluster GKE vengono fatturate in base ai prezzi di Cloud DNS.

Le query a una zona DNS basata su VPC gestita da GKE vengono fatturate utilizzando i prezzi standard di Cloud DNS.

Requisiti

L'API Cloud DNS deve essere abilitata nel progetto.

Cloud DNS per GKE ha i seguenti requisiti per l'ambito del cluster:

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

Cloud DNS per GKE ha i seguenti requisiti per l'ambito VPC additivo:

  • GKE versione 1.28 o successive.
  • Versione 471.0.0 di Google Cloud CLI.
  • Il cluster GKE deve utilizzare l'ambito del cluster Cloud DNS come provider DNS predefinito.

Cloud DNS per GKE ha i seguenti requisiti per l'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 progetto.

Restrizioni e limitazioni

Si applicano le seguenti limitazioni:

  • L'ambito VPC non è supportato nei cluster Autopilot, è supportato solo l'ambito cluster. Se devi risolvere i nomi dei servizi headless in esecuzione nei cluster GKE Autopilot, devi utilizzare l'ambito VPC additivo.
  • Cloud DNS non è conforme a un regime di conformità di livello di impatto 4 (IL4). Cloud DNS per GKE non può essere utilizzato in un carico di lavoro garantito con un regime di conformità IL4. Devi utilizzare kube-dns in questo tipo di ambiente regolamentato. Per i cluster GKE Autopilot, la selezione di kube-dns o Cloud DNS viene eseguita automaticamente in base al tuo regime di conformità.
  • Le modifiche manuali alle zone DNS private gestite non sono supportate e vengono sostituite dal controller Cloud DNS. Le modifiche ai record DNS in queste zone non vengono mantenute al riavvio del controller.
  • Non puoi modificare l'ambito DNS in un cluster dopo aver impostato l'ambito con il flag --cluster-dns-scope. Se devi modificare l'ambito DNS, ricrea il cluster con un ambito DNS diverso.
  • I domini stub personalizzati e le configurazioni dei server DNS a monte si applicano alle configurazioni DNS di pod e nodi. I pod che utilizzano la rete dell'host o i processi che vengono eseguiti direttamente sull'host utilizzano anche il dominio stub e le configurazioni dei server dei nomi a monte. Questa opzione è supportata solo in Standard.
  • I domini stub personalizzati e i server dei nomi upstream configurati tramite il ConfigMap kube-dns vengono applicati automaticamente a Cloud DNS per il DNS a livello di cluster. Il DNS con ambito VPC ignora il ConfigMap kube-dns e devi applicare queste configurazioni direttamente su Cloud DNS. Questa opzione è supportata solo in Standard.
  • Non esiste un percorso di migrazione da kube-dns all'ambito VPC, l'operazione è interattiva. Ricrea il cluster quando passi da kube-dns all'ambito VPC o viceversa.
  • Per l'ambito VPC, l'intervallo di indirizzi IP secondario per i servizi non deve essere condiviso con altri cluster nella subnet.
  • Per l'ambito VPC, il criterio di risposta associato a un record PTR è associato alla rete VPC. Se sono presenti altri criteri di risposta associati alla rete del cluster, la risoluzione dei record PTR non va a buon fine per gli indirizzi IP dei servizi Kubernetes.
  • Se provi a creare un servizio senza testa con un numero di pod superiore alla quota consentita, Cloud DNS non crea set di record o record per il servizio.

Quote

Cloud DNS utilizza le quote per limitare il numero di risorse che GKE può creare per le voci DNS. Le quote e i limiti di Cloud DNS potrebbero essere diversi dalle limitazioni di kube-dns per il tuo progetto.

Quando utilizzi Cloud DNS per GKE, a ogni zona gestita del progetto vengono applicate le seguenti quote predefinite:

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 1.24-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 create per cluster contribuiscono ai limiti delle risorse Cloud DNS, come descritto nella seguente tabella:

Limite Contributo al limite
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 su altri tipi di servizi.
Numero di regole per criterio di risposta Per l'ambito del cluster, il numero di servizi più il numero di endpoint di servizio headless con hostname validi per cluster. Per l'ambito VPC, il numero di servizi più il numero di endpoint headless con gli hostname di tutti i cluster nel VPC.

Per scoprire di più su come vengono creati i record DNS per Kubernetes, consulta Service Discovery basato su DNS di Kubernetes.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

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

Attivare il DNS con ambito cluster

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

Il seguente diagramma mostra come Cloud DNS crea una zona DNS privata per un cluster GKE. Solo i processi e i pod in esecuzione sui nodi del cluster possono risolvere i record DNS del cluster, perché solo i nodi sono in ambito DNS.

Pod su nodi diversi che risolvono i servizi all'interno del cluster GKE.
Diagramma: DNS a livello di cluster

Attivare il DNS a livello di cluster in un nuovo cluster

Cluster GKE Autopilot

Per i nuovi cluster Autopilot nella versione 1.25.9-gke.400, 1.26.4-gke.500 o successive, viene utilizzato per impostazione predefinita l'ambito del cluster Cloud DNS.

Cluster GKE Standard

Puoi creare un cluster GKE Standard con l'ambito del cluster Cloud DNS abilitato utilizzando la 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 cluster.

  6. Configura il cluster in base alle tue esigenze.

  7. Fai clic su Crea.

Attivare il DNS a livello di 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 attivare l'ambito del cluster Cloud DNS, ricrea i cluster Autopilot nella versione 1.25.9-gke.400, 1.26.4-gke.500 o 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 la console Google Cloud in un cluster GKE Standard.

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

Dopo aver attivato Cloud DNS per un cluster, le impostazioni vengono applicate solo se esegui l'upgrade dei pool di nodi esistenti o se aggiungi nuovi pool di nodi al cluster. Quando esegui l'upgrade di un pool di nodi, i nodi vengono ricreati.

Puoi anche eseguire la migrazione dei cluster con applicazioni in esecuzione senza interrompere la comunicazione del cluster attivando Cloud DNS come provider DNS in ogni pool di nodi separatamente. Un sottoinsieme di nodi è operativo in ogni momento perché alcuni pool di nodi utilizzano kube-dns e altri Cloud DNS.

Nei passaggi seguenti, attivi Cloud DNS per un cluster ed esegui l'upgrade dei tuoi pool di nodi. L'upgrade dei pool di nodi ricrea i nodi. I nodi useranno quindi 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 sul piano di controllo GKE, ma i pod non utilizzano Cloud DNS per la risoluzione DNS finché non esegui l'upgrade del pool di nodi o non aggiungi nuovi pool di nodi 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 prima l'upgrade del piano di controllo, come descritto in Eseguire l'upgrade manuale del piano di controllo, quindi esegui l'upgrade del pool di nodi.

    Conferma la risposta e ripeti questo comando per ogni pool di nodi nel cluster. Se il cluster ha un solo 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 cluster.

  6. Fai clic su Salva modifiche.

Attivare l'ambito VPC additivo di Cloud DNS

Questa sezione descrive i passaggi per attivare o disattivare l'ambito VPC additivo di Cloud DNS, come componente aggiuntivo dell'ambito cluster di Cloud DNS.

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

Puoi abilitare il DNS a livello di VPC in un nuovo cluster GKE utilizzando la 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 che questo nome sia univoco all'interno della VPC perché GKE non conferma questo valore. Non puoi modificare questo valore dopo averlo impostato. Non devi utilizzare un dominio che termina con ".local", altrimenti potresti riscontrare errori di risoluzione DNS.

Per Standard

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --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 assicurarti che questo nome sia univoco all'interno della VPC perché GKE non conferma questo valore. Non puoi modificare questo valore dopo averlo impostato. Non devi utilizzare un dominio che termina con ".local", altrimenti potresti riscontrare errori di risoluzione DNS.

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

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

Per attivare l'ambito VPC additivo 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 assicurarti che questo nome sia univoco all'interno della VPC perché GKE non conferma questo valore. Non puoi modificare questo valore dopo averlo impostato. Non devi utilizzare un dominio che termina con ".local", altrimenti potresti riscontrare errori di risoluzione DNS.

Attivare il DNS con ambito VPC

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

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

  • Service Discovery headless per i client non GKE all'interno della stessa VPC.
  • Risoluzione del servizio GKE da client cloud on-premise o di terze parti. Per ulteriori informazioni, consulta Criteri del server in entrata.
  • Risoluzione dei servizi in cui un client può decidere con quale cluster comunicare utilizzando il dominio DNS del cluster personalizzato.

Nel seguente diagramma, due cluster GKE utilizzano DNS di ambito VPC nella stessa VPC. Entrambi i cluster hanno un dominio DNS personalizzato,.cluster1 e .cluster2, anziché il dominio predefinito .cluster.local. Una VM comunica con il servizio di backend headless risolvendo backend.default.svc.cluster1. Cloud DNS risolve il servizio senza interfaccia negli indirizzi IP dei singoli pod del servizio e la VM comunica direttamente con gli indirizzi IP dei pod.

Client che risolvono in servizi headless dall'esterno del cluster GKE.
Diagramma: DNS ambito VPC

Puoi eseguire questo tipo di risoluzione anche da altre reti quando sei connesso al VPC tramite Cloud Interconnect o Cloud VPN. I criteri dei server DNS consentono ai client delle reti connesse alla VPC di risolvere i nomi in Cloud DNS, inclusi i servizi GKE se il cluster utilizza il DNS a livello di VPC.

Attivare DNS nell'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 all'ambito VPC Cloud DNS.

Cluster GKE Standard

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

Dopo aver attivato Cloud DNS per un cluster, le impostazioni vengono applicate solo se esegui l'upgrade dei pool di nodi esistenti o se aggiungi nuovi pool di nodi al cluster. Quando esegui l'upgrade di un pool di nodi, i nodi vengono ricreati.

Nei passaggi seguenti, attivi Cloud DNS per un cluster ed esegui l'upgrade dei tuoi pool di nodi. L'upgrade dei pool di nodi ricrea i nodi. I nodi useranno quindi 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: la posizione Compute Engine per il cluster.
    • CUSTOM_DOMAIN: il nome di un dominio. Devi assicurarti che questo nome sia univoco all'interno della VPC perché GKE non conferma questo valore. Non puoi modificare questo valore dopo averlo impostato. Non devi utilizzare un dominio che termina con ".local", altrimenti potresti riscontrare 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 sul piano di controllo GKE. I pod non utilizzano Cloud DNS per la risoluzione DNS finché non esegui l'upgrade del pool di nodi o non aggiungi nuovi pool di nodi 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

    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 prima l'upgrade del piano di controllo, come descritto in Eseguire l'upgrade manuale del piano di controllo, quindi esegui l'upgrade del pool di nodi.

    Conferma la risposta e ripeti questo comando per ogni pool di nodi nel cluster. Se il cluster ha un solo 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 e 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.

    A seconda della modalità del cluster, l'output è simile al seguente:

    Cluster GKE Autopilot

    nameserver 169.254.20.10

    Poiché NodeLocal DNSCache è attivo per impostazione predefinita in GKE Autopilot, il pod utilizza NodeLocal DNSCache.

    Solo quando la cache locale non contiene 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 in cui il piano dati di Cloud DNS ascolta le richieste sulla porta 53. I nodi non utilizzano più l'indirizzo del servizio kube-dns per la risoluzione DNS e tutta la risoluzione DNS avviene sul nodo locale.

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

    Se l'output è 169.254.20.10, significa che hai attivato NodeLocal DNSCache nel tuo cluster, quindi il pod utilizza NodeLocal DNSCache.

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

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

  3. Esponi l'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 cluster. In questo esempio, l'indirizzo IP virtuale è 10.47.255.11.

  5. Verifica che il nome del servizio sia stato creato come record nella zona DNS privata per il tuo 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 della zona DNS gestita.

    L'output è simile al seguente:

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

Disattivare Cloud DNS per GKE

Cluster GKE Autopilot

Non puoi disattivare Cloud DNS in un cluster GKE Autopilot creato con Cloud DNS per impostazione predefinita. Consulta i requisiti per saperne di più sui cluster GKE Autopilot che utilizzano Cloud DNS per impostazione predefinita.

Cluster GKE Standard

Puoi disattivare l'ambito del cluster Cloud DNS utilizzando la gcloud CLI o la console Google Cloud in un cluster GKE Standard.

gcloud

Aggiorna il cluster in modo che utilizzi 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.

Dopo aver disattivato Cloud DNS per i cluster standard, aggiorna i pool di nodi associati ai tuoi cluster. In alternativa, puoi creare un nuovo pool di nodi e pianificare il tuo carico di lavoro al suo interno. Se non aggiorni i pool di nodi, lo spazio dei nomi DNS continuerà a puntare a Cloud DNS, non a kube-dns.

gcloud

Aggiorna il pool di nodi in modo che utilizzi kube-dns:

gcloud container clusters upgrade dns --node-pool=DEFAULT_POOL \
    --cluster-version=VERSION \
    --region=REGION

Disattivare l'ambito VPC additivo di Cloud DNS

Quando disattivi l'ambito VPC additivo di Cloud DNS per il tuo cluster, verranno eliminati solo i record DNS nelle zone private collegate alla rete VPC. I record nelle zone DNS private per il cluster GKE rimarranno gestiti da Cloud DNS per GKE finché il servizio headless non verrà eliminato dal cluster.

Per disattivare l'ambito VPC additivo di Cloud DNS, esegui il seguente comando:

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

Sostituisci CLUSTER_NAME con il nome del cluster.

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

Esegui la pulizia

Dopo aver completato gli esercizi in questa pagina, segui questi passaggi per rimuovere le risorse 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 eliminare il cluster.

Utilizzare Cloud DNS con VPC condiviso

Cloud DNS per GKE supporta VPC condiviso sia per l'ambito VPC sia per l'ambito cluster.

Il controller GKE crea una zona privata gestita nello stesso progetto del cluster GKE.

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

Più di un cluster per progetto di servizio

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

Se hai già cluster che utilizzano VPC condiviso e ambito VPC Cloud DNS, devi eseguirne la migrazione manualmente seguendo i passaggi riportati di seguito:

  • Esegui l'upgrade dei cluster esistenti in cui è abilitato VPC condiviso alla versione GKE 1.22.3-gke.700 o successiva o 1.21.6-gke.1500 o successiva.
  • Esegui la migrazione del criterio di risposta dal progetto di servizio al progetto host. Devi eseguire questa migrazione solo una volta per rete VPC condiviso.

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

Esegui i seguenti passaggi nel progetto di servizio:

  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 dalla descrizione, simile a "Criterio di risposta per i cluster GKE sulla rete NETWORK_NAME".

  4. Fai clic sulla scheda In uso da.

  5. Accanto al nome del progetto host, fai clic su per rimuovere il vincolo di rete.

  6. Fai clic sulla scheda Regole 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 lo crea automaticamente nel progetto host. I cluster di altri progetti di servizi condividono questo criterio di risposta.

Supporta domini stub personalizzati e server dei nomi upstream

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

Cloud DNS traduce i valori stubDomains e upstreamNameservers in zone di inoltro Cloud DNS.

Problemi noti

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

Se utilizzi terraform-provider-google o terraform-provider-google-beta, potresti riscontrare un problema in cui Terraform tenta di ricreare un cluster Autopilot. Questo errore si verifica perché i cluster Autopilot appena creati che eseguono la versione 1.25.9-gke.400, 1.26.4-gke.500, 1.27.1-gke.400 o successive utilizzano Cloud DNS come provider DNS anziché kube-dns.

Questo problema è stato 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 alla risorsa per assicurarti che google_container_cluster ignori le modifiche apportate a dns_config:

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

Risoluzione DNS non riuscita dopo la migrazione da kube-dns a Cloud DNS con NodeLocal DNSCache abilitato

Questa sezione descrive un problema noto presente nei cluster GKE in Cloud DNS con NodeLocal DNSCache nell'ambito cluster.

Dopo la migrazione da kube-DNS a Cloud DNS con NodeLocal DNSCache abilitato sul cluster, il cluster potrebbe presentare errori di risoluzione intermittenti.

Quando utilizzi kube-dns con NodeLocal DNSCache abilitato nel cluster, NodeLocal DNSCache è configurato per ascoltare su entrambi gli indirizzi (indirizzo NodeLocal DNSCache e indirizzo kube-dns).

Per controllare lo stato di NodeLocal DNSCache, esegui il seguente comando:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

L'output è simile al seguente:

    bind 169.254.20.10 x.x.x.10
    bind 169.254.20.10 x.x.x.10

Dopo aver aggiornato il cluster a Cloud DNS, la configurazione di NodeLocal DNSCache viene modificata. Controlla NodeLocal DNSCache:

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

L'output è simile al seguente:

    bind 169.254.20.10
    bind 169.254.20.10

Il seguente flusso di lavoro spiega le voci nel file resolv.conf durante la migrazione e la ricreazione dei nodi:

Prima della migrazione

  • I pod hanno resolv.conf configurato per l'IP kube-dns (ad es. x.x.x.10).
  • I pod node-local-cache ascoltano su entrambi gli indirizzi (bind 169.254.20.10 x.x.x.10) e intersecano le richieste DNS provenienti dai pod.
  • NodeLocal DNSCache funziona come una cache e i pod kube-dns vengono sottoposti a poco stress.

Dopo la migrazione

  • Dopo l'aggiornamento del piano di controllo per l'utilizzo di Cloud DNS, i pod hanno ancora resolv.conf configurato per l'IP kube-dns (ad es. x.x.x.10). Questa configurazione rimane perché GKE richiede la ricreazione dei nodi per utilizzare 169.254.20.10 .La configurazione di Cloud DNS richiede 169.254.20.10
  • I pod Node-local-cache ascoltano solo sull'indirizzo NodeLocal DNSCache (associazione 169.254.20.10). La richiesta non viene inviata ai pod Node-local-cache.
  • Tutte le richieste provenienti dai pod vengono inviate direttamente ai pod kube-dns. Questa configurazione genera un traffico elevato sui pod.

Dopo la ricreazione dei nodi o l'upgrade del pool di nodi

  • I pod hanno resolv.conf configurato per l'indirizzo IP di NodeLocal DNSCache (169.254.20.10).
  • I pod node-local-cache ascoltano solo l'indirizzo NodeLocal DNSCache (associazione 169.254.20.10) e ricevono richieste DNS dai pod su questo indirizzo IP.

Quando i node pool utilizzano l'IP kube-dns in resolv.conf prima della ricreazione del pool di nodi, un aumento del traffico delle query DNS aumenta anche il traffico sui pod kube-dns, causando un errore intermittente delle richieste DNS. Per ridurre al minimo gli errori, devi pianificare questa migrazione durante i periodi di inattività.

Risoluzione dei problemi

Per informazioni sulla risoluzione dei problemi di Cloud DNS, consulta le seguenti pagine:

Passaggi successivi