CKA · Módulo 6 · Services & Networking

Campo	Es el puerto de…
port	el Service (por donde le hablás)
port	the Service (where you address it)
port	il Service (dove gli parli)
targetPort	el container (a donde reenvía)
targetPort	the container (where it forwards)
targetPort	il container (dove inoltra)
nodePort	el nodo (solo tipo NodePort/LB)
nodePort	the node (NodePort/LB types only)
nodePort	il nodo (solo tipi NodePort/LB)

Tipo	Alcance	Uso típico
ClusterIP	Interno	Comunicación entre servicios
ClusterIP	Internal	Service-to-service traffic
ClusterIP	Interno	Traffico fra servizi
NodePort	IP nodo + puerto	Acceso externo básico / labs
NodePort	Node IP + port	Basic external access / labs
NodePort	IP nodo + porta	Accesso esterno base / lab
LoadBalancer	IP pública	Producción en la nube
LoadBalancer	Public IP	Cloud production
LoadBalancer	IP pubblico	Produzione in cloud
ExternalName	Solo DNS	Apuntar a algo de afuera
ExternalName	DNS only	Pointing at something outside
ExternalName	Solo DNS	Puntare a qualcosa di esterno

Parte	Qué es
web	nombre del Service
web	the Service's name
web	il nome del Service
default	namespace
default	namespace
default	namespace
svc	tipo de recurso
svc	resource type
svc	tipo di risorsa
cluster.local	dominio del cluster
cluster.local	the cluster domain
cluster.local	il dominio del cluster

dnsPolicy	El pod usa
`ClusterFirst`	El default real. CoreDNS, con los search del cluster
`ClusterFirst`	The actual default. CoreDNS, with the cluster search domains
`ClusterFirst`	Il default vero. CoreDNS, coi search domain del cluster
`Default`	El `resolv.conf` del nodo. No conoce el DNS del cluster
`Default`	The node's `resolv.conf`. It knows nothing of cluster DNS
`Default`	Il `resolv.conf` del nodo. Non conosce il DNS del cluster
`None`	Nada: lo definís vos entero en `dnsConfig`
`None`	Nothing: you define it all yourself in `dnsConfig`
`None`	Nulla: lo definisci tu per intero in `dnsConfig`
`ClusterFirstWithHostNet`	CoreDNS aun con `hostNetwork: true`
`ClusterFirstWithHostNet`	CoreDNS even with `hostNetwork: true`
`ClusterFirstWithHostNet`	CoreDNS anche con `hostNetwork: true`

Modo	Estado
iptables	Default histórico, el más común
iptables	Historic default, the most common
iptables	Default storico, il più comune
nftables	GA desde 1.33, mejor a gran escala
nftables	GA since 1.33, better at scale
nftables	GA dalla 1.33, meglio su larga scala
ipvs	Más algoritmos de balanceo
ipvs	More balancing algorithms
ipvs	Più algoritmi di bilanciamento

★

Fase 2 · resolver en vivo

Phase 2 · solve it live

Fase 2 · risolvere dal vivo

Práctica — 9 ejercicios

Practice — 9 exercises

Pratica — 9 esercizi

Cinco de construcción, cuatro de troubleshooting. Todo se verifica por endpoints.

Five building, four troubleshooting. Everything is verified through endpoints.

Cinque di costruzione, quattro di troubleshooting. Tutto si verifica tramite gli endpoint.

0 / 9

◆

Manifests publicados. Cada ejercicio tiene su YAML servido por este mismo sitio: k apply -f <url>/manifests/m6e1.yaml. Los E son la solución de referencia; los T plantan el problema — aplicalos y diagnosticá sin leerlos. Todos crean el namespace net y k delete -f <misma-url> los limpia. Excepción: T3, cuyo manifest solo arma el escenario — la rotura toca kube-system y va a mano, porque un YAML público que te deje el cluster entero sin DNS es un pie de plomo. Cada tarjeta trae el comando exacto, con botón de copiar.

Published manifests. Every exercise has its YAML served by this very site: k apply -f <url>/manifests/m6e1.yaml. The E ones are the reference solution; the T ones plant the problem — apply them and diagnose without reading them. All create namespace net and k delete -f <same-url> cleans up. Exception: T3, whose manifest only sets the scene — the break touches kube-system and is done by hand, because a public YAML that leaves your whole cluster without DNS is a footgun. Each card carries the exact command, with a copy button.

Manifest pubblicati. Ogni esercizio ha il suo YAML servito da questo stesso sito: k apply -f <url>/manifests/m6e1.yaml. Gli E sono la soluzione di riferimento; i T piantano il problema — applicali e diagnostica senza leggerli. Tutti creano il namespace net e k delete -f <stessa-url> pulisce. Eccezione: il T3, il cui manifest prepara solo lo scenario — la rottura tocca kube-system e si fa a mano, perché uno YAML pubblico che ti lascia l'intero cluster senza DNS è un'arma puntata al piede. Ogni scheda porta il comando esatto, con pulsante copia.

🧠

Modelo mental. Service = selector + puertos → EndpointSlice. Cada ejercicio termina en la misma pregunta: ¿tiene endpoints? Si la respuesta es no, ya sabés que es el selector o la readiness. Nunca "arregles" adivinando: mirá primero describe svc.

Mental model. Service = selector + ports → EndpointSlice. Every exercise ends at the same question: does it have endpoints? If the answer is no, you already know it is the selector or readiness. Never "fix" by guessing: look at describe svc first.

