Questa pagina spiega come migliorare la latenza della ricerca DNS in una Cluster Google Kubernetes Engine (GKE) utilizzando NodeLocal DNSCache.
Per i cluster GKE Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non è possibile eseguirne l'override.
Architettura
NodeLocal DNSCache è un componente aggiuntivo di GKE che puoi eseguire oltre a kube-dns.
GKE implementa NodeLocal DNSCache come DaemonSet che esegue una cache DNS su ciascun nodo del cluster.
Quando un pod effettua una richiesta DNS, questa viene inviata alla cache DNS in esecuzione stesso nodo del pod. Se la cache non riesce a risolvere la richiesta DNS, inoltra la richiesta a una delle seguenti posizioni in base alla query destinazione:
- kube-dns: tutte le query per il dominio DNS del cluster (
cluster.local
) vengono a kube-dns. I pod node-local-dns utilizzano kube-dns-upstream per accedere ai pod kube-dns. Nel diagramma seguente, l'indirizzo IP il servizio kube-dns è10.0.0.10:53
. - Domini stub personalizzati o server dei nomi upstream: le query vengono inoltrate direttamente dai pod NodeLocal DNSCache.
- Cloud DNS: tutte le altre query vengono inoltrate al server di metadati locale che viene eseguito come il pod da cui ha avuto origine la query. Il server di metadati locale accede in Cloud DNS.
Quando abiliti NodeLocal DNSCache su un cluster esistente, GKE ricrea tutti i nodi del cluster che eseguono GKE versione 1.15 e successive secondo processo di upgrade dei nodi.
Dopo che GKE ha ricreato i nodi, GKE esegue automaticamente
aggiunge l'etichetta addon.gke.io/node-local-dns-ds-ready=true
ai nodi. Tu
non devono aggiungere manualmente questa etichetta ai nodi del cluster.
Vantaggi di NodeLocal DNSCache
NodeLocal DNSCache offre i seguenti vantaggi:
- Riduzione del tempo medio di ricerca DNS
- Le connessioni dai pod alla cache locale non creano conntrack le voci della tabella. In questo modo si evitano connessioni interrotte o rifiutate causate da dell'esaurimento delle tabelle di connessione e delle condizioni di gara.
- Puoi utilizzare NodeLocal DNSCache con Cloud DNS per GKE.
- Le query DNS per gli URL esterni (URL che non fanno riferimento alle risorse del cluster) vengono vengono inoltrati direttamente al team locale Server di metadati Cloud DNS, bypassando kube-dns.
- Le cache DNS locali rilevano automaticamente i domini stub e l'upstream server dei nomi specificati kube-dns ConfigMap.
Requisiti e limitazioni
- NodeLocal DNSCache consuma risorse di calcolo su ciascun nodo del cluster.
- NodeLocal DNSCache non è supportato con i pool di nodi di Windows Server.
- NodeLocal DNSCache richiede GKE versione 1.15 o successiva.
- NodeLocal DNSCache accede ai pod kube-dns tramite TCP.
- NodeLocal DNSCache accede a
upstreamServers
estubDomains
tramite TCP e UDP su GKE versione 1.18 o successive. Il DNS deve essere raggiungibile tramite TCP e UDP. - I record DNS vengono memorizzati nella cache per i seguenti periodi:
- La durata (TTL) del record o 30 secondi se il TTL è superiore a 30 secondi.
- 5 secondi se la risposta DNS è
NXDOMAIN
.
- I pod NodeLocal DNSCache sono in ascolto sulle porte 53, 9253, 9353 e 8080 dei nodi. Se
esegui qualsiasi altro pod
hostNetwork
o configurihostPorts
con quelle porte, NodeLocal DNSCache e di errori DNS si verificano. I pod NodeLocal DNSCache non usare la modalitàhostNetwork
quando usi GKE Dataplane V2 e Cloud DNS per GKE. - La cache DNS locale viene eseguita solo su pool di nodi che eseguono GKE 1.15 e versioni successive. Se abiliti NodeLocal DNSCache in un cluster mentre i nodi eseguono versioni precedenti, i pod su questi nodi usano kube-dns.
Abilita NodeLocal DNSCache
Per i cluster Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita non possono essere sostituiti.
Per i cluster standard, puoi abilitare NodeLocal DNSCache su nuove istanze con Google Cloud CLI. Puoi abilitare NodeLocal DNSCache in utilizzando la console Google Cloud.
gcloud
Abilita NodeLocal DNSCache in un nuovo cluster
Per abilitare NodeLocal DNSCache in un nuovo cluster, utilizza il flag --addons
con
argomento NodeLocalDNS
:
gcloud container clusters create CLUSTER_NAME \
--location=COMPUTE_LOCATION \
--addons=NodeLocalDNS
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del nuovo cluster.COMPUTE_LOCATION
: il Località di Compute Engine per il cluster.
Abilita NodeLocal DNSCache in un cluster esistente
Per abilitare NodeLocal DNSCache in un cluster esistente, utilizza
Flag --update-addons
con l'argomento NodeLocalDNS=ENABLED
:
gcloud container clusters update CLUSTER_NAME \
--update-addons=NodeLocalDNS=ENABLED
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del tuo cluster.
Console
Per abilitare NodeLocal DNSCache su un nuovo cluster, segui questi passaggi:
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Accanto a Standard, fai clic su Configura.
Configura il cluster come preferisci.
Nel riquadro di navigazione, fai clic su Networking.
Nella sezione Opzioni di rete avanzate, seleziona la casella di controllo Abilita NodeLocal DNSCache.
Fai clic su Crea.
Verifica che NodeLocal DNSCache sia abilitato
Puoi verificare che NodeLocal DNSCache sia in esecuzione elencando node-local-dns
Pod:
kubectl get pods -n kube-system -o wide | grep node-local-dns
L'output è simile al seguente:
node-local-dns-869mt 1/1 Running 0 6m24s 10.128.0.35 gke-test-pool-69efb6b8-5d7m <none> <none>
node-local-dns-htx4w 1/1 Running 0 6m24s 10.128.0.36 gke-test-pool-69efb6b8-wssk <none> <none>
node-local-dns-v5njk 1/1 Running 0 6m24s 10.128.0.33 gke-test-pool-69efb6b8-bhz3 <none> <none>
L'output mostra un pod node-local-dns
per ogni nodo in esecuzione
GKE versione 1.15 o successive.
Disabilita NodeLocal DNSCache
Puoi disabilitare NodeLocal DNSCache utilizzando il seguente comando:
gcloud container clusters update CLUSTER_NAME \
--update-addons=NodeLocalDNS=DISABLED
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster da disabilitare.
Risolvi i problemi di NodeLocal DNSCache
Per informazioni generali su come diagnosticare i problemi del DNS di Kubernetes, consulta Debug della risoluzione DNS.
NodeLocal DNSCache non è abilitato immediatamente
Quando abiliti NodeLocal DNSCache su un cluster esistente, GKE potrebbe non aggiornare immediatamente i nodi se per il cluster è configurata periodo di manutenzione o esclusione. Per ulteriori informazioni, vedi caveat per i periodi di manutenzione e ricreazione dei nodi.
Se preferisci non attendere, puoi applicare manualmente le modifiche ai nodi
chiamando il gcloud container clusters upgrade
e passare il flag --cluster-version
con lo stesso
La versione GKE già in esecuzione del pool di nodi. Devi utilizzare
Google Cloud CLI per questa soluzione alternativa.
NodeLocal DNSCache con Cloud DNS
Se utilizzi NodeLocal DNSCache con
Cloud DNS, il cluster
utilizza l'indirizzo IP del server dei nomi 169.254.20.10
, come mostrato di seguito
diagramma:
Di conseguenza, l'indirizzo IP del servizio kube-dns
potrebbe essere diverso da
l'indirizzo IP del server dei nomi utilizzato dai pod. La differenza di indirizzi IP
è previsto perché l'indirizzo IP del server dei nomi 169.254.20.10
è obbligatorio
affinché Cloud DNS funzioni correttamente.
Per verificare gli indirizzi IP, esegui questi comandi:
Visualizza l'indirizzo IP del servizio
kube-dns
:kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"
L'output è l'indirizzo IP di
kube-dns
, ad esempio10.0.0.10:53
Apri una sessione di shell nel tuo pod:
kubectl exec -it POD_NAME -- /bin/bash
Nella sessione della shell del pod, leggi i contenuti del file
/etc/resolv.conf
:cat /etc/resolv.conf
L'output è
169.254.20.10
Criterio di rete con NodeLocal DNSCache
Se usi i criteri di rete
con NodeLocal DNSCache e non stai utilizzando
Cloud DNS o
GKE Dataplane V2,
devi configurare regole che consentano i carichi di lavoro e node-local-dns
per l'invio di query DNS.
Utilizza una regola ipBlock
nel file manifest per consentire la comunicazione tra
i tuoi pod e kube-dns.
Il seguente file manifest descrive un criterio di rete che utilizza una regola ipBlock
:
spec:
egress:
- ports:
- port: 53
protocol: TCP
- port: 53
protocol: UDP
to:
- ipBlock:
cidr: KUBE_DNS_SVC_CLUSTER_IP/32
podSelector: {}
policyTypes:
- Egress
Sostituisci KUBE_DNS_SVC_CLUSTER_IP
con l'indirizzo IP del
kube-dns. Puoi ottenere l'indirizzo IP del servizio kube-dns utilizzando
seguente comando:
kubectl get svc -n kube-system kube-dns -o jsonpath="{.spec.clusterIP}"
Problemi noti
Timeout DNS in dnsPolicy di ClusterFirstWithHostNet durante l'utilizzo di NodeLocal DNSCache e GKE Dataplane V2
Sui cluster che utilizzano GKE Dataplane V2 e NodeLocal DNSCache, pod con hostNetwork
impostato su true
e dnsPolicy
impostato su ClusterFirstWithHostNet
non può raggiungere
backend DNS del cluster. I log DNS potrebbero contenere voci simili alle seguenti:
nslookup: write to 'a.b.c.d': Operation not permitted
;; connection timed out; no servers could be reached
L'output indica che le richieste DNS non possono raggiungere i server di backend.
Una soluzione alternativa è impostare dnsPolicy
e dnsConfig
per i pod hostNetwork
:
spec:
dnsPolicy: "None"
dnsConfig:
nameservers:
- KUBE_DNS_UPSTREAM
searches:
- cluster.local
- svc.cluster.local
- NAMESPACE.svc.cluster.local
- c.PROJECT_ID.internal
- google.internal
options:
- name: ndots
value: "5"
Sostituisci quanto segue:
NAMESPACE
: lo spazio dei nomi del podhostNetwork
.PROJECT_ID
: l'ID del tuo progetto Google Cloud.KUBE_DNS_UPSTREAM
: il ClusterIP dell'upstream kube-dns. Puoi ottenere questo valore utilizzando il seguente comando:kubectl get svc -n kube-system kube-dns-upstream -o jsonpath="{.spec.clusterIP}"
Le richieste DNS dal pod possono ora raggiungere kube-dns e bypassare NodeLocal DNSCache.
Errori di timeout di NodeLocal DNSCache
Nei cluster in cui è abilitato NodeLocal DNSCache, i log potrebbero contenere voci simile al seguente:
[ERROR] plugin/errors: 2 <hostname> A: read tcp <node IP: port>-><kubedns IP>:53: i/o timeout
L'output include l'indirizzo IP dell'IP del cluster kube-dns-upstream
assistenza. In questo esempio, la risposta a una richiesta DNS non è stata ricevuta
kube-dns in 2 secondi. Ciò potrebbe essere dovuto a uno dei seguenti motivi:
- Un problema di connettività di rete sottostante.
- Notevole aumento delle query DNS dal carico di lavoro o a causa dell'upscaling del pool di nodi.
Di conseguenza, i pod kube-dns
esistenti non sono in grado di gestire tutte le richieste in tempo. La soluzione alternativa è aumentare il numero di repliche kube-dns ottimizzando
parametri di scalabilità automatica.
Fare lo scale up di kube-dns
Puoi utilizzare un valore più basso per nodesPerReplica
per garantire che più kube-dns
I pod vengono creati quando i nodi del cluster fanno lo scale up. Ti consigliamo vivamente di impostare
valore max
esplicito per garantire che il piano di controllo GKE
di una macchina (VM) non viene sottoposta a sovraccarico a causa dell'osservazione di un numero elevato di pod kube-dns
l'API Kubernetes.
Puoi impostare max
sul numero di nodi nel cluster. Se il cluster ha un numero maggiore
di 500 nodi, imposta max
su 500.
Per i cluster standard, puoi modificare il numero di repliche kube-dns
modificando il ConfigMap kube-dns-autoscaler
. Questa configurazione non è
supportati nei cluster Autopilot.
kubectl edit configmap kube-dns-autoscaler --namespace=kube-system
L'output è simile al seguente:
linear: '{"coresPerReplica":256, "nodesPerReplica":16,"preventSinglePointFailure":true}'
Il numero di repliche kube-dns viene calcolato utilizzando la seguente formula:
replicas = max( ceil( cores × 1/coresPerReplica ) , ceil( node × 1/nodesPerReplica ), maxValue )
Per fare lo scale up, modifica nodesPerReplica
impostando un valore inferiore e includi un
Valore max
.
linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"preventSinglePointFailure":true}'
La configurazione crea un pod kube-dns per ogni 8 nodi nel cluster. Un nodo di 24 nodi
un cluster avrà 3 repliche, mentre un cluster da 40 nodi avrà 5 repliche. Se
che supera i 120 nodi, il numero di repliche kube-dns non aumenta
oltre 15, il valore max
.
Per garantire un livello base di disponibilità DNS nel cluster, e impostare un numero minimo di repliche per kube-dns.
L'output ConfigMap kube-dns-autoscaler
con il campo min
sarebbe simile
a:
linear: '{"coresPerReplica":256, "nodesPerReplica":8,"max": 15,"min": 5,"preventSinglePointFailure":true}'
Passaggi successivi
- Leggi una panoramica di come GKE fornisce DNS gestiti.
- Letto DNS per servizi e pod per una panoramica generale dell'uso del DNS nei cluster Kubernetes.
- Scopri come utilizzare Cloud DNS per GKE.