CKA · Módulo 5 · Scheduling

nodeSelector	node Affinity
Simple: label = valor	Expresiones (In, NotIn, Exists…)
Simple: label = value	Expressions (In, NotIn, Exists…)
Semplice: label = valore	Espressioni (In, NotIn, Exists…)
Solo AND exacto	OR, rangos, negación
Exact AND only	OR, ranges, negation
Solo AND esatto	OR, intervalli, negazione
Solo "requerido"	requerido O preferido
"Required" only	required OR preferred
Solo "richiesto"	richiesto O preferito

Efecto	Qué hace
NoSchedule	No entran pods nuevos sin toleration
NoSchedule	No new pods without a toleration
NoSchedule	Niente pod nuovi senza toleration
PreferNoSchedule	Evita, pero no prohíbe
PreferNoSchedule	Avoids, but does not forbid
PreferNoSchedule	Evita, ma non vieta
NoExecute	Además EXPULSA los pods ya corriendo
NoExecute	Also EVICTS pods already running
NoExecute	Inoltre ESPELLE i pod già in esecuzione

Request	Limit
Lo que reserva	El techo máximo
What it reserves	The hard ceiling
Quello che riserva	Il tetto massimo
Lo usa el scheduler para ver dónde cabe	Lo hace cumplir el kubelet en runtime
Used by the scheduler to see where it fits	Enforced by the kubelet at runtime
Usato dallo scheduler per vedere dove entra	Fatto rispettare dal kubelet a runtime
No puede superar el allocatable del nodo	Puede sobrecomprometerse (>100%)
Cannot exceed the node's allocatable	May be overcommitted (>100%)
Non può superare l'allocatable del nodo	Può essere sovracommesso (>100%)

Clase	Cuándo	Al desalojar
Guaranteed	requests == limits (todo)	último
Guaranteed	requests == limits (all)	last
Guaranteed	requests == limits (tutto)	ultimo
Burstable	tiene requests, pero ≠ limits	segundo
Burstable	has requests, but ≠ limits	second
Burstable	ha requests, ma ≠ limits	secondo
BestEffort	sin requests ni limits	primero
BestEffort	no requests, no limits	first
BestEffort	né requests né limits	per primo

★

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

E1–E5 construyen; T1–T4 diagnostican. ~5 min cada uno.

E1–E5 build; T1–T4 diagnose. ~5 min each.

E1–E5 costruiscono; T1–T4 diagnosticano. ~5 min ciascuno.

0 / 9

⚙

Setup. Cluster de 2 nodos (cp con taint control-plane:NoSchedule, w1 worker limpio). Namespace de trabajo: k create ns m5, y -n m5 en todo. Ojo: labels y taints de nodo NO son namespaced — sobreviven al delete ns, hay que limpiarlos aparte (última tarjeta).

Setup. Two-node cluster (cp tainted control-plane:NoSchedule, w1 a clean worker). Working namespace: k create ns m5, and -n m5 on everything. Careful: node labels and taints are NOT namespaced — they survive delete ns and must be cleaned separately (last card).

Setup. Cluster a 2 nodi (cp con taint control-plane:NoSchedule, w1 worker pulito). Namespace di lavoro: k create ns m5, e -n m5 su tutto. Attenzione: label e taint dei nodi NON sono namespaced — sopravvivono al delete ns e vanno puliti a parte (ultima scheda).

◆

Manifests publicados. Cada ejercicio tiene su YAML servido por este mismo sitio, así que no hace falta copiar nada a mano: k apply -f <url>/manifests/m5e1.yaml. Los E son la solución de referencia (mirá el YAML cuando quieras ver cómo se escribe); los T plantan el problema — aplicalos y diagnosticá sin leerlos. Todos crean el namespace m5, y k delete -f <misma-url> los limpia. Cada tarjeta trae el comando exacto, con botón de copiar.

Published manifests. Every exercise has its YAML served by this very site, so nothing needs copying by hand: k apply -f <url>/manifests/m5e1.yaml. The E ones are the reference solution (open the YAML whenever you want to see how it is written); the T ones plant the problem — apply them and diagnose without reading them. All of them create namespace m5, and k delete -f <same-url> cleans up. Each card carries the exact command, with a copy button.

Manifest pubblicati. Ogni esercizio ha il suo YAML servito da questo stesso sito, così non serve copiare nulla a mano: k apply -f <url>/manifests/m5e1.yaml. Gli E sono la soluzione di riferimento (apri lo YAML quando vuoi vedere come si scrive); i T piantano il problema — applicali e diagnostica senza leggerli. Tutti creano il namespace m5, e k delete -f <stessa-url> pulisce. Ogni scheda porta il comando esatto, con pulsante copia.

🧠

Modelo mental. El scheduler decide; vos lo influenciás con 4 palancas: atraer (nodeSelector/nodeAffinity), repeler (taint + toleration), reservar (requests/limits) y distribuir (pod anti-affinity / topology spread). Filtros en orden: taints → afinidad/selector → recursos. Resolvé antes de abrir la solución.

Mental model. The scheduler decides; you steer it with 4 levers: attract (nodeSelector/nodeAffinity), repel (taint + toleration), reserve (requests/limits) and spread (pod anti-affinity / topology spread). Filters in order: taints → affinity/selector → resources. Solve it before opening the solution.