Modello mentale. Service = selector + porte → EndpointSlice. Ogni esercizio finisce alla stessa domanda: ha endpoint? Se la risposta è no, sai già che è il selector o la readiness. Non "aggiustare" a indovinare: guarda prima describe svc.

◆

Preparación. Nada de esto rompe el cluster. Trabajá en un namespace descartable: k create ns net && k config set-context --current -n net, y al final k delete ns net. Para T3 sí conviene un snapshot: se toca CoreDNS.

Setup. None of this breaks the cluster. Work in a throwaway namespace: k create ns net && k config set-context --current -n net, and at the end k delete ns net. For T3 a snapshot is worth having: it touches CoreDNS.

Preparazione. Nulla di questo rompe il cluster. Lavora in un namespace usa e getta: k create ns net && k config set-context --current -n net, e alla fine k delete ns net. Per T3 conviene uno snapshot: si tocca CoreDNS.

Del deployment al Service, verificando

From deployment to Service, verified

Dal deployment al Service, verificando

~5 min hecho

Creá un Deployment web (nginx, 3 réplicas) y exponelo como ClusterIP en el puerto 80. Después probá, en este orden: que el Service existe, que tiene 3 endpoints, y que responde desde otro pod por nombre. Finalmente borrá un pod y verificá que el EndpointSlice se actualiza solo.

Create a Deployment web (nginx, 3 replicas) and expose it as ClusterIP on port 80. Then check, in this order: the Service exists, it has 3 endpoints, and it answers from another pod by name. Finally delete a pod and verify the EndpointSlice updates on its own.

Crea un Deployment web (nginx, 3 repliche) ed esponilo come ClusterIP sulla porta 80. Poi verifica, in quest'ordine: il Service esiste, ha 3 endpoint, e risponde da un altro pod per nome. Infine cancella un pod e verifica che l'EndpointSlice si aggiorni da solo.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

k create deploy web --image=nginx --replicas=3
k expose deploy web --port=80

k get svc web -o wide                # mirá la columna SELECTOR# look at the SELECTOR column# guarda la colonna SELECTOR
k describe svc web | grep -i endpoints
k get endpointslices -l kubernetes.io/service-name=web

k run tmp --rm -it --image=nginx -- curl -s web:80

k delete pod -l app=web --field-selector=status.phase=Running --wait=false
k get endpointslices -l kubernetes.io/service-name=web -o wide

Claves

Key points

Punti chiave

expose hereda el selector del Deployment, así que los endpoints salen bien de una: es la razón por la que casi siempre se prefiere sobre create service.
El EndpointSlice se recalcula solo cuando los pods cambian: es un controller observando labels, no una lista que mantengas vos.
Verificar por endpoints, no por "se creó el objeto". Un Service se crea siempre, aunque no sirva a nadie.

expose inherits the Deployment's selector, so endpoints come out right first time: that is why it is nearly always preferred over create service.
The EndpointSlice recalculates itself when pods change: it is a controller watching labels, not a list you maintain.
Verify by endpoints, not by "the object was created". A Service is always created, even when it serves nobody.

expose eredita il selector del Deployment, quindi gli endpoint escono giusti al primo colpo: per questo si preferisce quasi sempre a create service.
L'EndpointSlice si ricalcola da solo quando i pod cambiano: è un controller che osserva le label, non una lista che mantieni tu.
Verifica per endpoint, non per "l'oggetto è stato creato". Un Service viene sempre creato, anche se non serve nessuno.

port vs targetPort: el que conecta pero falla

port vs targetPort: it connects but fails

port contro targetPort: si connette ma fallisce

~5 min hecho

Creá un Deployment api con la imagen hashicorp/http-echo, argumentos -text=hola y -listen=:5678. Exponelo de forma que se le pueda pegar en el puerto 80 del Service. Primero hacelo mal a propósito (sin --target-port) y observá el síntoma; después corregilo.

Create a Deployment api with the image hashicorp/http-echo, args -text=hola and -listen=:5678. Expose it so it can be hit on the Service's port 80. First do it wrong on purpose (no --target-port) and observe the symptom; then fix it.

Crea un Deployment api con l'immagine hashicorp/http-echo, argomenti -text=hola e -listen=:5678. Esponilo in modo da poterlo colpire sulla porta 80 del Service. Prima fallo sbagliato di proposito (senza --target-port) e osserva il sintomo; poi correggilo.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

k create deploy api --image=hashicorp/http-echo -- -text=hola -listen=:5678

# MAL: targetPort asume 80, pero la app escucha en 5678# WRONG: targetPort assumes 80, but the app listens on 5678# SBAGLIATO: targetPort assume 80, ma l'app ascolta su 5678
k expose deploy api --port=80
k run t --rm -it --image=nginx -- curl -s --max-time 5 api:80
#   cuelga y muere por timeout — y el Service TIENE endpoints#   hangs and dies on timeout — and the Service DOES have endpoints#   si blocca e muore in timeout — e il Service HA endpoint

# BIEN# RIGHT# GIUSTO
k delete svc api
k expose deploy api --port=80 --target-port=5678
k run t --rm -it --image=nginx -- curl -s api:80    #  hola

Claves

Key points

Punti chiave

El síntoma distingue el diagnóstico. Selector mal = cero endpoints. targetPort mal = endpoints correctos pero timeout. Si ves endpoints y no anda, mirá los puertos.
Sin --target-port, kubectl asume targetPort = port. Es el default más traicionero del módulo.
Alternativa robusta: nombrá el containerPort (name: http) y usá targetPort: http.

