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 esternamente utilizzando un bilanciatore del carico e registrare i relativi indirizzi IP esterni del cluster nell'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 di pod e servizi con DNS gestito che non richiede un provider DNS ospitato nel cluster. I record DNS per i pod e i servizi vengono automaticamente sottoposti a provisioning in Cloud DNS per l'indirizzo IP del cluster, i servizi headless e i servizi di nomi esterni.

Cloud DNS supporta l'intera 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 le regole della policy di risposta.

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

• Elimina l'overhead 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 Google altamente scalabile.
• Risoluzione locale delle query DNS su ogni nodo GKE. Simile a NodeLocal DNSCache, Cloud DNS memorizza nella cache localmente le risposte DNS, fornendo una risoluzione DNS a bassa latenza e ad alta scalabilità.
• Integrazione con Google Cloud Observability per il monitoraggio e la registrazione dei log DNS. Per saperne di più, vedi Attivare e disattivare la registrazione per le zone gestite private.

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 dati di Cloud DNS risolvono i 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 denominato 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 gli errori della cache a Cloud DNS.

Il piano dati di Cloud DNS viene eseguito localmente all'interno di 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 suo indirizzo IP virtuale, per i servizi Cluster IP, o nell'elenco degli indirizzi IP endpoint, per i servizi headless.

Dopo che il pod frontend risolve l'indirizzo IP, può inviare traffico al servizio backend e a tutti i pod dietro il servizio.

Ambiti DNS

Cloud DNS ha i seguenti ambiti DNS. Un cluster non può operare in più modalità contemporaneamente.

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

  • Ambito VPC additivo di Cloud DNS:

    L'ambito VPC aggiuntivo di Cloud DNS è una funzionalità facoltativa che estende l'ambito del cluster GKE per rendere risolvibili i servizi headless da altre risorse nel VPC, ad esempio VM Compute Engine o client on-premise connessi tramite Cloud VPN o Cloud Interconnect. L'ambito VPC additivo è una modalità aggiuntiva che viene abilitata insieme all'ambito cluster e che puoi abilitare o disabilitare nel cluster senza influire sull'uptime o sulla 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 del VPC. Questa modalità riduce l'attrito della comunicazione tra le risorse GKE e non GKE.

La seguente tabella elenca le differenze tra gli ambiti DNS:

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.

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

Oltre alle zone menzionate nella tabella precedente, il controller Cloud DNS crea le seguenti zone nel tuo progetto, a seconda della configurazione:

Per scoprire di più su come creare domini stub personalizzati o server dei nomi upstream personalizzati, consulta Aggiungere resolver personalizzati per 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 DNS upstream utilizzando una zona gestita con il nome DNS ..

Prezzi

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

Le query a una zona DNS con ambito VPC gestita da GKE vengono fatturate in base ai prezzi standard di Cloud DNS.

Requisiti

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

Cloud DNS per GKE presenta i seguenti requisiti per l'ambito cluster

• Per Standard, GKE 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 successive.
• Google Cloud CLI versione 411.0.0 o successive.

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

• GKE 1.28.3-gke.1430000 o versioni successive.
• Google Cloud CLI versione 503.0.0 o successive.
• 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 1.19 o versioni successive.
• Google Cloud CLI versione 364.0.0 o successive.
• L'API Cloud DNS deve essere abilitata nel tuo progetto.

Limitazioni e restrizioni

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.

• Puoi abilitare i cluster GKE Autopilot con ambito VPC aggiuntivo solo al momento della creazione del cluster. L'abilitazione o la disabilitazione dell'ambito VPC additivo nei cluster GKE Autopilot esistenti non è supportata.

• Cloud DNS per GKE non è disponibile per Assured Workloads con un regime di conformità IL4. kube-dns è forzato in questi ambienti regolamentati.

• Le modifiche manuali alle zone DNS private gestite non sono supportate e vengono sovrascritte dal controller Cloud DNS. Le modifiche ai record DNS in queste zone non vengono mantenute al riavvio del controller.

• Dopo aver abilitato Cloud DNS per GKE in un cluster, kube-dns continua a essere eseguito nel cluster. Puoi disattivare kube-dns scalando a zero il deployment e il gestore della scalabilità automatica di kube-dns.

• Non puoi modificare l'ambito DNS in un cluster dopo averlo impostato con il flag --cluster-dns-scope. Se devi modificare l'ambito DNS, ricrea il cluster con un ambito DNS diverso.

• Si applicano limitazioni alle risorse Cloud DNS. In particolare, è possibile associare al massimo una zona di policy di risposta a una rete VPC alla volta. Per la creazione di cluster con ambiti VPC e VPC aggiuntivi non riesce se esiste già una zona di criteri di risposta che non segue la convenzione di denominazione associata alla rete VPC del cluster.

• Le configurazioni dei domini stub personalizzati e dei server DNS upstream si applicano alle configurazioni DNS di pod e nodi. I pod che utilizzano il networking host o i processi eseguiti direttamente sull'host utilizzano anche le configurazioni del dominio stub e del nameserver upstream. Questa funzionalità è supportata solo in Standard.

