Service discovery e DNS in Kubernetes
Scopra come i container si individuano tra loro: DNS del cluster, oggetti Service e flusso di risoluzione che rende i microservizi raggiungibili tramite nome.
Service discovery e DNS in Kubernetes è una lezione Linux Networking & TCP/IP for Developers 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 Linux Networking & TCP/IP for Developers, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Linux Networking & TCP/IP for Developers include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
The Discovery Problem
Container IPs are ephemeral — pods restart and get new addresses constantly. Hardcoding IPs is impossible.
Service discovery lets workloads find each other by stable names instead of changing IPs.
The Service Abstraction
A Kubernetes Service provides a stable virtual IP (ClusterIP) and DNS name that load-balances across a set of pods selected by labels.
apiVersion: v1
kind: Service
metadata:
name: orders
spec:
selector:
app: orders
ports:
- port: 80Cluster DNS
Every cluster runs a DNS server (CoreDNS). It automatically creates records for each Service so workloads can resolve them by name.
The DNS Naming Scheme
Services follow a predictable FQDN pattern:
service.namespace.svc.cluster.local
Within the same namespace, just orders works. Across namespaces use orders.payments.
curl http://orders.payments.svc.cluster.localHow a Pod Resolves Names
Each pod's /etc/resolv.conf points at the cluster DNS and includes search domains, so short names expand to full Service FQDNs automatically.
cat /etc/resolv.confClusterIP Load Balancing
A ClusterIP is virtual — kube-proxy programs iptables or IPVS rules so traffic to it is distributed across the healthy backing pods. Clients never see individual pod IPs.
Headless Services
Set clusterIP: None for a headless Service. DNS then returns the individual pod IPs directly, which is ideal for stateful sets and client-side load balancing.
spec:
clusterIP: None
selector:
app: dbEndpoints and EndpointSlices
Behind each Service, Kubernetes maintains EndpointSlices listing the ready pod IPs. As pods come and go, these update so DNS and routing stay current.
kubectl get endpointslicesResolving from Inside a Pod
You can debug discovery by running nslookup from a pod to verify a Service name resolves to its ClusterIP.
kubectl exec -it shell -- nslookup ordersExternal Name Services
An ExternalName Service maps a cluster DNS name to an outside hostname via a CNAME, letting you reference external systems with cluster-internal names.
spec:
type: ExternalName
externalName: api.example.comCommon Discovery Failures
When name resolution fails, check:
- Label selector mismatch (no endpoints)
- Wrong namespace in the FQDN
- CoreDNS pods unhealthy
- NetworkPolicy blocking DNS (port 53)
Quick Check
Test your service discovery knowledge.
Recap
You now understand container service discovery:
- Services give stable ClusterIPs and DNS names
- CoreDNS resolves
service.namespace.svc.cluster.local - EndpointSlices track ready pods
- Headless and ExternalName Services for special cases
- Debug with
nslookupfrom inside pods
This builds on your Docker network modes and Kubernetes networking basics.
Domande Frequenti
La lezione «Service discovery e DNS in Kubernetes» è gratuita?
Sì — il testo completo di «Service discovery e DNS in Kubernetes» è 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 Linux Networking & TCP/IP for Developers, passa a CoddyKit PRO. Il corso Linux Networking & TCP/IP for Developers include 4 lezioni in totale.
Cosa imparerò in «Service discovery e DNS in Kubernetes»?
Scopra come i container si individuano tra loro: DNS del cluster, oggetti Service e flusso di risoluzione che rende i microservizi raggiungibili tramite nome. Eserciti Linux Networking & TCP/IP for Developers 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 Linux Networking & TCP/IP for Developers?
Non è richiesta alcuna esperienza precedente. Linux Networking & TCP/IP for Developers 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 «Service discovery e DNS in Kubernetes»?
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 Linux Networking & TCP/IP for Developers?
Sì. Ogni lezione Linux Networking & TCP/IP for Developers 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
- Modalità di rete di Docker
- Fondamenti del networking in Kubernetes
- Policy di rete nei container
- Service discovery e DNS in Kubernetes