The symptom tells the diagnosis apart. Wrong selector = zero endpoints. Wrong targetPort = correct endpoints but timeouts. If you see endpoints and it still fails, look at the ports.
Without --target-port, kubectl assumes targetPort = port. The most treacherous default in the module.
Robust alternative: name the containerPort (name: http) and use targetPort: http.

Il sintomo distingue la diagnosi. Selector sbagliato = zero endpoint. targetPort sbagliato = endpoint corretti ma timeout. Se vedi endpoint e non va, guarda le porte.
Senza --target-port, kubectl assume targetPort = port. Il default più insidioso del modulo.
Alternativa robusta: dai un nome al containerPort (name: http) e usa targetPort: http.

NodePort con puerto fijo (generá y editá)

NodePort with a pinned port (generate and edit)

NodePort con porta fissa (genera e modifica)

~5 min hecho

Exponé el Deployment web como NodePort en el puerto 30080 exacto. Probalo desde tu máquina contra la IP de un worker que no tenga pods de web, y explicá por qué igual funciona. Después confirmá que el ClusterIP sigue vivo.

Expose the web Deployment as NodePort on the exact port 30080. Test it from your machine against the IP of a worker that has no web pods, and explain why it still works. Then confirm the ClusterIP is still alive.

Esponi il Deployment web come NodePort sulla porta 30080 esatta. Provalo dalla tua macchina contro l'IP di un worker che non ha pod di web, e spiega perché funziona lo stesso. Poi conferma che il ClusterIP è ancora vivo.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

# expose no tiene flag para nodePort fijo → generá y editá# expose has no flag for a pinned nodePort → generate and edit# expose non ha un flag per il nodePort fisso → genera e modifica
k expose deploy web --port=80 --type=NodePort --name=web-np $do > np.yaml
vim np.yaml        # en ports[0]: nodePort: 30080# in ports[0]: nodePort: 30080# in ports[0]: nodePort: 30080
k apply -f np.yaml

k get nodes -o wide
k get pods -l app=web -o wide    # elegí un nodo SIN pods# pick a node WITHOUT pods# scegli un nodo SENZA pod
curl http://<IP-DE-ESE-NODO>:30080

k run t --rm -it --image=nginx -- curl -s web-np:80   # el ClusterIP sigue# ClusterIP still works# il ClusterIP funziona ancora

Claves

Key points

Punti chiave

Funciona en cualquier nodo porque kube-proxy programa las reglas en todos los nodos: el que recibe reenvía al pod, esté donde esté.
Los tipos se anidan. Un NodePort sigue teniendo su ClusterIP y su nombre DNS: no reemplazaste nada, agregaste una capa.
El patrón "generá con $do, editá una línea, aplicá" resuelve todo lo que no tiene flag. Es más rápido que escribir el YAML entero.

It works on any node because kube-proxy programs the rules on every node: whichever receives it forwards to the pod, wherever that is.
The types nest. A NodePort still has its ClusterIP and DNS name: you replaced nothing, you added a layer.
The "generate with $do, edit one line, apply" pattern covers everything that has no flag. Faster than writing the whole YAML.

Funziona su qualsiasi nodo perché kube-proxy programma le regole su tutti i nodi: quello che riceve inoltra al pod, ovunque sia.
I tipi si annidano. Un NodePort mantiene il suo ClusterIP e il nome DNS: non hai sostituito nulla, hai aggiunto uno strato.
Il pattern "genera con $do, modifica una riga, applica" copre tutto ciò che non ha un flag. Più rapido che scrivere l'intero YAML.

Headless: DNS que devuelve pods

Headless: DNS that returns pods

Headless: DNS che restituisce pod

~6 min hecho

Creá un Service headless web-h apuntando a los pods de web. Desde un pod, comparativamente: nslookup web y nslookup web-h. Explicá la diferencia en la salida. Extra: creá un StatefulSet db de 2 réplicas con su headless y resolvé db-0 por nombre.

Create a headless Service web-h pointing at the web pods. From a pod, compare: nslookup web and nslookup web-h. Explain the difference in the output. Extra: create a 2-replica StatefulSet db with its headless Service and resolve db-0 by name.

Crea un Service headless web-h che punti ai pod di web. Da un pod, confronta: nslookup web e nslookup web-h. Spiega la differenza nell'output. Extra: crea uno StatefulSet db di 2 repliche col suo headless e risolvi db-0 per nome.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

k expose deploy web --port=80 --name=web-h $do > h.yaml
vim h.yaml          # en spec:  clusterIP: None# under spec:  clusterIP: None# sotto spec:  clusterIP: None
k apply -f h.yaml
k get svc                        # web-h tiene CLUSTER-IP None# web-h has CLUSTER-IP None# web-h ha CLUSTER-IP None

k run dns --rm -it --image=busybox:1.28 -- sh
#   nslookup web     -> 1 dirección: la VIP 10.96.x.x#   nslookup web     -> 1 address: the VIP 10.96.x.x#   nslookup web     -> 1 indirizzo: la VIP 10.96.x.x
#   nslookup web-h   -> 3 direcciones: las IPs de los pods#   nslookup web-h   -> 3 addresses: the pod IPs#   nslookup web-h   -> 3 indirizzi: gli IP dei pod

# StatefulSet: cada pod tiene nombre DNS propio y estable# StatefulSet: each pod has its own stable DNS name# StatefulSet: ogni pod ha un nome DNS proprio e stabile
nslookup db-0.db.net.svc.cluster.local

