Questa pagina descrive in che modo Google Kubernetes Engine (GKE) implementa Service Discovery utilizzando kube-dns, il provider DNS predefinito per i cluster GKE.
Per i cluster Autopilot, non puoi modificare il valore predefinito kube-dns configurazione.
Architettura
Quando crei un cluster, GKE esegue automaticamente il deployment di kube-dns
nello spazio dei nomi kube-system
. I pod accedono al deployment kube-dns tramite
a un Servizio corrispondente
che raggruppa i pod kube-dns e assegna loro un singolo indirizzo IP (ClusterIP).
Per impostazione predefinita, tutti i pod in un cluster utilizzano questo servizio per risolvere le query DNS. La
il seguente diagramma mostra la relazione tra i pod e il servizio kube-dns.
kube-dns scala per soddisfare le richieste DNS del cluster. Questo tipo di scalabilità è
controllato da kube-dns-autoscaler
, un pod il cui deployment viene eseguito per impostazione predefinita
in tutti i cluster GKE. kube-dns-autoscaler
regola il numero di
nel deployment kube-dns in base al numero di nodi e core in
nel cluster.
kube-dns supporta fino a 1000 endpoint per servizio headless.
Come viene configurato il DNS dei pod
Il kubelet in esecuzione su ciascun nodo configura l'etc/resolv.conf
del pod in
di usare il ClusterIP del servizio kube-dns. La configurazione di esempio seguente mostra
che l'indirizzo IP del servizio kube-dns sia 10.0.0.10
. Questo indirizzo IP è
diversi in altri cluster.
nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5
kube-dns è il server dei nomi autorevole per il dominio del cluster (cluster.local)
e risolve i nomi esterni in modo ricorsivo. Nomi brevi che non contengono
qualificate, come myservice
, vengono completate per prime con i percorsi di ricerca locale.
Aggiunta di resolver personalizzati per i domini stub
Puoi modificare ConfigMap affinché kube-dns imposti i domini stub come parte dell'infrastruttura DNS all'interno del proprio cluster.
I domini Stub consentono di configurare resolver per dominio personalizzati in modo che kube-dns inoltra le richieste DNS a specifici server DNS upstream per risolvere domini.
Il seguente esempio di manifest ConfigMap per kube-dns include un stubDomains
che imposta resolver personalizzati per il dominio example.com.
apiVersion: v1
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{
"example.com": [
"8.8.8.8",
"8.8.4.4",
"1.1.1.1",
"1.0.0.1"
]
}
Esegui questo comando per aprire un editor di testo:
kubectl edit configmap kube-dns -n kube-system
Sostituisci i contenuti del file con il file manifest, quindi esci dall'editor di testo per applicare il manifest al cluster.
Server dei nomi upstream
Se modifichi
ConfigMap
affinché kube-dns includa upstreamNameservers
, inoltra tutti i DNS
diverse richieste a questi server, tranne *.cluster.local
. Sono inclusi
metadata.internal
e *.google.internal
, che non sono risolvibili in base al
server upstream.
Se attivi
Federazione delle identità dei carichi di lavoro per GKE o qualsiasi
carichi di lavoro che si basano sulla risoluzione metadata.internal
, per conservare *.internal
risoluzione del nome, aggiungi stubDomain
al ConfigMap.
data:
stubDomains: |
{
"internal": [
"169.254.169.254"
]
}
upstreamNameservers: |
["8.8.8.8"]
Problemi noti
Limite di domini di ricerca
Esiste un limite di 6 domini di ricerca DNS per /etc/resolv.conf
. Se
se definisci più di sei domini di ricerca, il seguente avviso viene visualizzato quando esegui
il comando kubectl describe pod
:
Search Line limits were exceeded, some search paths have been omitted, the applied search line is: default.svc.cluster.local svc.cluster.local cluster.local c.<project ID>.internal google.internal
Questo avviso viene registrato in Cloud Logging nella sezione dei log dei container.
Per risolvere il problema, rimuovi i percorsi di ricerca aggiuntivi dalla configurazione.
Considera il limite di upstreamNameservers
Kubernetes impone un limite di massimo tre valori upstreamNameservers
. Se definisci
di 3 upstreamNameservers
, viene visualizzato il seguente errore in Cloud Logging
i log di deployment di kube-dns
:
Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update
In questo caso, kube-dns si comporta come se non avesse upstreamNameservers
configurato. Per risolvere il problema, rimuovi lo upstreamNameservers
aggiuntivo da
la configurazione.
Limitazioni delle prestazioni con kube-dns
Se stai riscontrando una latenza elevata con ricerche DNS o errori di risoluzione DNS con il provider kube-dns predefinito, la causa potrebbe essere:
- Esecuzione di ricerche DNS frequenti all'interno del carico di lavoro
- Eseguendo il deployment di una densità di pod più elevata per nodo.
- Esecuzione di kube-dns su VM spot o prerilasciabili, che può portare a nodi imprevisti e conseguenti problemi di risoluzione DNS.
Per migliorare i tempi di ricerca DNS, puoi scegliere una delle seguenti opzioni:
- Evita di eseguire componenti di sistema critici, come kube-dns su spot o prerilasciabili, delle VM in esecuzione. L'utilizzo di VM spot o prerilasciabili per il DNS può causare errori e interrompere in un cluster Kubernetes.
- Come best practice, crea almeno un pool di nodi composto da (non spot o prerilasciabili) per ospitare componenti di sistema critici come kube-dns. garantire che i carichi di lavoro critici siano pianificati solo sul nodo affidabile. che ne impedisce l'esecuzione su VM spot o prerilasciabili, utilizza incompatibilità e tolleranze per le VM spot.
- Abilita NodeLocal DNSCache.
- Fai lo scale up di kube-dns.
- Assicurati che l'applicazione utilizzi funzioni basate su dns.resolve* anziché su quelle basate su In base a dns.lookup perché dns.lookup è sincrona. Le funzioni dns.resolve* vengono eseguite sempre una query DNS asincrona sulla rete.
Record DNS del servizio
kube-dns crea solo record DNS per i servizi che dispongono di Endpoint.
TTL elevato da server upstream DNS
Se kube-dns riceve una risposta DNS da un resolver DNS upstream con una dimensione grande o "infinita" TTL, conserva questo valore TTL per la voce DNS nella cache. La voce non scade mai e potrebbe creare una discrepanza tra la voce e l'indirizzo IP effettivo risolto per il nome TTL.
GKE risolve questo problema nelle seguenti versioni del piano di controllo Impostando un valore TTL massimo su 30 secondi per qualsiasi risposta DNS con un TTL superiore a 30 secondi:
- 1.21.14-gke.9100
- 1.22.15-gke.2100
- 1.23.13-gke.500
- 1.24.7-gke.500
- 1.25.2-gke.500 o versioni successive
Questo comportamento è simile a NodeLocal DNSCache.
Passaggi successivi
- Leggi un panoramica del cluster il DNS in GKE.
- Letto DNS per servizi e pod per una panoramica generale dell'uso del DNS nei cluster Kubernetes.