Modello mentale. Lo scheduler decide; tu lo guidi con 4 leve: attrarre (nodeSelector/nodeAffinity), respingere (taint + toleration), riservare (requests/limits) e distribuire (pod anti-affinity / topology spread). Filtri in ordine: taint → affinity/selector → risorse. Risolvi prima di aprire la soluzione.

nodeSelector — forzar un pod a un nodo

nodeSelector — pin a pod to a node

nodeSelector — forzare un pod su un nodo

~5 min hecho

Etiquetá el nodo w1 con disktype=ssd.
Creá un Pod web-ssd (nginx) que solo pueda correr en nodos con esa label.
Verificá que cayó en w1.

Label node w1 with disktype=ssd.
Create a Pod web-ssd (nginx) that can run only on nodes with that label.
Verify it landed on w1.

Etichetta il nodo w1 con disktype=ssd.
Crea un Pod web-ssd (nginx) che possa girare solo su nodi con quella label.
Verifica che sia finito su w1.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

k label node w1 disktype=ssd
k get nodes -l disktype=ssd

# generar el esqueleto y agregarle el nodeSelector# generate the skeleton, then add the nodeSelector# genera lo scheletro, poi aggiungi il nodeSelector
k run web-ssd --image=nginx -n m5 --dry-run=client -o yaml > web-ssd.yaml
#   bajo spec:  nodeSelector: { disktype: ssd }#   under spec:  nodeSelector: { disktype: ssd }#   sotto spec:  nodeSelector: { disktype: ssd }
k apply -f web-ssd.yaml

k get pod web-ssd -n m5 -o wide      # NODE = w1# NODE = w1# NODE = w1

Claves

Key points

Punti chiave

nodeSelector es un AND exacto: el nodo debe tener todas las labels con el valor exacto. Si ninguno matchea → Pending (ese es el T1).
Va en spec.nodeSelector; en un Deployment, spec.template.spec.nodeSelector.

