DNS e service discovery
Comprenda come i Pod si trovino tra loro usando il DNS integrato di Kubernetes e come funzioni la service discovery al suo interno.
DNS e service discovery è una lezione DevOps Bootcamp gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento DevOps Bootcamp, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso DevOps Bootcamp include 4 lezioni in totale.
Il problema della service discovery
I Pod vengono creati e rimossi continuamente e i loro indirizzi IP cambiano di frequente. Codificare gli IP direttamente nell'applicazione causerebbe problemi immediati. Kubernetes risolve questo problema con la service discovery basata su DNS.
Invece di un IP, si utilizza un nome stabile.
DNS del cluster
Ogni cluster esegue un servizio DNS (in genere CoreDNS). Questo servizio crea automaticamente record DNS per Service e Pod, in modo che i nomi vengano risolti nel ClusterIP corretto.
Nomi DNS dei Service
Un Service riceve un nome DNS che segue un modello prevedibile:
service-name.namespace.svc.cluster.local
All'interno dello stesso namespace è sufficiente usare il nome breve service-name.
# from a Pod in the same namespace
curl http://payment-service:8080
# fully qualified, from any namespace
curl http://payment-service.shop.svc.cluster.local:8080Namespace e denominazione
Il namespace fa parte del nome. Per raggiungere un Service in un altro namespace, lo includa: service.namespace.
# Pod in 'frontend' namespace calling 'backend' namespace
curl http://api.backend.svc.cluster.localTestare il DNS da un Pod
È possibile avviare un Pod temporaneo per testare la risoluzione dei nomi.
kubectl run dnstest --image=busybox:1.36 --rm -it --restart=Never -- nslookup payment-serviceCome CoreDNS risolve i nomi
Quando un Pod esegue una query per un nome, la richiesta viene inviata a CoreDNS. CoreDNS cerca il Service corrispondente e restituisce il relativo ClusterIP. Per i Service headless restituisce direttamente gli IP dei Pod.
Service headless
Un Service headless (clusterIP: None) non utilizza un singolo IP virtuale. Il DNS restituisce invece gli IP dei singoli Pod, una caratteristica essenziale per le applicazioni stateful che indirizzano direttamente i Pod.
apiVersion: v1
kind: Service
metadata:
name: db
spec:
clusterIP: None
selector:
app: db
ports:
- port: 5432Record DNS dei Pod
Con un Service headless, ogni Pod associato può anche ricevere il proprio record DNS, una funzione utile per gli StatefulSet, in cui i Pod hanno identità stabili come db-0 e db-1.
# stable per-Pod name in a StatefulSet
curl http://db-0.db.default.svc.cluster.local:5432Esaminare resolv.conf del Pod
Kubernetes inserisce la configurazione DNS in ogni Pod. I domini di ricerca consentono di risolvere correttamente i nomi brevi.
kubectl exec -it mypod -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.localVariabili d'ambiente e DNS a confronto
Kubernetes inserisce inoltre le informazioni di connessione dei Service come variabili d'ambiente, ma solo per i Service già esistenti al momento dell'avvio del Pod. È preferibile il DNS perché riflette sempre lo stato attuale.
Problemi comuni del DNS
- Dimenticare il namespace quando si effettua una chiamata tra namespace
- Aspettarsi il DNS per un Service senza Pod corrispondenti (nessun endpoint)
- Memorizzare nell'applicazione IP obsoleti invece di risolvere nuovamente il nome
Controllo rapido
Scelga il formato corretto del nome DNS.
Riepilogo
Ha appreso che Kubernetes utilizza CoreDNS per assegnare ai Service nomi DNS stabili secondo il formato service.namespace.svc.cluster.local. I nomi brevi funzionano all'interno di un namespace, i Service headless espongono gli IP dei singoli Pod e il DNS riflette sempre lo stato attuale del cluster.
Domande Frequenti
La lezione «DNS e service discovery» è gratuita?
Sì — il testo completo di «DNS e service discovery» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso DevOps Bootcamp, passa a CoddyKit PRO. Il corso DevOps Bootcamp include 4 lezioni in totale.
Cosa imparerò in «DNS e service discovery»?
Comprenda come i Pod si trovino tra loro usando il DNS integrato di Kubernetes e come funzioni la service discovery al suo interno. Eserciti DevOps Bootcamp con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare DevOps Bootcamp?
Non è richiesta alcuna esperienza precedente. DevOps Bootcamp su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.
Quanto tempo richiede la lezione «DNS e service discovery»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione DevOps Bootcamp?
Sì. Ogni lezione DevOps Bootcamp include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Esposizione delle app con i Service
- Tipi di Service: ClusterIP, NodePort, LoadBalancer
- Ingress per l'accesso esterno
- DNS e service discovery