Claves

Key points

Punti chiave

clusterIP: None es lo único que lo vuelve headless. Sigue teniendo selector y endpoints — lo que no tiene es VIP ni balanceo.
El cliente elige la instancia. Por eso es la base de los StatefulSets: sin identidad por pod, una réplica de base de datos no sirve.
Patrón de nombre: POD-N.SERVICIO.NAMESPACE.svc.cluster.local. Solo existe con un Service headless.

clusterIP: None is the only thing making it headless. It still has a selector and endpoints — what it lacks is a VIP and balancing.
The client picks the instance. That is why it underpins StatefulSets: without per-pod identity, a database replica is useless.
Name pattern: POD-N.SERVICE.NAMESPACE.svc.cluster.local. It only exists with a headless Service.

clusterIP: None è l'unica cosa che lo rende headless. Ha ancora selector ed endpoint — ciò che manca è la VIP e il bilanciamento.
Il client sceglie l'istanza. Per questo è la base degli StatefulSet: senza identità per pod, una replica di database è inutile.
Schema del nome: POD-N.SERVICE.NAMESPACE.svc.cluster.local. Esiste solo con un Service headless.

DNS cross-namespace y ExternalName

Cross-namespace DNS and ExternalName

DNS cross-namespace ed ExternalName

~6 min hecho

Con web en el namespace net, levantá un pod cliente en otro e intentá curl web. Falla: arreglalo sin tocar el Service. Después creá un ExternalName externo que apunte a example.com y resolvelo desde un pod. ¿Qué tipo de registro DNS devuelve?

With web in the net namespace, start a client pod in otro and try curl web. It fails: fix it without touching the Service. Then create an ExternalName externo pointing at example.com and resolve it from a pod. What kind of DNS record comes back?

Con web nel namespace net, avvia un pod client in otro e prova curl web. Fallisce: sistemalo senza toccare il Service. Poi crea un ExternalName externo che punti a example.com e risolvilo da un pod. Che tipo di record DNS restituisce?

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

k create ns otro
k run t -n otro --rm -it --image=nginx -- curl -s --max-time 5 web
#   falla: busca web.otro.svc..., no web.net.svc...#   fails: it looks up web.otro.svc..., not web.net.svc...#   fallisce: cerca web.otro.svc..., non web.net.svc...

k run t -n otro --rm -it --image=nginx -- curl -s web.net        #  OK
k run t -n otro --rm -it --image=nginx -- curl -s web.net.svc.cluster.local

k create service externalname externo --external-name=example.com
k run dns --rm -it --image=busybox:1.28 -- nslookup externo
#   devuelve un CNAME a example.com: sin ClusterIP, sin endpoints, sin proxy#   returns a CNAME to example.com: no ClusterIP, no endpoints, no proxying#   restituisce un CNAME a example.com: nessun ClusterIP, nessun endpoint, nessun proxy

Claves

Key points

Punti chiave

El nombre corto usa los search domains del pod, que empiezan por su propio namespace. Cross-namespace exige al menos servicio.namespace.
Es una de las causas más frecuentes del "no le puedo hablar al otro servicio" en el examen, y no deja ningún error en logs: solo un DNS que no resuelve.
ExternalName no es un proxy: es puro DNS. No tiene ClusterIP ni endpoints, y el tráfico nunca pasa por Kubernetes.

The short name uses the pod's search domains, which begin with its own namespace. Cross-namespace needs at least service.namespace.
It is one of the most frequent causes of "I cannot reach the other service" in the exam, and it leaves no error in logs: just DNS that does not resolve.
ExternalName is not a proxy: it is pure DNS. No ClusterIP, no endpoints, and traffic never goes through Kubernetes.

Il nome breve usa i search domain del pod, che iniziano dal suo namespace. Il cross-namespace richiede almeno service.namespace.
È una delle cause più frequenti del "non riesco a raggiungere l'altro servizio" all'esame, e non lascia alcun errore nei log: solo un DNS che non risolve.
ExternalName non è un proxy: è puro DNS. Nessun ClusterIP, nessun endpoint, e il traffico non passa mai da Kubernetes.

Troubleshooting — cero endpoints por selector

Troubleshooting — zero endpoints, bad selector

Troubleshooting — zero endpoint, selector sbagliato

~6 min hecho

Un Service shop existe, tiene ClusterIP, y curl shop desde otro pod muere por timeout sin ningún error en los logs de la app. Encontrá la causa y arreglala sin borrar el Service.

A Service shop exists, has a ClusterIP, and curl shop from another pod dies on timeout with no error in the app logs. Find the cause and fix it without deleting the Service.

Un Service shop esiste, ha un ClusterIP, e curl shop da un altro pod muore in timeout senza alcun errore nei log dell'app. Trova la causa e sistemala senza cancellare il Service.

manifest · plantar el problemamanifest · plant the problemmanifest · piantare il problema

Ver soluciónShow solutionMostra soluzione

Equivalente imperativo: k create deploy tienda --image=nginx + k create service clusterip shop --tcp=80:80 — create service se inventa el selector app=shop.

Imperative equivalent: k create deploy tienda --image=nginx + k create service clusterip shop --tcp=80:80 — create service invents the selector app=shop.

Equivalente imperativo: k create deploy tienda --image=nginx + k create service clusterip shop --tcp=80:80 — create service si inventa il selector app=shop.