nodeSelector is an exact AND: the node must carry every label with the exact value. If none matches → Pending (that's T1).
It lives at spec.nodeSelector; in a Deployment, spec.template.spec.nodeSelector.

nodeSelector è un AND esatto: il nodo deve avere tutte le label con il valore esatto. Se nessuno corrisponde → Pending (è il T1).
Sta in spec.nodeSelector; in un Deployment, spec.template.spec.nodeSelector.

Node Affinity — required + preferred

~5 min hecho

Creá un Pod web-aff (nginx) que obligatoriamente corra en un nodo cuyo disktype esté en {ssd, nvme}, y preferentemente (peso 50) en uno con zone=a. Verificá dónde cayó y por qué.

Create a Pod web-aff (nginx) that must run on a node whose disktype is in {ssd, nvme}, and preferably (weight 50) on one with zone=a. Verify where it landed and why.

Crea un Pod web-aff (nginx) che debba girare su un nodo il cui disktype sia in {ssd, nvme}, e preferibilmente (peso 50) su uno con zone=a. Verifica dove è finito e perché.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

apiVersion: v1
kind: Pod
metadata:
  name: web-aff
  namespace: m5
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:      # DURA# HARD# DURA
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values: ["ssd", "nvme"]
      preferredDuringSchedulingIgnoredDuringExecution:     # BLANDA# SOFT# MORBIDA
      - weight: 50
        preference:
          matchExpressions:
          - key: zone
            operator: In
            values: ["a"]
  containers:
  - name: nginx
    image: nginx

Claves

Key points

Punti chiave

Nadie tiene zone=a: el preferred no matchea y el pod se schedulea igual. Eso es exactamente lo que "blanda" significa.
In te da el OR de valores que nodeSelector no puede expresar.
Fijate en la anidación: required lleva nodeSelectorTerms; preferred es una lista de {weight, preference}. No son simétricos.

Nobody has zone=a: the preferred rule fails to match and the pod schedules anyway. That is exactly what "soft" means.
In gives you the OR-of-values that nodeSelector cannot express.
Watch the nesting: required takes nodeSelectorTerms; preferred is a list of {weight, preference}. They are not symmetric.

Nessuno ha zone=a: la regola preferred non corrisponde e il pod viene schedulato lo stesso. È esattamente ciò che significa "morbida".
In ti dà l'OR di valori che nodeSelector non sa esprimere.
Occhio all'annidamento: required prende nodeSelectorTerms; preferred è una lista di {weight, preference}. Non sono simmetrici.

Taints, tolerations y el efecto NoExecute

Taints, tolerations and the NoExecute effect

Taint, toleration e l'effetto NoExecute

~7 min hecho

Poné el taint gpu=true:NoSchedule en w1.
Creá un Pod no-tol (nginx) sin toleration. ¿Dónde queda y por qué?
Creá si-tol (nginx) que tolere ese taint y verificá que sí entra.
Bonus: cambiá el taint a NoExecute y observá qué pasa. Después conseguí que si-tol sobreviva a los dos efectos.

Taint w1 with gpu=true:NoSchedule.
Create a Pod no-tol (nginx) with no toleration. Where does it end up, and why?
Create si-tol (nginx) tolerating that taint and verify it gets in.
Bonus: switch the taint to NoExecute and watch what happens. Then make si-tol survive both effects.

Metti il taint gpu=true:NoSchedule su w1.
Crea un Pod no-tol (nginx) senza toleration. Dove finisce e perché?
Crea si-tol (nginx) che tolleri quel taint e verifica che entri.
Bonus: cambia il taint in NoExecute e osserva cosa succede. Poi fai in modo che si-tol sopravviva a entrambi gli effetti.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

k taint node w1 gpu=true:NoSchedule

# 2 · sin toleration: Pending (w1 por gpu, cp por control-plane)# 2 · no toleration: Pending (w1 by gpu, cp by control-plane)# 2 · senza toleration: Pending (w1 per gpu, cp per control-plane)
k run no-tol --image=nginx -n m5
k describe pod no-tol -n m5 | grep -A6 Events

# 3+4 · toleration que cubre AMBOS efectos de la misma key# 3+4 · a toleration covering BOTH effects of the same key# 3+4 · una toleration che copre ENTRAMBI gli effetti della stessa key
spec:
  tolerations:
  - key: gpu
    operator: Equal
    value: "true"
    effect: NoSchedule
  - key: gpu
    operator: Equal
    value: "true"
    effect: NoExecute      # sin esta línea, el NoExecute lo expulsa# without this one, NoExecute evicts it# senza questa, il NoExecute lo espelle

k taint node w1 gpu=true:NoSchedule-
k taint node w1 gpu=true:NoExecute
k get pods -n m5 -o wide

Claves

Key points

Punti chiave

Un toleration matchea un efecto puntual. Omitir effect cubre todos los de esa key; operator: Exists sin key tolera cualquier taint.
NoExecute vacía el nodo: los Pods pelados sin toleration se borran y no vuelven; los que tiene un Deployment se recrean (y quedan Pending). Lección: controller vs pod suelto.
Quitar un taint = mismo comando con - al final, y el efecto tiene que coincidir.

A toleration matches one specific effect. Omitting effect covers all of them for that key; operator: Exists with no key tolerates any taint.
NoExecute drains the node: bare Pods without a toleration are deleted and never come back; Deployment-owned ones are recreated (and go Pending). Lesson: controller vs bare pod.
Removing a taint = same command with a trailing -, and the effect must match.

Una toleration corrisponde a un effetto preciso. Omettere effect li copre tutti per quella key; operator: Exists senza key tollera qualsiasi taint.
NoExecute svuota il nodo: i Pod nudi senza toleration vengono cancellati e non tornano; quelli di un Deployment vengono ricreati (e restano Pending). Lezione: controller contro pod nudo.
Togliere un taint = stesso comando con - finale, e l'effetto deve coincidere.

Requests, limits y "Allocated resources"

Requests, limits and "Allocated resources"

Requests, limits e "Allocated resources"

~5 min hecho

Creá un Deployment resweb (nginx, 2 réplicas) con requests cpu=100m/mem=64Mi y limits cpu=250m/mem=128Mi.
Verificá los recursos en el pod.
Leé cuánto hay reservado y libre en w1, y decí qué QoS class le tocó al pod.

Create a Deployment resweb (nginx, 2 replicas) with requests cpu=100m/mem=64Mi and limits cpu=250m/mem=128Mi.
Verify the resources on the pod.
Read how much is reserved and free on w1, and say which QoS class the pod got.

Crea un Deployment resweb (nginx, 2 repliche) con requests cpu=100m/mem=64Mi e limits cpu=250m/mem=128Mi.
Verifica le risorse nel pod.
Leggi quanto è riservato e libero su w1, e dì quale QoS class ha ottenuto il pod.

Ver soluciónShow solutionMostra soluzione

manifest · soluciónmanifest · solutionmanifest · soluzione

k create deploy resweb --image=nginx --replicas=2 -n m5
k set resources deploy resweb -n m5 \
  --requests=cpu=100m,memory=64Mi --limits=cpu=250m,memory=128Mi

k get pod -n m5 -l app=resweb -o jsonpath='{.items[0].spec.containers[0].resources}'; echo
k get pod -n m5 -l app=resweb -o jsonpath='{.items[0].status.qosClass}'; echo
# → Burstable (tiene requests, pero requests ≠ limits)# → Burstable (has requests, but requests ≠ limits)# → Burstable (ha requests, ma requests ≠ limits)

k describe node w1 | grep -A8 "Allocated resources"

Claves

Key points

Punti chiave

La tabla Allocated resources suma los requests de todos los pods del nodo con su %. Es lo que el scheduler compara, no k top.
La suma de requests no puede pasar el allocatable; la de limits sí (overcommit >100% es normal).
QoS: Guaranteed si requests==limits en todos los containers, Burstable si hay requests, BestEffort si no hay nada.

The Allocated resources table sums the requests of every pod on the node with percentages. That is what the scheduler compares against, not k top.
The sum of requests cannot exceed allocatable; the sum of limits can (overcommit >100% is normal).
QoS: Guaranteed if requests==limits on every container, Burstable if there are requests, BestEffort if there is nothing.

La tabella Allocated resources somma le requests di tutti i pod del nodo con le percentuali. È ciò che lo scheduler confronta, non k top.
La somma delle requests non può superare l'allocatable; quella dei limits sì (overcommit >100% è normale).
QoS: Guaranteed se requests==limits su ogni container, Burstable se ci sono requests, BestEffort se non c'è nulla.

Repartir réplicas: anti-affinity y topology spread

Spreading replicas: anti-affinity and topology spread

Distribuire le repliche: anti-affinity e topology spread

~7 min hecho

Querés que 2 réplicas de una app no caigan juntas. Con solo 2 nodos y el control plane tainteado, primero hay que liberarlo.

Hacé schedulable cp (quitale el taint control-plane).
Creá el Deployment ha-web (nginx, 2 réplicas) con podAntiAffinity por kubernetes.io/hostname.
Verificá una réplica por nodo.
Rehacelo con topologySpreadConstraints y compará.

You want 2 replicas of an app not to land together. With only 2 nodes and the control plane tainted, you must free it first.

Make cp schedulable (remove its control-plane taint).
Create Deployment ha-web (nginx, 2 replicas) with podAntiAffinity on kubernetes.io/hostname.
Verify one replica per node.
Redo it with topologySpreadConstraints and compare.

Vuoi che 2 repliche di un'app non finiscano insieme. Con soli 2 nodi e il control plane taintato, prima devi liberarlo.

Rendi cp schedulabile (togli il taint control-plane).
Crea il Deployment ha-web (nginx, 2 repliche) con podAntiAffinity su kubernetes.io/hostname.
Verifica una replica per nodo.
Rifallo con topologySpreadConstraints e confronta.

Ver soluciónShow solutionMostra soluzione

k taint node cp node-role.kubernetes.io/control-plane:NoSchedule-

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ha-web
  namespace: m5
spec:
  replicas: 2
  selector:
    matchLabels: { app: ha-web }
  template:
    metadata:
      labels: { app: ha-web }
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels: { app: ha-web }
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: nginx

# variante moderna, en spec.template.spec:# modern variant, under spec.template.spec:# variante moderna, sotto spec.template.spec:
#   topologySpreadConstraints:
#   - maxSkew: 1
#     topologyKey: kubernetes.io/hostname
#     whenUnsatisfiable: DoNotSchedule
#     labelSelector: { matchLabels: { app: ha-web } }

k get pods -n m5 -l app=ha-web -o wide

Claves

Key points

Punti chiave

El labelSelector del anti-affinity apunta a las labels del template, no del Deployment.
Con required, una réplica de más queda Pending: la regla gana sobre la disponibilidad. maxSkew + ScheduleAnyway es la versión tolerante.
Acordate de volver a poner el taint del control plane al terminar.

The anti-affinity labelSelector targets the template labels, not the Deployment's.
With required, one replica too many stays Pending: the rule beats availability. maxSkew + ScheduleAnyway is the forgiving version.
Remember to put the control-plane taint back when you are done.

Il labelSelector dell'anti-affinity punta alle label del template, non a quelle del Deployment.
Con required, una replica di troppo resta Pending: la regola batte la disponibilità. maxSkew + ScheduleAnyway è la versione tollerante.
Ricordati di rimettere il taint del control plane alla fine.

Troubleshooting — Pending por constraint imposible

Troubleshooting — Pending on an impossible constraint

Troubleshooting — Pending per un vincolo impossibile

~5 min hecho

Hay un Pod stuck-1 en m5 que quedó Pending y no arranca nunca. Diagnosticá por qué no se puede schedular y hacelo correr con el mínimo cambio.

There is a Pod stuck-1 in m5 stuck in Pending that never starts. Diagnose why it cannot be scheduled and get it running with the smallest change.

C'è un Pod stuck-1 in m5 bloccato in Pending che non parte mai. Diagnostica perché non può essere schedulato e fallo partire con la modifica minima.

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

Ver soluciónShow solutionMostra soluzione

Equivalente imperativo: k run stuck-1 --image=nginx -n m5 --overrides='{"spec":{"nodeSelector":{"disktype":"nvme"}}}'

Imperative equivalent: k run stuck-1 --image=nginx -n m5 --overrides='{"spec":{"nodeSelector":{"disktype":"nvme"}}}'

Equivalente imperativo: k run stuck-1 --image=nginx -n m5 --overrides='{"spec":{"nodeSelector":{"disktype":"nvme"}}}'

k get pod stuck-1 -n m5 -o wide          # Pending, NODE <none># Pending, NODE <none># Pending, NODE <none>
k describe pod stuck-1 -n m5 | grep -A6 Events
#   0/2 nodes are available: ... didn't match Pod's node affinity/selector#   0/2 nodes are available: ... didn't match Pod's node affinity/selector#   0/2 nodes are available: ... didn't match Pod's node affinity/selector

k get pod stuck-1 -n m5 -o jsonpath='{.spec.nodeSelector}'; echo
#   {"disktype":"nvme"}  → ningún nodo tiene esa label#   {"disktype":"nvme"}  → no node carries that label#   {"disktype":"nvme"}  → nessun nodo ha quella label

# Arreglo A: satisfacer el selector etiquetando un nodo# Fix A: satisfy the selector by labelling a node# Fix A: soddisfare il selector etichettando un nodo
k label node w1 disktype=nvme --overwrite
# Arreglo B: corregir el selector — pero en un Pod es inmutable: borrar y recrear# Fix B: correct the selector — but it is immutable on a Pod: delete and recreate# Fix B: correggere il selector — ma su un Pod è immutabile: cancella e ricrea

Claves

Key points

Punti chiave

Pending = el scheduler no encontró nodo. El porqué SIEMPRE está en Events: 0/N nodes are available: … desglosa la causa por nodo.
Red herring: el bloque Tolerations: con not-ready/unreachable aparece en todos los pods — lo inyecta el admission controller DefaultTolerationSeconds. No es tu problema. Mirá Events.
Un Pod suelto no se re-schedulea editándole el selector (campos inmutables); un Deployment sí, con un rollout.

Pending = the scheduler found no node. The why is ALWAYS in Events: 0/N nodes are available: … breaks the cause down per node.
Red herring: the Tolerations: block with not-ready/unreachable shows up on every pod — injected by the DefaultTolerationSeconds admission controller. Not your problem. Read Events.
A bare Pod is not rescheduled by editing its selector (immutable fields); a Deployment is, via a rollout.

Pending = lo scheduler non ha trovato un nodo. Il perché è SEMPRE in Events: 0/N nodes are available: … scompone la causa per nodo.
Falsa pista: il blocco Tolerations: con not-ready/unreachable compare su tutti i pod — lo inietta l'admission controller DefaultTolerationSeconds. Non è il tuo problema. Leggi Events.
Un Pod nudo non viene rischedulato modificandone il selector (campi immutabili); un Deployment sì, con un rollout.

Troubleshooting — Pending por recursos

Troubleshooting — Pending on resources

Troubleshooting — Pending per risorse

~5 min hecho

Un Deployment stuck-2 también está Pending, pero el cluster está casi vacío de carga real. Averiguá por qué no entra y hacelo correr.

A Deployment stuck-2 is also Pending, yet the cluster carries almost no real load. Work out why it does not fit and get it running.

Anche un Deployment stuck-2 è Pending, ma il cluster non ha quasi carico reale. Scopri perché non entra e fallo partire.

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

Ver soluciónShow solutionMostra soluzione

Equivalente imperativo: k create deploy stuck-2 --image=nginx -n m5 && k set resources deploy stuck-2 -n m5 --requests=cpu=6

Imperative equivalent: k create deploy stuck-2 --image=nginx -n m5 && k set resources deploy stuck-2 -n m5 --requests=cpu=6

Equivalente imperativo: k create deploy stuck-2 --image=nginx -n m5 && k set resources deploy stuck-2 -n m5 --requests=cpu=6

k describe pod -n m5 -l app=stuck-2 | grep -A6 Events
#   0/2 nodes are available: 2 Insufficient cpu#   0/2 nodes are available: 2 Insufficient cpu#   0/2 nodes are available: 2 Insufficient cpu

k get pod -n m5 -l app=stuck-2 -o jsonpath='{.items[0].spec.containers[0].resources.requests}'; echo
#   {"cpu":"6"}  → pide 6 cores; ningún nodo tiene tanto LIBRE#   {"cpu":"6"}  → asks for 6 cores; no node has that much FREE#   {"cpu":"6"}  → chiede 6 core; nessun nodo ne ha così tanti LIBERI

k describe node w1 | grep -A8 "Allocated resources"
k set resources deploy stuck-2 -n m5 --requests=cpu=100m,memory=64Mi --limits=cpu=200m,memory=128Mi
k get pods -n m5 -o wide

Claves

Key points

Punti chiave

Insufficient cpu/memory = ningún nodo tiene suficiente request libre (allocatable − ya reservado). Se mira lo reservado, no el uso real.
Mismo síntoma que T1 (Pending), distinta causa. El reflejo es siempre describe pod → Events, que discrimina entre selector/taint y recursos.
Herramienta distinta para confirmar: T1 → get nodes --show-labels; T2 → describe node (Allocated resources) y k top nodes para el uso real.

Insufficient cpu/memory = no node has enough free request (allocatable − already reserved). It looks at reservations, not actual usage.
Same symptom as T1 (Pending), different cause. The reflex is always describe pod → Events, which discriminates between selector/taint and resources.
Different tool to confirm: T1 → get nodes --show-labels; T2 → describe node (Allocated resources) plus k top nodes for real usage.

Insufficient cpu/memory = nessun nodo ha abbastanza request libera (allocatable − già riservato). Guarda le prenotazioni, non l'uso reale.
Stesso sintomo del T1 (Pending), causa diversa. Il riflesso è sempre describe pod → Events, che distingue fra selector/taint e risorse.
Strumento diverso per confermare: T1 → get nodes --show-labels; T2 → describe node (Allocated resources) più k top nodes per l'uso reale.

Troubleshooting — el DaemonSet al que le falta un nodo

Troubleshooting — the DaemonSet missing a node

Troubleshooting — il DaemonSet a cui manca un nodo

~5 min hecho

Un DaemonSet node-agent debería correr un pod por nodo. Aplicalo, contá los pods y explicá por qué falta uno. Después hacé que corra en todos, sin tocar los nodos.

Ojo con el síntoma: acá no hay ningún pod Pending. Los que existen están perfectos.

A DaemonSet node-agent should run one pod per node. Apply it, count the pods and explain why one is missing. Then make it run everywhere, without touching the nodes.

Mind the symptom: there is no Pending pod at all here. The ones that exist are perfectly fine.

Un DaemonSet node-agent dovrebbe eseguire un pod per nodo. Applicalo, conta i pod e spiega perché ne manca uno. Poi fallo girare ovunque, senza toccare i nodi.

Attenzione al sintomo: qui non c'è nessun pod Pending. Quelli che esistono stanno benissimo.

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

Ver soluciónShow solutionMostra soluzione

k get ds -n m5
# DESIRED 1, CURRENT 1, READY 1 ... pero hay 2 nodos# DESIRED 1, CURRENT 1, READY 1 ... but there are 2 nodes# DESIRED 1, CURRENT 1, READY 1 ... ma i nodi sono 2

k get nodes
k get pods -n m5 -o wide         # solo en w1; en cp no hay nada# only on w1; nothing on cp# solo su w1; su cp niente

# el nodo que falta está tainteado, y el DS no lo tolera# the missing node is tainted, and the DS does not tolerate it# il nodo mancante è taintato, e il DS non lo tollera
k describe node cp | grep -A2 Taints
# node-role.kubernetes.io/control-plane:NoSchedule

# arreglo: agregarle la toleration al template del DS# fix: add the toleration to the DS template# fix: aggiungere la toleration al template del DS
k edit ds node-agent -n m5
spec:
  template:
    spec:
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule

k get ds -n m5                   # DESIRED 2# DESIRED 2# DESIRED 2

Claves

Key points

Punti chiave

El síntoma no es Pending, es un número. El controller del DaemonSet excluye del DESIRED a los nodos que el pod no podría tolerar: no crea un pod para que quede Pending, directamente no lo cuenta. Por eso get pods se ve sano y el problema solo aparece en get ds.
Es el mismo taint del control plane que en E3, del otro lado del mostrador: en E3 lo ponés vos, acá ya estaba.
operator: Exists sin value tolera cualquier valor de esa key. Es exactamente lo que usan kube-proxy y los CNI para llegar a todos los nodos: mirá k get ds -n kube-system kube-proxy -o yaml.
Regla general: si un DaemonSet tiene que estar en el control plane, necesita la toleration sí o sí. Es la causa nº 1 de "instalé el agente y no está en el master".

The symptom is not Pending, it is a number. The DaemonSet controller excludes from DESIRED the nodes the pod could not tolerate: it does not create a pod and leave it Pending, it simply does not count the node. That is why get pods looks healthy and the problem only shows in get ds.
It is the same control-plane taint as in E3, from the other side of the counter: in E3 you set it, here it was already there.
operator: Exists with no value tolerates any value of that key. It is exactly what kube-proxy and the CNIs use to reach every node: look at k get ds -n kube-system kube-proxy -o yaml.
General rule: if a DaemonSet has to be on the control plane, it needs the toleration, no exceptions. It is the number-one cause of "I installed the agent and it is not on the master".

Il sintomo non è Pending, è un numero. Il controller del DaemonSet esclude dal DESIRED i nodi che il pod non potrebbe tollerare: non crea un pod lasciandolo Pending, semplicemente non conta il nodo. Per questo get pods sembra sano e il problema compare solo in get ds.
È lo stesso taint del control plane di E3, dall'altro lato del bancone: in E3 lo metti tu, qui c'era già.
operator: Exists senza value tollera qualsiasi valore di quella key. È esattamente ciò che usano kube-proxy e i CNI per raggiungere tutti i nodi: guarda k get ds -n kube-system kube-proxy -o yaml.
Regola generale: se un DaemonSet deve stare sul control plane, la toleration serve per forza. È la causa numero uno di "ho installato l'agent e sul master non c'è".

Troubleshooting — las réplicas que no entran

Troubleshooting — the replicas that will not fit

Troubleshooting — le repliche che non entrano

~6 min hecho

El Deployment spread-web pide 4 réplicas y levanta menos; el resto queda Pending. Hay CPU de sobra y ningún nodo tiene labels raras. Diagnosticá qué filtro las rechaza y decidí cómo arreglarlo: ¿aflojás la regla o agregás nodos?

Deployment spread-web asks for 4 replicas and brings up fewer; the rest stay Pending. There is CPU to spare and no node carries odd labels. Diagnose which filter rejects them and decide how to fix it: loosen the rule or add nodes?

Il Deployment spread-web chiede 4 repliche e ne alza meno; il resto resta Pending. C'è CPU in abbondanza e nessun nodo ha label strane. Diagnostica quale filtro le respinge e decidi come sistemarlo: allentare la regola o aggiungere nodi?

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

Ver soluciónShow solutionMostra soluzione

k get pods -n m5 -o wide -l app=spread-web
k describe pod -n m5 -l app=spread-web | grep -A6 Events
# 0/2 nodes are available: 1 node(s) didn't match pod anti-affinity rules,
# 1 node(s) had untolerated taint(s). ... preemption: 0/2 nodes are available:
# 2 Preemption is not helpful for scheduling.

# la cuenta: anti-affinity por hostname = máximo 1 réplica por nodo# the arithmetic: anti-affinity by hostname = at most 1 replica per node# il conto: anti-affinity per hostname = al massimo 1 replica per nodo
k get nodes                      # contá los SCHEDULABLES (sin taint) → ese es el techo# count the SCHEDULABLE ones (untainted) → that is the ceiling# conta i SCHEDULABILI (senza taint) → quello è il tetto

# Arreglo A — aflojar: preferred en vez de required# Fix A — loosen it: preferred instead of required# Fix A — allentare: preferred invece di required
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels: { app: spread-web }
        topologyKey: kubernetes.io/hostname

# Arreglo B — con topologySpread, que sí sabe repartir de a varias# Fix B — with topologySpread, which does know how to pack several# Fix B — con topologySpread, che sa distribuirne più d'una
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels: { app: spread-web }

# Arreglo C — dar más nodos: destaintear cp# Fix C — give it more nodes: untaint cp# Fix C — dargli più nodi: togliere il taint a cp
k taint node cp node-role.kubernetes.io/control-plane:NoSchedule-
#   … el techo sube en 1, no llega a 4 salvo que haya 4 nodos#   … the ceiling goes up by 1; it reaches 4 only with 4 nodes#   … il tetto sale di 1; arriva a 4 solo con 4 nodi

Claves

Key points

Punti chiave

Anti-affinity required por hostname pone un techo duro: una réplica por nodo. Pedir más réplicas que nodos schedulables deja el resto Pending para siempre, y ninguna cantidad de CPU lo arregla.
El Events lista las causas por nodo y acá hay dos distintas en la misma línea: un nodo rechaza por la regla, el otro por el taint. Leer las dos partes es lo que te da el techo real.
La diferencia de fondo con topologySpread: la anti-affinity es binaria (hay o no hay un pod igual), el spread cuenta y admite un desbalance de maxSkew. Por eso el spread reparte 4 réplicas en 2 nodos y la anti-affinity no.
Antes de tocar el YAML, hacé la cuenta: réplicas ≤ nodos schedulables. Si no cierra, no es un bug, es aritmética.
El no-arreglo: borrar el bloque affinity. El Pending desaparece y parece resuelto — pero las réplicas se apilan todas en un nodo, que es justo lo que la regla evitaba. Perdiste el requisito, no lo cumpliste. Si el enunciado pide alta disponibilidad, esto puntúa cero: aflojá la regla (A) o repartí de verdad (B), no la elimines.

required anti-affinity by hostname sets a hard ceiling: one replica per node. Asking for more replicas than schedulable nodes leaves the rest Pending forever, and no amount of CPU fixes it.
Events lists the causes per node and here there are two different ones on the same line: one node refuses on the rule, the other on the taint. Reading both parts is what gives you the real ceiling.
The underlying difference from topologySpread: anti-affinity is binary (there either is or is not a matching pod), spread counts and tolerates an imbalance of maxSkew. That is why spread fits 4 replicas on 2 nodes and anti-affinity does not.
Before touching the YAML, do the arithmetic: replicas ≤ schedulable nodes. If it does not add up, it is not a bug, it is counting.
The non-fix: deleting the affinity block. The Pending goes away and it looks solved — but the replicas all pile onto one node, which is exactly what the rule prevented. You lost the requirement, you did not meet it. If the task asks for high availability, this scores zero: loosen the rule (A) or genuinely spread (B), do not delete it.

L'anti-affinity required per hostname impone un tetto rigido: una replica per nodo. Chiedere più repliche dei nodi schedulabili lascia il resto Pending per sempre, e nessuna quantità di CPU lo risolve.
Events elenca le cause per nodo e qui ce ne sono due diverse sulla stessa riga: un nodo rifiuta per la regola, l'altro per il taint. Leggere entrambe le parti è ciò che ti dà il tetto reale.
La differenza di fondo con topologySpread: l'anti-affinity è binaria (c'è o non c'è un pod uguale), lo spread conta e ammette uno sbilanciamento di maxSkew. Per questo lo spread distribuisce 4 repliche su 2 nodi e l'anti-affinity no.
Prima di toccare lo YAML, fai il conto: repliche ≤ nodi schedulabili. Se non torna, non è un bug, è aritmetica.
Il non-fix: cancellare il blocco affinity. Il Pending sparisce e sembra risolto — ma le repliche si accatastano tutte su un nodo, che è proprio ciò che la regola evitava. Hai perso il requisito, non l'hai soddisfatto. Se la consegna chiede alta disponibilità, questo vale zero: allenta la regola (A) o distribuisci davvero (B), non eliminarla.

Limpieza — labels y taints no son namespaced

Cleanup — labels and taints are not namespaced

Pulizia — label e taint non sono namespaced

~1 min

Borrar el namespace no revierte lo que tocaste en los nodos. Dejalos como estaban:

Deleting the namespace does not undo what you changed on the nodes. Put them back:

Cancellare il namespace non annulla quello che hai toccato sui nodi. Rimettili a posto:

k label node w1 disktype- zone- 2>/dev/null
k taint node w1 gpu=true:NoSchedule- 2>/dev/null
k taint node w1 gpu=true:NoExecute-  2>/dev/null
k taint node cp node-role.kubernetes.io/control-plane:NoSchedule   # restaurar# restore# ripristina
k delete ns m5

Autoevaluación — antes de marcar M5 como ★ dominado

Self-check — before marking M5 as ★ mastered

Autovalutazione — prima di segnare M5 come ★ padroneggiato

Forzar un pod a un nodo con nodeSelector, sin mirar.
Escribir un nodeAffinity required + preferred con operator: In.
Taintear, tolerar, y explicar NoSchedule vs NoExecute (y qué le pasa a un pod pelado).
Setear requests/limits y leer Allocated resources; decir la QoS class de un pod.
Repartir réplicas con podAntiAffinity o topologySpread por hostname.
Ante un Pending, ir a Events y distinguir constraint vs recursos.

Pin a pod to a node with nodeSelector, from memory.
Write a nodeAffinity required + preferred with operator: In.
Taint, tolerate, and explain NoSchedule vs NoExecute (and what happens to a bare pod).
Set requests/limits and read Allocated resources; state a pod's QoS class.
Spread replicas with podAntiAffinity or topologySpread by hostname.
Given a Pending pod, go to Events and tell constraint from resources.

Forzare un pod su un nodo con nodeSelector, a memoria.
Scrivere un nodeAffinity required + preferred con operator: In.
Taintare, tollerare e spiegare NoSchedule vs NoExecute (e cosa succede a un pod nudo).
Impostare requests/limits e leggere Allocated resources; dire la QoS class di un pod.
Distribuire le repliche con podAntiAffinity o topologySpread per hostname.
Davanti a un Pending, andare su Events e distinguere vincolo da risorse.

Efecto	Qué hace
Effect	What it does
Effetto	Cosa fa
NoSchedule	No entran pods nuevos sin toleration
NoSchedule	No new pods without a toleration
NoSchedule	Niente pod nuovi senza toleration
PreferNoSchedule	Evita, pero no prohíbe
PreferNoSchedule	Avoids, but does not forbid
PreferNoSchedule	Evita, ma non vieta
NoExecute	Además EXPULSA los pods ya corriendo
NoExecute	Also EVICTS pods already running
NoExecute	Inoltre ESPELLE i pod già in esecuzione

Clase	Cuándo	Al desalojar
Class	When	On eviction
Classe	Quando	All'eviction
Guaranteed	requests == limits (todo)	último
Guaranteed	requests == limits (all)	last
Guaranteed	requests == limits (tutto)	ultimo
Burstable	tiene requests, pero ≠ limits	segundo
Burstable	has requests, but ≠ limits	second
Burstable	ha requests, ma ≠ limits	secondo
BestEffort	sin requests ni limits	primero
BestEffort	no requests, no limits	first
BestEffort	né requests né limits	per primo

nodeSelector y Node Affinity

nodeSelector and Node Affinity

nodeSelector e Node Affinity

Primero: etiquetar un nodo

First: label a node

Primo: etichettare un nodo

nodeSelector — la forma simple

nodeSelector — the simple form

nodeSelector — la forma semplice

Node Affinity — la forma flexible

Node Affinity — the flexible form

Node Affinity — la forma flessibile

La diferencia

The difference

La differenza

required vs preferred

required vs preferred

required vs preferred

Taints y Tolerations

Taints and Tolerations

Taints e Tolerations

Poner un taint a un nodo

Taint a node

Mettere un taint su un nodo

Toleration en el pod

Toleration on the pod

Toleration nel pod

Los efectos de un taint

A taint's effects

Gli effetti di un taint

Affinity vs Taints — la diferencia clave

Affinity vs Taints — the key difference

Affinity vs Taints — la differenza chiave

Requests, Limits y QoS

Requests, Limits and QoS

Requests, Limits e QoS

requests y limits en un pod

requests and limits on a pod

requests e limits in un pod

Atajo imperativo y lectura del nodo

Imperative shortcut and reading the node

Scorciatoia imperativa e lettura del nodo

La distinción crucial

The crucial distinction

La distinzione cruciale

Al superar el limit

Going over the limit

Superare il limit

Las 3 clases de QoS

The 3 QoS classes

Le 3 classi di QoS

Pod Affinity y Topology Spread

Pod Affinity and Topology Spread

Pod Affinity e Topology Spread

Pod Anti-Affinity — separar réplicas

Pod Anti-Affinity — split replicas

Pod Anti-Affinity — separare le repliche

Topology Spread — distribución pareja

Topology Spread — even distribution

Topology Spread — distribuzione uniforme

Pod affinity vs node affinity

Pod affinity vs node affinity

Pod affinity vs node affinity

El topologyKey

The topologyKey

Il topologyKey

Casos de uso típicos

Typical use cases

Casi d'uso tipici

Lo que te llevás del Módulo 5

What you take from Module 5

Cosa porti via dal Modulo 5

Para tu chuleta

For your cheat sheet

Per il tuo bigliettino

Las 4 ideas que no se negocian

The 4 non-negotiable ideas

Le 4 idee non negoziabili

Práctica — 9 ejercicios

Practice — 9 exercises