• I domini stub personalizzati e i nameserver upstream configurati tramite kube-dns Configmap vengono applicati automaticamente a Cloud DNS per il DNS con ambito cluster. Il DNS con ambito VPC ignora ConfigMap kube-dns e devi applicare queste configurazioni direttamente su Cloud DNS. Questa funzionalità è supportata solo in Standard.

• Non esiste un percorso di migrazione da kube-dns all'ambito VPC, l'operazione è distruttiva. Ricrea il cluster quando passi da kube-dns all'ambito VPC o viceversa.

• Per l'ambito VPC, l'intervallo di indirizzi IP secondari per i servizi non deve essere condiviso con altri cluster nella stessa subnet.

• Per l'ambito VPC, la policy di risposta associata a un record PTR è collegata alla rete VPC. Se alla rete del cluster sono associate altre norme di risposta, la risoluzione del record PTR non va a buon fine per gli indirizzi IP del servizio Kubernetes.

• Se provi a creare un servizio headless 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 per 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 tuo progetto vengono applicate le seguenti quote predefinite:

Limiti delle risorse

Le risorse Kubernetes che crei per cluster contribuiscono ai limiti delle risorse Cloud DNS, come descritto nella tabella seguente:

Per saperne di più su come vengono creati i record DNS per Kubernetes, consulta Service Discovery basata sul 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à, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

• Abilita l'API Cloud DNS nel tuo progetto:

  Abilita l'API Cloud DNS

Attiva DNS con ambito cluster

Nel DNS con ambito 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 downtime o modifiche alle tue 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 si trovano nell'ambito DNS.

Abilitare il DNS con ambito cluster in un nuovo cluster

Cluster GKE Autopilot

I nuovi cluster Autopilot nella versione 1.25.9-gke.400, 1.26.4-gke.500 o successive utilizzano 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 gcloud CLI o la console Google Cloud :

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

Abilita il DNS con ambito 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 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 consoleGoogle 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 abilitato 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 dei nodi è operativo in ogni momento perché alcuni node pool utilizzano kube-dns e altri utilizzano Cloud DNS.

Nei passaggi successivi, abilita Cloud DNS per un cluster e poi esegui l'upgrade dei node pool. L'upgrade dei pool di nodi ricrea i nodi. I nodi utilizzano Cloud DNS per la risoluzione DNS anziché kube-dns.

Attiva 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 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 che questo nome sia univoco all'interno del 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

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

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

Abilitare 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 node pool. L'upgrade dei pool di nodi ricrea i nodi. I nodi utilizzano quindi Cloud DNS per la risoluzione DNS anziché kube-dns.

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

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

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 del 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.
• COMPUTE_LOCATION: la posizione di Compute Engine per il cluster.

Attiva DNS con ambito VPC

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

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

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

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

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

Abilita DNS con ambito VPC in un cluster esistente

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

Cluster GKE Autopilot

Non puoi eseguire la migrazione di un cluster GKE Autopilot da kube-dns all'ambito VPC di 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 abilitato 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 successivi, abilita Cloud DNS per un cluster e poi esegui l'upgrade dei node pool. L'upgrade dei pool di nodi ricrea i nodi. I nodi utilizzano Cloud DNS per la risoluzione DNS anziché kube-dns.

Verifica Cloud DNS

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

1. Verifica che i 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à del cluster, l'output è simile al seguente:

   Cluster GKE Autopilot

   nameserver 169.254.20.10
   

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

   Solo quando la cache locale non ha una voce per il nome che viene 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 data plane Cloud DNS è in attesa di 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 tuo pod utilizza ancora kube-dns.

   Se l'output è 169.254.20.10, significa che hai abilitato 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. Esporre 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 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
   

Disabilita 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 gcloud CLI o la console Google Cloud in un cluster GKE Standard.

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

Dopo aver disattivato Cloud DNS per i cluster Standard, aggiorna tutti i node pool associati ai tuoi cluster. In alternativa, puoi creare un nuovo pool di nodi e pianificare il tuo workload lì. Se non aggiorni i pool di nodi, lo spazio dei nomi DNS continua a puntare a Cloud DNS, non a kube-dns.

Disabilita l'ambito VPC additivo di Cloud DNS

Quando disattivi l'ambito VPC additivo di Cloud DNS per il tuo cluster, vengono 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 viene eliminato dal cluster.

Per disattivare 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 cluster con l'ambito cluster Cloud DNS abilitato continuerà a 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 per l'ambito VPC e cluster.

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

Il 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 all'interno dello 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 un VPC nello stesso progetto host.

Se hai già cluster che utilizzano il VPC condiviso e l'ambito VPC di Cloud DNS, devi eseguirne la migrazione manualmente con i 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 della policy di risposta dal progetto di servizio al progetto host. Devi eseguire questa migrazione una sola volta per ogni 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 della policy di risposta.

3. Fai clic sul criterio di risposta per la tua rete VPC. Puoi identificare la policy di risposta in base alla descrizione, simile a "Policy 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 delete per rimuovere il binding di rete.