k describe svc shop | grep -iE 'selector|endpoints'
#   Selector: app=shop   ·   Endpoints: <none>   ← ahí está#   Selector: app=shop   ·   Endpoints: <none>   ← there it is#   Selector: app=shop   ·   Endpoints: <none>   ← eccolo

k get pods -l app=shop            # no hay ninguno# none at all# nessuno
k get pods --show-labels          # los pods dicen app=tienda# the pods say app=tienda# i pod dicono app=tienda

# dos formas de arreglarlo; la primera es la más limpia# two ways to fix it; the first is cleanest# due modi per sistemarlo; il primo è il più pulito
k set selector svc shop app=tienda
#   o: k patch svc shop -p '{"spec":{"selector":{"app":"tienda"}}}'#   or: k patch svc shop -p '{"spec":{"selector":{"app":"tienda"}}}'#   oppure: k patch svc shop -p '{"spec":{"selector":{"app":"tienda"}}}'

k describe svc shop | grep -i endpoints   # ahora sí# now it is populated# ora è popolato

Claves

Key points

Punti chiave

Falla en silencio. El Service se crea, tiene IP, el DNS resuelve — y no hay nadie detrás. Ningún log de la app va a mencionarlo: la app nunca recibe la conexión.
create service se inventa el selector app=<nombre-del-service>. Por eso expose es el camino por defecto.
--show-labels es el comando que resuelve este caso en 5 segundos. Tenelo a mano.

It fails silently. The Service is created, has an IP, DNS resolves — and there is nobody behind it. No app log will mention it: the app never receives the connection.
create service invents the selector app=<service-name>. That is why expose is the default path.
--show-labels is the command that cracks this in 5 seconds. Keep it handy.

Fallisce in silenzio. Il Service viene creato, ha un IP, il DNS risolve — e dietro non c'è nessuno. Nessun log dell'app lo menzionerà: l'app non riceve mai la connessione.
create service si inventa il selector app=<nome-del-service>. Per questo expose è la strada di default.
--show-labels è il comando che risolve questo caso in 5 secondi. Tienilo a portata.

Troubleshooting — la readinessProbe que vacía el Service

Troubleshooting — the readinessProbe that empties the Service

Troubleshooting — la readinessProbe che svuota il Service

~6 min hecho

El selector del Service es correcto y los pods están Running, pero el Service no tiene endpoints. Diagnosticá y arreglá.

The Service selector is correct and the pods are Running, but the Service has no endpoints. Diagnose and fix.

Il selector del Service è corretto e i pod sono Running, ma il Service non ha endpoint. Diagnostica e sistema.

manifest · plantar el problemamanifest · plant the problemmanifest · piantare il problema

Ver soluciónShow solutionMostra soluzione

Equivalente imperativo: agregarle al deployment una readinessProbe HTTP contra /healthz en el puerto 80 — nginx no sirve esa ruta.

Imperative equivalent: add an HTTP readinessProbe against /healthz on port 80 to the deployment — nginx does not serve that path.

Equivalente imperativo: aggiungere al deployment una readinessProbe HTTP verso /healthz sulla porta 80 — nginx non serve quel path.

k get pods -l app=front
#   READY 0/1 pero STATUS Running ← la pista está en READY, no en STATUS#   READY 0/1 but STATUS Running ← the clue is in READY, not STATUS#   READY 0/1 ma STATUS Running ← l'indizio è in READY, non in STATUS

k describe pod <pod> | grep -A5 -i readiness
k describe pod <pod> | tail -20
#   Warning  Unhealthy  Readiness probe failed: HTTP probe returned 404

# arreglar la ruta (o el puerto) de la probe# fix the probe's path (or port)# sistemare il path (o la porta) della probe
k edit deploy front        # path: /healthz  →  /# path: /healthz  →  /# path: /healthz  →  /

k get pods -l app=front                              #  1/1
k describe svc front | grep -i endpoints            #  poblado#  populated#  popolato

Claves

Key points

Punti chiave

Running ≠ Ready. La columna que importa para el Service es READY: solo los Ready entran al EndpointSlice.
Los Events del describe pod te dicen exactamente por qué falla la probe (código HTTP, connection refused, timeout).
Es el mismo síntoma que T1 (cero endpoints) con causa distinta. Por eso el orden del diagnóstico importa: primero selector, después readiness.

Running ≠ Ready. The column that matters to the Service is READY: only Ready pods enter the EndpointSlice.
The Events in describe pod tell you exactly why the probe fails (HTTP code, connection refused, timeout).
It is the same symptom as T1 (zero endpoints) with a different cause. That is why diagnostic order matters: selector first, readiness second.

Running ≠ Ready. La colonna che conta per il Service è READY: solo i Ready entrano nell'EndpointSlice.
Gli Events del describe pod dicono esattamente perché la probe fallisce (codice HTTP, connection refused, timeout).
È lo stesso sintomo di T1 (zero endpoint) con causa diversa. Per questo l'ordine diagnostico conta: prima il selector, poi la readiness.

Troubleshooting — el DNS del cluster no resuelve

Troubleshooting — cluster DNS does not resolve

Troubleshooting — il DNS del cluster non risolve

~7 min hecho

Ningún pod resuelve nombres: curl web da could not resolve host, pero curl <ClusterIP> anda perfecto. Diagnosticá siguiendo la cadena completa y arreglá.

Para plantarlo: el manifest solo deja el blanco armado; la rotura va a mano, porque toca kube-system: k -n kube-system scale deploy coredns --replicas=0. Snapshot antes, y para restaurar --replicas=2.

