Questo documento ti aiuta a decidere se Cloud DNS per GKE è la soluzione DNS giusta per il tuo cluster. Puoi utilizzare Cloud DNS per gestire la risoluzione DNS di pod e servizi in alternativa ai provider DNS ospitati nel cluster come kube-dns.
Per i cluster Autopilot, Cloud DNS è già il provider DNS predefinito. Per i cluster Standard, puoi passare da kube-dns a
Cloud DNS.
Questo documento è rivolto agli utenti di GKE, inclusi sviluppatori, amministratori e architetti. Per saperne di più sui ruoli comuni e sulle attività di esempio in Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.
Questo documento presuppone che tu abbia familiarità con i seguenti concetti:
Come funziona Cloud DNS per GKE
Quando utilizzi Cloud DNS come provider DNS per GKE, Cloud DNS fornisce la risoluzione DNS di pod e servizi senza richiedere un provider DNS ospitato nel cluster. I record DNS per pod e servizi vengono sottoposti automaticamente al provisioning in Cloud DNS per i servizi di indirizzo IP del cluster, headless e nome esterno.
Cloud DNS supporta la specifica DNS completa 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 dei criteri di risposta. L'utilizzo di Cloud DNS come provider DNS per GKE offre i seguenti vantaggi rispetto al DNS ospitato nel cluster:
- Overhead ridotto: elimina la necessità di gestire i server DNS ospitati nel cluster. Cloud DNS non richiede il ridimensionamento, il monitoraggio o la gestione manuali delle istanze DNS perché è un servizio completamente gestito.
- Scalabilità e prestazioni elevate: risolve le query localmente per ogni nodo GKE per fornire una risoluzione DNS a bassa latenza e altamente scalabile. Per prestazioni ottimali, soprattutto nei cluster su larga scala, valuta la possibilità di abilitare NodeLocal DNSCache, che fornisce un livello di memorizzazione nella cache aggiuntivo sul nodo.
- Integrazione con Google Cloud Observability: consente il monitoraggio e il logging DNS. Per maggiori informazioni, vedi Attivare e disattivare la registrazione per le zone private gestite.
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 control plane 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 backend del servizio seleziona i pod di backend in esecuzione. Il clouddns-controller crea un record DNS per il backend del servizio.
Il frontend del pod 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 di cache a Cloud DNS.
Cloud DNS risolve il nome del servizio in indirizzi IP diversi in base al
tipo di servizio Kubernetes. Per i servizi ClusterIP, Cloud DNS risolve il nome del servizio nel suo indirizzo IP virtuale; per i servizi headless, risolve il nome del servizio nell'elenco degli indirizzi IP degli endpoint.
Dopo che il frontend del pod risolve l'indirizzo IP, il pod può inviare traffico al backend del servizio 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 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 non sono in conflitto con i nomi DNS*.cluster.localper altri cluster GKE nello stesso progetto. Questa è la modalità predefinita.- Ambito VPC aggiuntivo 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. Questa modalità è una modalità aggiuntiva abilitata insieme all'ambito del cluster. Puoi attivare o disattivare questa modalità nel tuo cluster senza influire sull'uptime del DNS o sulle funzionalità dell'ambito del 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 possono 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 nella 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 | Solo cluster, con servizi headless risolvibili nella rete VPC | L'intera rete VPC |
| Risoluzione del servizio headless | Risolvibile all'interno del cluster | Risolvibile all'interno del cluster utilizzando il dominio `cluster.local`, e nel VPC utilizzando il suffisso del cluster | Risolvibile all'interno del cluster e nel VPC utilizzando il suffisso del cluster |
| Requisito di dominio unico | No, utilizza il dominio predefinito `*.cluster.local` | Sì, devi impostare un dominio personalizzato univoco | Sì, devi impostare un dominio personalizzato univoco |
| Configurazione | Predefinito, nessun passaggio aggiuntivo | Facoltativo al momento della creazione del cluster Può essere attivato o 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 diretta | Zona di ricerca inversa |
|---|---|---|
| Ambito cluster | 1 zona privata per cluster per zona di Compute Engine (nella regione) | 1 zona della policy di risposta per cluster per zona di 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 delle norme di risposta
per cluster per zona di Compute Engine (nella regione) per cluster
(zona globale)
1 zona delle norme di risposta con ambito VPC per cluster (zona globale) |
| Ambito VPC | 1 zona privata per cluster (zona globale) | 1 zona della policy di risposta per cluster (zona globale) |
La convenzione di denominazione utilizzata per queste risorse Cloud DNS è la seguente:
| Ambito | Zona di ricerca diretta | 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 con ambito cluster
gke-NETWORK_NAME_HASH-rp per le zone con ambito VPC |
| 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 tuo 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 |
| Server dei nomi upstream personalizzati | Inoltro (zona globale) | gke-CLUSTER_NAME-CLUSTER_HASH-upstream |
Per saperne 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 forwarding
Per i cluster che utilizzano l'ambito cluster 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 DNS stubDomain, il controller Cloud DNS crea una zona di inoltro.
Cloud DNS elabora ogni DNS upstream utilizzando una zona gestita con il nome DNS ..
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:
| 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 o IPv6) | Numero di record per set di record di risorse | GKE 1.24-1.25: 1000 (IPv4 o IPv6) GKE 1.26 e versioni successive: 3500 per IPv4; 2000 per IPv6 |
| Numero di cluster GKE in un progetto | Numero di policy di risposta per progetto | 100 |
| Numero di record PTR per cluster | Numero di regole per policy di risposta | 100.000 |
Limiti delle risorse
Le risorse Kubernetes che crei per cluster contribuiscono ai limiti delle risorse Cloud DNS, come descritto nella tabella seguente:
| Limite | Contributo al limite |
|---|---|
| Set di record di risorse per zona gestita | Numero di servizi più 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 policy di risposta | Per l'ambito del cluster, numero di servizi più numero di endpoint di servizio headless con nomi host validi per cluster. Per l'ambito VPC, numero di servizi più numero di endpoint headless con nomi host di tutti i cluster nel VPC. |
Per saperne di più su come vengono creati i record DNS per Kubernetes, consulta Service Discovery basata sul DNS di Kubernetes.
Più di un cluster per progetto di servizio
A partire dalle versioni 1.22.3-gke.700 e 1.21.6-gke.1500 di GKE, puoi creare cluster in più progetti di servizio che fanno riferimento a una VPC nello stesso progetto host.
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 forwarding Cloud DNS.
Estensioni di specifiche
Per migliorare il service discovery e la compatibilità con vari client e sistemi, puoi utilizzare aggiunte 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, ma Cloud DNS potrebbe creare record aggiuntivi per il proprio funzionamento e per supportare varie funzionalità di Kubernetes. Le tabelle seguenti
mostrano il numero minimo di set di record che puoi prevedere, dove "E"
rappresenta il numero di endpoint e "P" il numero di porte.
Cloud DNS potrebbe creare record aggiuntivi.
| Tipo di stack IP | Tipo di servizio | Set di record |
|---|---|---|
| Singola pila | ClusterIP | $$2+P$$ |
| Headless | $$2+P+2E$$ |
|
| Doppia pila | ClusterIP | $$3+P$$ |
| Headless | $$3+P+3E$$ |
|
| Per ulteriori informazioni sui servizi single stack e dual stack, consulta Servizi single stack e dual stack. | ||
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 varie finalità, tra cui:
- Record SRV: per il 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 che utilizzano sia IPv4 che 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. Questo approccio è il motivo per cui il numero di porta non viene moltiplicato nel calcolo del record di servizio headless.
Esempio: considera un servizio denominato my-http-server che si trova 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.
| Tipo di stack IP | Tipo di servizio | Set di record |
|---|---|---|
| Singola pila | ClusterIP | $$2+2$$ |
| Headless | $$2+2+2*3$$ |
|
| Doppia pila | ClusterIP | $$3+2$$ |
| Headless | $$3+2+3*3$$ |
Oltre a questi record minimi, Cloud DNS potrebbe creare record SRV e, nel caso di reti dual-stack, record AAAA. Se my-http-server è un servizio di tipo LoadBalancer, vengono 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
Questa sezione descrive i problemi comuni che potresti riscontrare quando utilizzi Cloud DNS con GKE, insieme a potenziali soluzioni alternative.
Terraform tenta di ricreare il cluster Autopilot a causa di una 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 le versioni 1.25.9-gke.400, 1.26.4-gke.500 o 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 l'impostazione lifecycle.ignore_changes
alla risorsa per assicurarti che google_container_cluster ignori
le modifiche a dns_config:
lifecycle {
ignore_changes = [
dns_config,
]
}
La risoluzione DNS non riesce dopo la migrazione da kube-dns a Cloud DNS con NodeLocal DNSCache abilitato
Questa sezione descrive un problema noto per i cluster GKE che si trovano in Cloud DNS e che hanno abilitato NodeLocal DNSCache nell'ambito del cluster.
Quando NodeLocal DNSCache è abilitato sul cluster e esegui la migrazione da
kube-dns a Cloud DNS, il cluster potrebbe riscontrare errori di risoluzione intermittenti.
Se 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
Se GKE Dataplane V2 è abilitato sul cluster e il cluster utilizza kube-dns, NodeLocal DNSCache viene eseguito in una rete isolata ed è configurato per l'ascolto su tutti gli indirizzi IP dei pod (0.0.0.0). L'output è simile al seguente:
bind 0.0.0.0
bind 0.0.0.0
Dopo l'aggiornamento del cluster a Cloud DNS, la configurazione di NodeLocal DNSCache viene modificata. Per controllare la configurazione 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
bind 169.254.20.10
Il seguente flusso di lavoro spiega le voci nel file resolv.conf prima
e dopo la migrazione e la ricreazione del nodo:
Prima della migrazione
- I pod hanno il file
resolv.confconfigurato con l'indirizzo IPkube-dns(ad esempio,x.x.x.10). - I pod NodeLocal DNSCache intercettano le richieste DNS dai pod e ascoltano quanto segue:
- (DPv1) entrambi gli indirizzi (bind 169.254.20.10 x.x.x.10).
- (DPv2) tutti gli indirizzi IP del pod (bind 0.0.0.0).
- NodeLocal DNSCache funziona come cache e il carico minimo viene applicato ai pod
kube-dns.
Dopo la migrazione
- Dopo l'aggiornamento del control plane per l'utilizzo di Cloud DNS, i pod hanno ancora il file
resolv.confconfigurato con l'indirizzo IPkube-dns(ad esempio,x.x.x.10). I pod mantengono questa configurazioneresolv.conffinché il nodo non viene ricreato. Quando Cloud DNS con NodeLocal DNSCache è abilitato, i pod devono essere configurati per utilizzare169.254.20.10come server dei nomi, ma questa modifica si applica solo ai pod sui nodi creati o ricreati dopo la migrazione a Cloud DNS. - I pod NodeLocal DNSCache sono in ascolto solo sull'indirizzo NodeLocal DNSCache (bind 169.254.20.10). Le richieste non vengono inviate ai pod NodeLocal DNSCache.
- Tutte le richieste dei pod vengono inviate direttamente ai pod
kube-dns. Questa configurazione genera un traffico elevato sui pod.
Dopo la ricreazione del nodo o l'upgrade del pool di nodi
- I pod hanno il file
resolv.confconfigurato per utilizzare l'indirizzo IP di NodeLocal DNSCache (169.254.20.10). - I pod NodeLocal DNSCache 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 pool di nodi utilizzano l'indirizzo IP kube-dns nel file resolv.conf prima
che il pool di nodi venga ricreato, un aumento del traffico di query DNS aumenta anche
il traffico sui pod kube-dns. Questo aumento può causare errori intermittenti delle richieste DNS. Per ridurre al minimo gli errori, devi pianificare questa migrazione durante i periodi di inattività.
Passaggi successivi
- Configura Cloud DNS per GKE.
- Utilizza NodeLocal DNSCache in GKE.
- Risolvi i problemi relativi al DNS di GKE.