6. Fai clic sulla scheda Regole policy di risposta.

7. Seleziona tutte le voci della tabella.

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

9. Fai clic su delete Elimina criterio di risposta.

Dopo aver eliminato il criterio di risposta, il controller DNS crea automaticamente il criterio di risposta nel progetto host. I cluster di altri progetti di servizio condividono questa policy di risposta.

Supportare domini stub personalizzati e server dei nomi upstream

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

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

Estensioni di specifica

Per migliorare la Service Discovery e la compatibilità con vari client e sistemi, sono state aggiunte funzionalità alla specifica DNS di Kubernetes generale.

Porte denominate

Questa sezione spiega in che modo le porte denominate influiscono sui record DNS creati da Cloud DNS per il tuo cluster Kubernetes. Kubernetes definisce un insieme minimo di record DNS richiesti, mentre Cloud DNS può creare record aggiuntivi per il proprio funzionamento e per supportare varie funzionalità di Kubernetes. Le tabelle seguenti illustrano il numero minimo di set di record che puoi prevedere, dove "E" rappresenta il numero di endpoint e "P" rappresenta il numero di porte. Cloud DNS potrebbe creare record aggiuntivi.

Record DNS aggiuntivi creati da Cloud DNS

Cloud DNS potrebbe creare record DNS aggiuntivi oltre al numero minimo di set di record. Questi record hanno vari scopi, tra cui: Record SRV: per Service Discovery, Cloud DNS spesso crea record SRV. Questi record forniscono informazioni sulla porta e sul protocollo del servizio. Record AAAA (per il doppio stack): nelle configurazioni a doppio stack (IPv4 e IPv6), Cloud DNS crea record A (per IPv4) e record AAAA (per IPv6) per ogni endpoint. Record interni: Cloud DNS potrebbe creare record interni per la propria gestione e ottimizzazione. Questi record in genere non sono direttamente pertinenti per gli utenti. Servizi LoadBalancer: per i servizi di tipo LoadBalancer, Cloud DNS crea record associati all'indirizzo IP del bilanciatore del carico esterno. Servizi headless: i servizi headless hanno una configurazione DNS distinta. Ogni pod ha il proprio record DNS, che consente ai client di connettersi direttamente ai pod. Per questo motivo, il numero di porta non viene moltiplicato nel calcolo del record del servizio headless.

Esempio: Considera un servizio chiamato my-http-server nello spazio dei nomi backend. Questo servizio espone due porte, 80 e 8080, per un deployment con tre pod. Pertanto, E = 3 e P = 2.

Oltre a questi record minimi, Cloud DNS potrebbe creare record SRV e, nel caso di doppio stack, record AAAA. Se my-http-server è un servizio di tipo LoadBalancer, verranno creati record aggiuntivi per l'IP del bilanciatore del carico. Nota: Cloud DNS aggiunge record DNS supplementari in base alle esigenze. I record specifici creati dipendono da fattori quali il tipo di servizio e la configurazione.

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 per 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 è 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 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 del cluster.

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

Quando utilizzi kube-dns con NodeLocal DNSCache abilitato sul cluster, NodeLocal DNSCache è configurato per l'ascolto su entrambi gli indirizzi (l'indirizzo NodeLocal DNSCache e l'indirizzo kube-dns).

Per controllare lo stato di NodeLocal DNSCache, esegui questo 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 il file resolv.conf configurato con l'IP kube-dns (ad es. x.x.x.10).
• I pod node-local-cache sono in ascolto su entrambi gli indirizzi (bind 169.254.20.10 x.x.x.10) e intersecano le richieste DNS dai pod.
• NodeLocal DNSCache funziona come cache e i pod kube-dns sono poco sollecitati.

Dopo la migrazione

• Dopo l'aggiornamento del control plane per l'utilizzo di Cloud DNS, i pod hanno ancora resolv.conf configurato su kube-dns-IP (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 sono in ascolto solo sull'indirizzo NodeLocal DNSCache (bind 169.254.20.10). La richiesta non viene inviata ai pod Node-local-cache.
• Tutte le richieste dei 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 NodeLocal DNSCache (169.254.20.10).
• I pod node-local-cache sono in ascolto solo sull'indirizzo NodeLocal DNSCache (bind 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 di query DNS aumenta anche il traffico sui pod kube-dns, il che causa errori intermittenti 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:

• Per suggerimenti su Cloud DNS in GKE, consulta Risoluzione dei problemi di Cloud DNS in GKE.
• Per suggerimenti specifici su Cloud DNS, vedi Risolvere i problemi di Cloud DNS.
• Per suggerimenti generali sulla diagnosi dei problemi DNS di Kubernetes, consulta Debug della risoluzione DNS.

Passaggi successivi

• Leggi una panoramica di come GKE fornisce DNS gestito.
• Leggi DNS per servizi e pod per una panoramica generale di come viene utilizzato il DNS nei cluster Kubernetes.
• Scopri di più su ambiti e gerarchie in Cloud DNS.
• Scopri di più su come attivare e disattivare la registrazione per le zone gestite private.