Utilizzo di kube-dns

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 la configurazione kube-dns predefinita.

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 kube-dns tramite un Service 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. Il seguente diagramma mostra la relazione tra i pod e il servizio kube-dns.

Relazione pod kube-dns con il servizio kube-dns

kube-dns scala per soddisfare le richieste DNS del cluster. Questa scalabilità è controllata da kube-dns-autoscaler, un pod di cui viene eseguito il deployment per impostazione predefinita in tutti i cluster GKE. kube-dns-autoscaler regola il numero di repliche nel deployment kube-dns in base al numero di nodi e core nel cluster.

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

Come è configurato il DNS dei pod

Il kubelet in esecuzione su ciascun Nodo configura il etc/resolv.conf del pod in modo che utilizzi il ClusterIP 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. I nomi brevi non completi, come myservice, vengono completati per primi con i percorsi di ricerca locale.

Aggiunta di resolver personalizzati per domini stub

Puoi modificare il campo ConfigMap per kube-dns per impostare domini stub come parte dell'infrastruttura DNS all'interno dei tuoi cluster.

I domini Stub consentono di configurare resolver personalizzati per dominio in modo che kube-dns inoltri 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 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 manifest, quindi esci dall'editor di testo per applicarlo al cluster.

Server dei nomi upstream

Se modifichi il valore ConfigMap per kube-dns in modo da includere upstreamNameservers, kube-dns inoltra a questi server tutte le richieste DNS tranne *.cluster.local. Sono inclusi metadata.internal e *.google.internal, che non sono risolvibili dal server upstream.

Se abiliti Workload Identity o qualsiasi carico di lavoro che si basa sulla risoluzione metadata.internal, per mantenere la risoluzione dei nomi *.internal, aggiungi stubDomain al ConfigMap.

data:
  stubDomains: |
    {
      "internal": [
        "169.254.169.254"
      ]
    }
  upstreamNameservers: |
    ["8.8.8.8"]

Problemi noti

Limite per i domini di ricerca

Esiste un limite di sei domini di ricerca DNS per /etc/resolv.conf. Se definisci più di sei domini di ricerca, quando esegui il comando kubectl describe pod viene visualizzato il seguente avviso:

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

Per risolvere il problema, rimuovi i percorsi di ricerca aggiuntivi dalla configurazione.

Considera il limite di upstreamNameservers

Kubernetes impone un limite massimo di tre valori upstreamNameservers. Se definisci più di tre upstreamNameservers, vedrai il seguente errore in Cloud Logging nei log di deployment 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 fosse stato configurato alcun elemento upstreamNameservers. Per risolvere il problema, rimuovi l'elemento upstreamNameservers aggiuntivo dalla configurazione.

Limitazioni delle prestazioni con kube-dns

Se riscontri un'elevata latenza con le ricerche DNS o gli errori di risoluzione DNS con il provider kube-dns predefinito, il problema potrebbe essere dovuto al fatto che il tuo carico di lavoro esegue ricerche DNS frequenti o utilizzi una densità di pod per nodo maggiore.

Per migliorare i tempi di ricerca DNS, puoi scegliere una delle seguenti opzioni:

Record DNS del servizio

kube-dns crea record DNS solo per i servizi che hanno endpoint.

TTL di grandi dimensioni da server upstream DNS

Se kube-dns riceve una risposta DNS da un resolver DNS a monte con un TTL di grandi dimensioni o "infinito", mantiene 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 una panoramica sul DNS dei cluster in GKE.
  • Consulta la pagina DNS per servizi e pod per una panoramica generale sull'utilizzo del DNS nei cluster Kubernetes.