No pod resolves names: curl web gives could not resolve host, but curl <ClusterIP> works fine. Diagnose along the full chain and fix.

To plant it: the manifest only sets up the target; the break is done by hand, because it touches kube-system: k -n kube-system scale deploy coredns --replicas=0. Snapshot first, and restore with --replicas=2.

Nessun pod risolve i nomi: curl web dà could not resolve host, ma curl <ClusterIP> funziona benissimo. Diagnostica lungo tutta la catena e sistema.

Per prepararlo: il manifest prepara solo il bersaglio; la rottura si fa a mano, perché tocca kube-system: k -n kube-system scale deploy coredns --replicas=0. Prima lo snapshot, e per ripristinare --replicas=2.

manifest · armar el escenariomanifest · set the scenemanifest · preparare lo scenario

Ver soluciónShow solutionMostra soluzione

# el hecho clave: por IP funciona, por nombre no → es DNS, no red# the key fact: by IP it works, by name it does not → it is DNS, not networking# il fatto chiave: per IP funziona, per nome no → è DNS, non rete

# 1 · ¿corren los pods de CoreDNS?# 1 · are the CoreDNS pods running?# 1 · i pod di CoreDNS girano?
k get pods -n kube-system -l k8s-app=kube-dns     # ninguno# none# nessuno

# 2 · ¿el Service kube-dns tiene endpoints?# 2 · does the kube-dns Service have endpoints?# 2 · il Service kube-dns ha endpoint?
k -n kube-system describe svc kube-dns | grep -i endpoints

# 3 · ¿el pod apunta al nameserver correcto?# 3 · does the pod point at the right nameserver?# 3 · il pod punta al nameserver giusto?
k exec <pod> -- cat /etc/resolv.conf        #  nameserver 10.96.0.10

# 4 · arreglar y reverificar# 4 · fix and re-verify# 4 · sistemare e riverificare
k -n kube-system scale deploy coredns --replicas=2
k run dns --rm -it --image=busybox:1.28 -- nslookup web

Claves

Key points

Punti chiave

"Por IP sí, por nombre no" divide el problema al instante: la red está bien, el que falla es el DNS. Ese contraste es el primer test que hacés siempre.
La cadena de DNS tiene 3 eslabones: pods de CoreDNS → Service kube-dns con endpoints → resolv.conf del pod. Se revisan en ese orden.
CoreDNS es un Deployment normal: se diagnostica con logs, describe y get cm coredns como cualquier app. Un Corefile roto también se ve en sus logs.
Recordá que sin CNI no hay red de pods, y sin red de pods CoreDNS queda Pending: es la variante de este mismo problema que ya viviste al armar el cluster.

"By IP yes, by name no" splits the problem instantly: networking is fine, DNS is what fails. That contrast is the first test you always run.
The DNS chain has 3 links: CoreDNS pods → kube-dns Service with endpoints → the pod's resolv.conf. Check them in that order.
CoreDNS is an ordinary Deployment: diagnose it with logs, describe and get cm coredns like any app. A broken Corefile shows up in its logs too.
Remember that without a CNI there is no pod network, and without a pod network CoreDNS stays Pending: the variant of this same problem you already lived while building the cluster.

"Per IP sì, per nome no" divide il problema all'istante: la rete è a posto, a fallire è il DNS. Quel contrasto è il primo test che fai sempre.
La catena DNS ha 3 anelli: pod di CoreDNS → Service kube-dns con endpoint → resolv.conf del pod. Si controllano in quest'ordine.
CoreDNS è un Deployment normale: si diagnostica con logs, describe e get cm coredns come qualsiasi app. Anche un Corefile rotto si vede nei suoi log.
Ricorda che senza CNI non c'è rete dei pod, e senza rete dei pod CoreDNS resta Pending: è la variante di questo stesso problema che hai già vissuto costruendo il cluster.

Troubleshooting — el pod que no resuelve, con el DNS sano

Troubleshooting — the pod that will not resolve, with DNS healthy

Troubleshooting — il pod che non risolve, col DNS sano

~6 min hecho

Dos clientes con la misma imagen en el mismo namespace: cliente-a resuelve web y cliente-b no. CoreDNS está perfecto y el resto del cluster también. Encontrá la diferencia y arreglá cliente-b.

Antes de tocar nada, hacé una prueba más desde cliente-b: probá resolver un nombre de internet. La respuesta cambia todo el diagnóstico.

Two clients with the same image in the same namespace: cliente-a resolves web and cliente-b does not. CoreDNS is perfectly healthy and so is the rest of the cluster. Find the difference and fix cliente-b.

Before touching anything, run one more test from cliente-b: try resolving an internet name. The answer changes the whole diagnosis.

Due client con la stessa immagine nello stesso namespace: cliente-a risolve web e cliente-b no. CoreDNS è perfettamente sano e anche il resto del cluster. Trova la differenza e sistema cliente-b.

Prima di toccare qualsiasi cosa, fai un'altra prova da cliente-b: prova a risolvere un nome di internet. La risposta cambia tutta la diagnosi.

manifest · plantar el problemamanifest · plant the problemmanifest · piantare il problema

Ver soluciónShow solutionMostra soluzione

k exec deploy/cliente-a -- curl -s --max-time 5 web     # anda# works# funziona
k exec deploy/cliente-b -- curl -s --max-time 5 web        # could not resolve host
k exec deploy/cliente-b -- curl -sI --max-time 5 example.com
#   ¡SÍ resuelve internet! → el DNS del pod anda, pero no es el del cluster#   it DOES resolve the internet! → the pod's DNS works, just not the cluster's#   risolve internet! → il DNS del pod funziona, ma non è quello del cluster

