Utilizzo di kube-dns

Questa pagina descrive in che modo Google Kubernetes Engine (GKE) implementa il discovery dei servizi 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 dei pod kube-dns nello spazio dei nomi kube-system. I pod accedono al deployment di kube-dns tramite un servizio corrispondente che raggruppa i pod kube-dns e li assegna a un singolo indirizzo IP (ClusterIP). Per impostazione predefinita, tutti i pod in un cluster utilizzano questo servizio per risolvere le query DNS. Il seguente diagramma mostra la relazione tra i pod e il servizio kube-dns.

Pod kube-dns la relazione con 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 di cui viene eseguito il deployment in tutti i cluster GKE. kube-dns-autoscaler regola il numero di repliche nel deployment di kube-dns in base al numero di nodi e core nel cluster.

kube-dns supporta fino a 1000 endpoint per servizio headless.

Come viene configurato il DNS del pod

Il kubelet in esecuzione su ogni nodo configura il etc/resolv.conf del pod per usare l'IP cluster del servizio kube-dns. La seguente configurazione di esempio mostra che l'indirizzo IP del servizio kube-dns è 10.0.0.10. Questo indirizzo IP è diverso 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 il ConfigMap per kube-dns per impostare i domini stub come parte dell'infrastruttura DNS all'interno dei tuoi cluster.

I domini stub ti consentono di configurare resolver per dominio personalizzati in modo che kube-dns forwardi le richieste DNS a server DNS upstream specifici durante la risoluzione di questi domini.

Il seguente manifest ConfigMap di esempio per kube-dns include una configurazione stubDomains che imposta i 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 il seguente 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 il ConfigMap per kube-dns in modo da includere upstreamNameservers, kube-dns inoltra tutte le richieste DNS tranne *.cluster.local a questi server. Sono inclusi metadata.internal e *.google.internal, che non sono risolvibili in base al server upstream.

Se attivi Workload Identity Federation for GKE o qualsiasi carico di lavoro che si basa sulla risoluzione metadata.internal, per mantenere la risoluzione dei nomi *.internal, aggiungi un 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 definisci più di 6 domini di ricerca, viene visualizzato il seguente avviso 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 del contenitore.

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.
  • Eseguire kube-dns su VM spot o prerilasciabili, il che può comportare l'eliminazione imprevista di nodi 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 VM Spot o prerilasciabili. L'utilizzo di VM spot o prerilasciabili per il DNS può causare errori e interrompere il tuo cluster.
  • Come best practice, crea almeno un pool di nodi composto da (non spot o prerilasciabili) per ospitare componenti di sistema critici come kube-dns. assicurare 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 la tua applicazione utilizzi funzioni basate su dns.resolve* anziché su dns.lookup, poiché dns.lookup è sincrono. Le funzioni dns.resolve* eseguono sempre una query DNS asincrona sulla rete.

Record DNS del servizio

kube-dns crea record DNS solo per i servizi che hanno Endpoint{track-name="k8sLink" track-type="concept"}.

TTL elevato dai server DNS upstream

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