# comparar el resolv.conf de los dos: ahí está todo# compare both resolv.conf files: everything is there# confrontare i due resolv.conf: è tutto lì
k exec deploy/cliente-a -- cat /etc/resolv.conf
#   nameserver 10.96.0.10        search net.svc.cluster.local ...   ndots:5
k exec deploy/cliente-b -- cat /etc/resolv.conf
#   el nameserver del NODO, sin search domains del cluster#   the NODE's nameserver, with no cluster search domains#   il nameserver del NODO, senza i search domain del cluster

k get deploy cliente-b -o jsonpath='{.spec.template.spec.dnsPolicy}'; echo
#   Default   <- el culpable

# arreglo: volver al DNS del cluster# fix: go back to cluster DNS# fix: tornare al DNS del cluster
k patch deploy cliente-b -p '{"spec":{"template":{"spec":{"dnsPolicy":"ClusterFirst"}}}}'
k rollout status deploy/cliente-b
k exec deploy/cliente-b -- curl -s web

Claves

Key points

Punti chiave

El nombre del campo miente: dnsPolicy: Default NO es el default. El default real es ClusterFirst. Default significa "heredá el resolv.conf del nodo", que no conoce el DNS del cluster.
Resolver internet pero no servicios internos es la firma exacta de este caso. Si CoreDNS estuviera caído (T3) no resolvería nada; si fuera una NetworkPolicy de egress, tampoco. Que ande lo de afuera y falle lo de adentro apunta al resolv.conf del pod, no al servidor.
Un solo pod afectado y el resto sano ⇒ el problema es del pod. Este contraste es el que te ahorra ir a mirar kube-system: T3 se diagnostica hacia el servidor, T4 hacia el cliente.
Comparar el resolv.conf de un pod sano contra el del roto es el atajo del ejercicio. Las tres cosas que mirás son nameserver, search y ndots.

The field name lies: dnsPolicy: Default is NOT the default. The real default is ClusterFirst. Default means "inherit the node's resolv.conf", which knows nothing about cluster DNS.
Resolving the internet but not internal services is this case's exact signature. If CoreDNS were down (T3) nothing would resolve; nor would it with an egress NetworkPolicy. Outside working and inside failing points at the pod's resolv.conf, not at the server.
One pod affected and the rest healthy ⇒ the problem belongs to the pod. That contrast is what saves you a trip to kube-system: T3 is diagnosed towards the server, T4 towards the client.
Comparing a healthy pod's resolv.conf against the broken one is the exercise's shortcut. The three things to read are nameserver, search and ndots.

Il nome del campo mente: dnsPolicy: Default NON è il default. Il default vero è ClusterFirst. Default significa "eredita il resolv.conf del nodo", che non conosce il DNS del cluster.
Risolvere internet ma non i servizi interni è la firma esatta di questo caso. Se CoreDNS fosse caduto (T3) non risolverebbe nulla; nemmeno con una NetworkPolicy di egress. Che funzioni il fuori e fallisca il dentro punta al resolv.conf del pod, non al server.
Un solo pod colpito e il resto sano ⇒ il problema è del pod. Questo contrasto ti risparmia il giro in kube-system: il T3 si diagnostica verso il server, il T4 verso il client.
Confrontare il resolv.conf di un pod sano con quello rotto è la scorciatoia dell'esercizio. Le tre cose da leggere sono nameserver, search e ndots.

Autoevaluación — antes de marcar M6 como ★ dominado

Self-check — before marking M6 as ★ mastered

Autovalutazione — prima di segnare M6 come ★ padroneggiato

Exponer un Deployment y verificar endpoints en menos de 1 min.
Explicar la diferencia entre port, targetPort y nodePort sin dudar.
Fijar un nodePort concreto usando $do + editar.
Explicar por qué un NodePort responde en un nodo sin pods.
Crear un headless y decir qué devuelve su DNS.
Escribir el FQDN completo de un Service de memoria.
Diagnosticar cero endpoints distinguiendo selector de readiness.
Diagnosticar un fallo de DNS recorriendo los 3 eslabones.

Expose a Deployment and verify endpoints in under 1 min.
Explain the difference between port, targetPort and nodePort without hesitating.
Pin a specific nodePort using $do + edit.
Explain why a NodePort answers on a node with no pods.
Create a headless Service and say what its DNS returns.
Write a Service's full FQDN from memory.
Diagnose zero endpoints, telling selector apart from readiness.
Diagnose a DNS failure along the 3 links.

Esporre un Deployment e verificare gli endpoint in meno di 1 min.
Spiegare la differenza fra port, targetPort e nodePort senza esitare.
Fissare un nodePort specifico usando $do + modifica.
Spiegare perché un NodePort risponde su un nodo senza pod.
Creare un Service headless e dire cosa restituisce il suo DNS.
Scrivere l'FQDN completo di un Service a memoria.
Diagnosticare zero endpoint distinguendo selector da readiness.
Diagnosticare un guasto DNS percorrendo i 3 anelli.

Campo	Es el puerto de…
Field	Is the port of…
Campo	È la porta di…
port	el Service (por donde le hablás)
port	the Service (where you address it)
port	il Service (dove gli parli)
targetPort	el container (a donde reenvía)
targetPort	the container (where it forwards)
targetPort	il container (dove inoltra)
nodePort	el nodo (solo tipo NodePort/LB)
nodePort	the node (NodePort/LB types only)
nodePort	il nodo (solo tipi NodePort/LB)

Tipo	Alcance	Uso típico
Type	Reach	Typical use
Tipo	Portata	Uso tipico
ClusterIP	Interno	Comunicación entre servicios
ClusterIP	Internal	Service-to-service traffic
ClusterIP	Interno	Traffico fra servizi
NodePort	IP nodo + puerto	Acceso externo básico / labs
NodePort	Node IP + port	Basic external access / labs
NodePort	IP nodo + porta	Accesso esterno base / lab
LoadBalancer	IP pública	Producción en la nube
LoadBalancer	Public IP	Cloud production
LoadBalancer	IP pubblico	Produzione in cloud
ExternalName	Solo DNS	Apuntar a algo de afuera
ExternalName	DNS only	Pointing at something outside
ExternalName	Solo DNS	Puntare a qualcosa di esterno

Parte	Qué es
Part	What it is
Parte	Cos'è
web	nombre del Service
web	the Service's name
web	il nome del Service
default	namespace
default	namespace
default	namespace
svc	tipo de recurso
svc	resource type
svc	tipo di risorsa
cluster.local	dominio del cluster
cluster.local	the cluster domain
cluster.local	il dominio del cluster

dnsPolicy	El pod usa
dnsPolicy	The pod uses
dnsPolicy	Il pod usa
`ClusterFirst`	El default real. CoreDNS, con los search del cluster
`ClusterFirst`	The actual default. CoreDNS, with the cluster search domains
`ClusterFirst`	Il default vero. CoreDNS, coi search domain del cluster
`Default`	El `resolv.conf` del nodo. No conoce el DNS del cluster
`Default`	The node's `resolv.conf`. It knows nothing of cluster DNS
`Default`	Il `resolv.conf` del nodo. Non conosce il DNS del cluster
`None`	Nada: lo definís vos entero en `dnsConfig`
`None`	Nothing: you define it all yourself in `dnsConfig`
`None`	Nulla: lo definisci tu per intero in `dnsConfig`
`ClusterFirstWithHostNet`	CoreDNS aun con `hostNetwork: true`
`ClusterFirstWithHostNet`	CoreDNS even with `hostNetwork: true`
`ClusterFirstWithHostNet`	CoreDNS anche con `hostNetwork: true`

Modo	Estado
Mode	Status
Modalità	Stato
iptables	Default histórico, el más común
iptables	Historic default, the most common
iptables	Default storico, il più comune
nftables	GA desde 1.33, mejor a gran escala
nftables	GA since 1.33, better at scale
nftables	GA dalla 1.33, meglio su larga scala
ipvs	Más algoritmos de balanceo
ipvs	More balancing algorithms
ipvs	Più algoritmi di bilanciamento

El Service y el modelo de red

The Service and the network model

Il Service e il modello di rete

El problema, en vivo

The problem, live

Il problema, dal vivo

El Service, imperativo

The Service, imperatively

Il Service, imperativo

La verificación que importa: ¿tiene endpoints?

The verification that matters: does it have endpoints?

La verifica che conta: ha endpoint?

El YAML, para leerlo bien

The YAML, read properly

Lo YAML, letto bene

El modelo de red de Kubernetes

Kubernetes' network model

Il modello di rete di Kubernetes

Entonces, ¿para qué el Service?

So what is the Service for?

Allora a cosa serve il Service?

Los tres puertos (fuente eterna de confusión)

The three ports (an eternal source of confusion)

Le tre porte (fonte eterna di confusione)

Solo pods Ready entran

Only Ready pods get in

Entrano solo i pod Ready

Los tipos de Service

The Service types

I tipi di Service

ClusterIP (el default) — solo interno

ClusterIP (the default) — internal only

ClusterIP (il default) — solo interno

NodePort — puerto en TODOS los nodos

NodePort — a port on EVERY node

NodePort — una porta su TUTTI i nodi

LoadBalancer — IP externa del proveedor

LoadBalancer — the provider's external IP

LoadBalancer — l'IP esterno del provider

ExternalName — un CNAME, sin proxy

ExternalName — a CNAME, no proxying

ExternalName — un CNAME, senza proxy

Headless — sin IP virtual, DNS directo a pods

Headless — no virtual IP, DNS straight to pods

Headless — nessun IP virtuale, DNS diretto ai pod

Los tipos, en una tabla

The types, in one table

I tipi, in una tabella

Se anidan (esto ordena todo)

They nest (this sorts everything out)

Si annidano (questo mette ordine)

Headless: para qué existe

Headless: why it exists

Headless: perché esiste

externalTrafficPolicy

Crear services rápido

Creating services fast

Creare service in fretta

Camino 1: expose (recurso existente)

Path 1: expose (existing resource)

Strada 1: expose (risorsa esistente)

Camino 2: create service (desde cero)

Path 2: create service (from scratch)

Strada 2: create service (da zero)

El atajo que te ahorra un Service

The shortcut that saves you a Service

La scorciatoia che ti risparmia un Service

Editar puertos después

Editing ports afterwards

Modificare le porte dopo

La regla

The rule

La regola

Multi-puerto: los nombres son obligatorios

Multi-port: names are mandatory

Multi-porta: i nomi sono obbligatori

targetPort puede ser un nombre

targetPort can be a name

targetPort può essere un nome

CoreDNS: hablarle por nombre