CKA · Módulo 1 · Cluster Architecture

Componente	Función
etcd	Base de datos. Guarda TODO el estado del cluster
etcd	Database. Holds ALL cluster state
etcd	Database. Contiene TUTTO lo stato del cluster
kube-apiserver	Única puerta de entrada. Todo pasa por él; el único que habla con etcd
kube-apiserver	The single front door. Everything goes through it; the only one that talks to etcd
kube-apiserver	L'unica porta d'ingresso. Tutto passa da lui; l'unico che parla con etcd
kube-scheduler	Decide en qué nodo va cada pod nuevo
kube-scheduler	Decides which node each new pod lands on
kube-scheduler	Decide su quale nodo va ogni pod nuovo
controller-manager	Vigila que realidad = deseado. Recrea pods caídos, etc.
controller-manager	Keeps reality = desired. Recreates dead pods, etc.
controller-manager	Tiene realtà = desiderato. Ricrea i pod caduti, ecc.
kubelet	Agente en cada nodo. Recibe órdenes y arranca containers
kubelet	Agent on every node. Takes orders and starts containers
kubelet	Agente su ogni nodo. Riceve ordini e avvia i container
kube-proxy	Ruteo de red de los Services (Módulo 6)
kube-proxy	Service network routing (Module 6)
kube-proxy	Routing di rete dei Service (Modulo 6)

Paso	Qué hace
restore	Desempaqueta el .db en un data-dir nuevo
restore	Unpacks the .db into a new data-dir
restore	Estrae il .db in un data-dir nuovo
editar manifest	Decirle a etcd que use ese data-dir
edit manifest	Tell etcd to use that data-dir
modificare manifest	Dire a etcd di usare quel data-dir
kubelet recrea	Al cambiar el static pod, etcd reinicia con los datos restaurados
kubelet recreates	The static pod changed, so etcd restarts on the restored data
il kubelet ricrea	Cambiato lo static pod, etcd riparte sui dati ripristinati

Componente	Modo	Por qué
kube-apiserver	Activo-activo	No guarda estado (todo está en etcd): cualquiera atiende, el LB reparte
kube-apiserver	Active-active	It keeps no state (everything is in etcd): any of them serves, the LB spreads load
kube-apiserver	Attivo-attivo	Non tiene stato (è tutto in etcd): uno qualsiasi risponde, il LB distribuisce
scheduler, controller-manager	Activo-pasivo	Si dos decidieran a la vez habría conflictos: eligen un líder con un objeto `Lease`
scheduler, controller-manager	Active-passive	Two deciding at once would conflict: they elect a leader through a `Lease` object
scheduler, controller-manager	Attivo-passivo	Se due decidessero insieme ci sarebbero conflitti: eleggono un leader con un oggetto `Lease`
etcd	Consenso (raft)	Cada escritura necesita la confirmación de la mayoría de los miembros
etcd	Consensus (raft)	Every write needs confirmation from a majority of the members
etcd	Consenso (raft)	Ogni scrittura richiede la conferma della maggioranza dei membri

Miembros	Quórum	Tolera caídos
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2

	Stacked	External
Dónde corre etcd	En los mismos nodos del control plane (static pod)	En nodos propios
Where etcd runs	On the control plane nodes themselves (static pod)	On dedicated nodes
Dove gira etcd	Sugli stessi nodi del control plane (static pod)	Su nodi propri
Nodos mínimos	3	6 (3 control plane + 3 etcd)
Minimum nodes	3	6 (3 control plane + 3 etcd)
Nodi minimi	3	6 (3 control plane + 3 etcd)
Riesgo	Perder un nodo = perder un apiserver y un miembro de etcd	Las fallas están separadas
Risk	Losing a node = losing an apiserver and an etcd member	Failures are decoupled
Rischio	Perdere un nodo = perdere un apiserver e un membro di etcd	I guasti sono separati
Con kubeadm	Lo que hace por defecto	`etcd.external` en la ClusterConfiguration
With kubeadm	What it does by default	`etcd.external` in the ClusterConfiguration
Con kubeadm	Quello che fa di default	`etcd.external` nella ClusterConfiguration

★

Fase 2 · resolver en vivo

Phase 2 · solve it live

Fase 2 · risolvere dal vivo

Práctica — 8 ejercicios

Practice — 8 exercises

Pratica — 8 esercizi

Reconocimiento, upgrade, etcd y 2 de troubleshooting. Casi todos destructivos.

Recon, upgrade, etcd and 2 troubleshooting drills. Nearly all destructive.

Ricognizione, upgrade, etcd e 2 di troubleshooting. Quasi tutti distruttivi.

0 / 8

◆

Snapshot ANTES de empezar. Este módulo rompe el cluster de verdad: E3/E4 lo actualizan, E6 le cambia el data-dir a etcd y T1/T2 lo dejan sin control plane. Trabajá siempre desde cluster-ready o pre-upgrade, y restaurá entre ejercicios. Sin snapshots esto es una tarde perdida, no una práctica.

Snapshot BEFORE you start. This module genuinely breaks the cluster: E3/E4 upgrade it, E6 changes etcd's data-dir and T1/T2 leave it with no control plane. Always work from cluster-ready or pre-upgrade, and restore between exercises. Without snapshots this is a lost afternoon, not practice.

Snapshot PRIMA di cominciare. Questo modulo rompe il cluster sul serio: E3/E4 lo aggiornano, E6 cambia il data-dir di etcd e T1/T2 lo lasciano senza control plane. Lavora sempre da cluster-ready o pre-upgrade, e ripristina fra un esercizio e l'altro. Senza snapshot questo è un pomeriggio perso, non pratica.

🧠

Modelo mental. Todo el módulo se apoya en dos hechos: el kubelet vigila una carpeta (por eso los static pods se arreglan editando archivos) y etcd guarda todo (por eso el backup es la póliza de seguro). El upgrade es un procedimiento con un orden que no se negocia.

Mental model. The whole module rests on two facts: the kubelet watches a folder (which is why static pods are fixed by editing files) and etcd holds everything (which is why the backup is the insurance policy). The upgrade is a procedure whose order is not negotiable.

Modello mentale. Tutto il modulo poggia su due fatti: il kubelet sorveglia una cartella (per questo gli static pod si aggiustano modificando file) ed etcd contiene tutto (per questo il backup è la polizza assicurativa). L'upgrade è una procedura il cui ordine non si negozia.

Reconocimiento del control plane

Control plane recon

Ricognizione del control plane

~4 min hecho

Sin abrir la documentación, contestá con un comando cada una: ¿qué versión corre cada nodo? ¿Qué static pods hay y dónde están sus manifiestos? ¿En qué puerto escucha etcd y con qué certificados? ¿Está sano el kubelet del worker? ¿Cuándo vencen los certificados del cluster?

Without opening the docs, answer each with one command: which version does each node run? Which static pods exist and where are their manifests? Which port does etcd listen on, and with which certificates? Is the worker's kubelet healthy? When do the cluster certificates expire?

Senza aprire la documentazione, rispondi a ciascuna con un comando: quale versione esegue ogni nodo? Quali static pod esistono e dove sono i loro manifest? Su quale porta ascolta etcd e con quali certificati? Il kubelet del worker è sano? Quando scadono i certificati del cluster?

Ver soluciónShow solutionMostra soluzione

k get nodes -o wide
ls /etc/kubernetes/manifests/
sudo grep -E 'listen-client|file' /etc/kubernetes/manifests/etcd.yaml
sudo systemctl status kubelet          # en el worker# on the worker# sul worker
sudo kubeadm certs check-expiration

Claves

Key points

Punti chiave

El manifiesto de etcd es tu chuleta de rutas: grep file te da los tres certificados sin buscar en la documentación.
kubeadm certs check-expiration aparece poco en el material y sí en el examen: los certs de kubeadm duran un año y se renuevan con kubeadm certs renew all.
El kubelet se diagnostica con systemctl y journalctl, no con kubectl: es un servicio del host, no un pod.

The etcd manifest is your path cheat sheet: grep file gives you the three certificates without opening the docs.
kubeadm certs check-expiration barely appears in study material but does in the exam: kubeadm certs last a year and renew with kubeadm certs renew all.
You diagnose the kubelet with systemctl and journalctl, not kubectl: it is a host service, not a pod.

Il manifest di etcd è il tuo bigliettino dei percorsi: grep file ti dà i tre certificati senza aprire la documentazione.
kubeadm certs check-expiration compare poco nel materiale ma sì all'esame: i cert di kubeadm durano un anno e si rinnovano con kubeadm certs renew all.
Il kubelet si diagnostica con systemctl e journalctl, non con kubectl: è un servizio dell'host, non un pod.

Sumar un worker con el token vencido

Join a worker with an expired token

Aggiungere un worker con il token scaduto

~5 min hecho

Pasaron más de 24 horas desde el init y querés sumar un nodo. El token original ya no sirve. Generá lo necesario y unilo. Después sacá el nodo del cluster de forma limpia.

More than 24 hours have passed since init and you want to add a node. The original token is dead. Generate what you need and join it. Then remove the node from the cluster cleanly.

Sono passate più di 24 ore dall'init e vuoi aggiungere un nodo. Il token originale non vale più. Genera quello che serve e uniscilo. Poi togli il nodo dal cluster in modo pulito.

Ver soluciónShow solutionMostra soluzione

# en el control plane: genera token + hash y arma el comando entero# on the control plane: generates token + hash and builds the whole command# sul control plane: genera token + hash e compone l'intero comando
kubeadm token create --print-join-command

# en el nodo nuevo, pegar la salida:# on the new node, paste the output:# sul nodo nuovo, incolla l'output:
sudo kubeadm join <IP>:6443 --token … --discovery-token-ca-cert-hash sha256:…
k get nodes

# sacarlo limpio: drenar, borrarlo del API, y resetear el nodo# remove it cleanly: drain, delete from the API, reset the node# toglierlo pulito: drenare, cancellarlo dall'API, resettare il nodo
k drain w2 --ignore-daemonsets --delete-emptydir-data
k delete node w2
sudo kubeadm reset -f          # en w2# on w2# su w2

Claves

Key points

Punti chiave

--print-join-command te ahorra calcular el hash del CA a mano. Es el comando que hay que recordar.
Sacar un nodo son tres pasos: drain (mover cargas), delete node (sacarlo del API) y kubeadm reset (limpiar el nodo). Saltear el reset deja basura que rompe un join posterior.
Un token dura 24 h por diseño: es una credencial de bootstrap, no permanente.

--print-join-command saves you computing the CA hash by hand. That is the command to remember.
Removing a node is three steps: drain (move workloads), delete node (remove it from the API) and kubeadm reset (clean the node). Skipping the reset leaves debris that breaks a later join.
A token lasts 24 h by design: it is a bootstrap credential, not a permanent one.

--print-join-command ti risparmia di calcolare l'hash della CA a mano. È il comando da ricordare.
Togliere un nodo sono tre passi: drain (spostare i carichi), delete node (toglierlo dall'API) e kubeadm reset (pulire il nodo). Saltare il reset lascia residui che rompono un join successivo.
Un token dura 24 h per design: è una credenziale di bootstrap, non permanente.

Upgrade del control plane (salto de minor)

Control plane upgrade (minor jump)

Upgrade del control plane (salto di minor)

~12 min hecho

Partiendo del snapshot pre-upgrade (cluster en 1.33.x), llevá el control plane a 1.34.x. El worker queda como está: es el ejercicio siguiente. Verificá al final que k get nodes muestra las dos versiones distintas — y explicá por qué eso está bien.

Starting from the pre-upgrade snapshot (cluster on 1.33.x), take the control plane to 1.34.x. Leave the worker as it is: that is the next exercise. At the end verify that k get nodes shows two different versions — and explain why that is fine.

Partendo dallo snapshot pre-upgrade (cluster su 1.33.x), porta il control plane a 1.34.x. Il worker resta com'è: è l'esercizio successivo. Alla fine verifica che k get nodes mostri due versioni diverse — e spiega perché va bene così.

Ver soluciónShow solutionMostra soluzione

sudo sed -i 's#/v1.33/#/v1.34/#' /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update

sudo apt-mark unhold kubeadm
sudo apt-get install -y kubeadm=1.34.3-1.1
sudo apt-mark hold kubeadm
kubeadm version

sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.34.3

k drain cp1 --ignore-daemonsets
sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.34.3-1.1 kubectl=1.34.3-1.1
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload && sudo systemctl restart kubelet
k uncordon cp1
k get nodes                       # cp1 en 1.34.3, w1 todavía en 1.33.x# cp1 on 1.34.3, w1 still on 1.33.x# cp1 su 1.34.3, w1 ancora su 1.33.x

Claves

Key points

Punti chiave

Sin cambiar el repo, apt no ve la versión nueva y te da un "no candidate" confuso. Es el paso que más se olvida en un salto de minor.
Por qué está bien la asimetría: el skew policy permite que el kubelet esté hasta 3 minors por detrás del apiserver, nunca por delante. Control plane primero siempre.
upgrade apply reescribe los static pods y renueva certificados de paso; el kubelet del nodo se actualiza aparte.

Without changing the repo, apt cannot see the new version and gives you a confusing "no candidate". It is the most forgotten step in a minor jump.
Why the asymmetry is fine: the skew policy lets the kubelet be up to 3 minors behind the apiserver, never ahead. Control plane first, always.
upgrade apply rewrites the static pods and renews certificates on the way; the node's kubelet is upgraded separately.

Senza cambiare il repo, apt non vede la versione nuova e ti dà un "no candidate" confuso. È il passo più dimenticato in un salto di minor.
Perché l'asimmetria va bene: la skew policy consente al kubelet di essere fino a 3 minor dietro l'apiserver, mai avanti. Control plane per primo, sempre.
upgrade apply riscrive gli static pod e rinnova i certificati strada facendo; il kubelet del nodo si aggiorna a parte.

Upgrade del worker

Worker upgrade

Upgrade del worker

~8 min hecho

Terminá el upgrade llevando w1 a 1.34.x. Antes de drenar, dejá corriendo un Deployment con 2 réplicas en el worker y observá qué les pasa durante el drain. Prestá atención a qué comandos se corren en qué máquina.

Finish the upgrade by taking w1 to 1.34.x. Before draining, leave a Deployment with 2 replicas running on the worker and watch what happens to them during the drain. Pay attention to which commands run on which machine.

Completa l'upgrade portando w1 a 1.34.x. Prima di drenare, lascia in esecuzione un Deployment con 2 repliche sul worker e osserva cosa succede loro durante il drain. Fai attenzione a quali comandi girano su quale macchina.

Ver soluciónShow solutionMostra soluzione

# EN EL WORKER: repo + kubeadm# ON THE WORKER: repo + kubeadm# SUL WORKER: repo + kubeadm
sudo sed -i 's#/v1.33/#/v1.34/#' /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-mark unhold kubeadm && sudo apt-get install -y kubeadm=1.34.3-1.1
sudo apt-mark hold kubeadm

# EN EL CONTROL PLANE: drenar# ON THE CONTROL PLANE: drain# SUL CONTROL PLANE: drenare
k drain w1 --ignore-daemonsets --delete-emptydir-data
k get pods -o wide -w            # las réplicas renacen en otro nodo# the replicas come back on another node# le repliche rinascono su un altro nodo

# EN EL WORKER: node + kubelet# ON THE WORKER: node + kubelet# SUL WORKER: node + kubelet
sudo kubeadm upgrade node
sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.34.3-1.1 kubectl=1.34.3-1.1
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload && sudo systemctl restart kubelet

# EN EL CONTROL PLANE: devolverlo al servicio# ON THE CONTROL PLANE: put it back in service# SUL CONTROL PLANE: rimetterlo in servizio
k uncordon w1

Claves

Key points

Punti chiave

En workers es kubeadm upgrade node, no apply. Confundirlos es de los errores más repetidos.
drain y uncordon se corren desde el control plane (son operaciones del API); el resto, en el worker.
Los pods desalojados no vuelven solos tras el uncordon: el scheduler no rebalancea lo que ya corre. El nodo se repuebla con lo nuevo.

On workers it is kubeadm upgrade node, not apply. Confusing them is among the most repeated mistakes.
drain and uncordon run from the control plane (they are API operations); everything else on the worker.
Evicted pods do not come back on their own after the uncordon: the scheduler does not rebalance running workloads. The node refills with new ones.

Sui worker è kubeadm upgrade node, non apply. Confonderli è fra gli errori più ripetuti.
drain e uncordon si eseguono dal control plane (sono operazioni dell'API); il resto sul worker.
I pod espulsi non tornano da soli dopo l'uncordon: lo scheduler non ribilancia ciò che è già in esecuzione. Il nodo si ripopola con i nuovi.

etcd — backup y verificación

etcd — backup and verification

etcd — backup e verifica

~5 min hecho

Sacá un snapshot de etcd en /opt/backup.db y verificá que es válido. No busques las rutas de los certificados en internet: sacalas del cluster. Después anotá cuántas claves tiene el snapshot.

Take an etcd snapshot at /opt/backup.db and verify it is valid. Do not look up the certificate paths online: get them from the cluster. Then note how many keys the snapshot holds.

Fai uno snapshot di etcd in /opt/backup.db e verifica che sia valido. Non cercare i percorsi dei certificati online: prendili dal cluster. Poi annota quante chiavi contiene lo snapshot.

Ver soluciónShow solutionMostra soluzione

sudo grep -E 'cert-file|key-file|trusted-ca' /etc/kubernetes/manifests/etcd.yaml

sudo ETCDCTL_API=3 etcdctl snapshot save /opt/backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

sudo ETCDCTL_API=3 etcdctl snapshot status /opt/backup.db -w table
#   HASH | REVISION | TOTAL KEYS | TOTAL SIZE#   HASH | REVISION | TOTAL KEYS | TOTAL SIZE#   HASH | REVISION | TOTAL KEYS | TOTAL SIZE

Claves

Key points

Punti chiave

El manifiesto de etcd tiene las rutas exactas. Es más rápido y más seguro que recordarlas.
snapshot save necesita etcd vivo (es un cliente TLS). Si el apiserver está caído pero etcd corre, el backup igual sale.
snapshot status es la verificación: si el archivo está corrupto o vacío, te enterás ahora y no durante el restore.

The etcd manifest has the exact paths. Faster and safer than recalling them.
snapshot save needs a live etcd (it is a TLS client). If the apiserver is down but etcd runs, the backup still works.
snapshot status is the verification: a corrupt or empty file shows up now rather than during the restore.

Il manifest di etcd ha i percorsi esatti. Più rapido e più sicuro che ricordarli.
snapshot save richiede un etcd vivo (è un client TLS). Se l'apiserver è giù ma etcd gira, il backup riesce lo stesso.
snapshot status è la verifica: un file corrotto o vuoto si scopre ora e non durante il restore.

etcd — restore de verdad (el que más cae)

etcd — a real restore (the one that comes up most)

etcd — restore vero (quello che cade di più)

~12 min hecho

Creá un namespace antes con un Deployment adentro.
Sacá el backup.
Borrá el namespace entero — a propósito.
Restaurá el snapshot y hacé que el cluster vuelva con el namespace vivo.

Create a namespace antes with a Deployment inside.
Take the backup.
Delete the whole namespace — on purpose.
Restore the snapshot and bring the cluster back with the namespace alive.

Crea un namespace antes con dentro un Deployment.
Fai il backup.
Cancella l'intero namespace — di proposito.
Ripristina lo snapshot e fai tornare il cluster con il namespace vivo.

Ver soluciónShow solutionMostra soluzione

k create ns antes && k create deploy web --image=nginx -n antes
# … backup como en E5 …# … backup as in E5 …# … backup come in E5 …
k delete ns antes

# 1 · restaurar a un data-dir NUEVO (etcd 3.6+ → etcdutl)# 1 · restore into a NEW data-dir (etcd 3.6+ → etcdutl)# 1 · ripristinare in un data-dir NUOVO (etcd 3.6+ → etcdutl)
sudo etcdutl snapshot restore /opt/backup.db --data-dir=/var/lib/etcd-restore

# 2 · editar SOLO el hostPath del volumen etcd-data# 2 · edit ONLY the hostPath of the etcd-data volume# 2 · modificare SOLO l'hostPath del volume etcd-data
sudo vim /etc/kubernetes/manifests/etcd.yaml
#   volumes: - hostPath: path: /var/lib/etcd  →  /var/lib/etcd-restore#   volumes: - hostPath: path: /var/lib/etcd  →  /var/lib/etcd-restore#   volumes: - hostPath: path: /var/lib/etcd  →  /var/lib/etcd-restore

# 3 · el kubelet recrea etcd solo. Dale un minuto.# 3 · the kubelet recreates etcd on its own. Give it a minute.# 3 · il kubelet ricrea etcd da solo. Dagli un minuto.
sudo crictl ps | grep etcd
k get ns antes
k get deploy -n antes

Claves

Key points

Punti chiave

Un solo cambio en el YAML. Si tocás --data-dir o mountPath, etcd busca los datos donde no están y el cluster se cae en CrashLoopBackOff.
Mientras etcd reinicia, kubectl no responde: es esperable, el apiserver depende de etcd. Diagnosticá con crictl ps y journalctl -u kubelet, que no necesitan el API.
El restore te devuelve el estado del momento del backup: lo creado después desaparece. Es viaje en el tiempo, no un merge.
Si el pod de etcd no vuelve, casi siempre son permisos del data-dir nuevo o los tres paths tocados.

One single change in the YAML. Touch --data-dir or mountPath and etcd looks for data where there is none — the cluster falls into CrashLoopBackOff.
While etcd restarts, kubectl stops answering: expected, the apiserver depends on etcd. Diagnose with crictl ps and journalctl -u kubelet, which need no API.
The restore gives you the state at backup time: anything created after it disappears. It is time travel, not a merge.
If the etcd pod does not come back, it is almost always permissions on the new data-dir, or all three paths edited.

Una sola modifica nello YAML. Se tocchi --data-dir o mountPath, etcd cerca i dati dove non ci sono e il cluster cade in CrashLoopBackOff.
Mentre etcd riparte, kubectl non risponde: è previsto, l'apiserver dipende da etcd. Diagnostica con crictl ps e journalctl -u kubelet, che non richiedono l'API.
Il restore ti restituisce lo stato al momento del backup: ciò che è stato creato dopo sparisce. È viaggio nel tempo, non un merge.
Se il pod di etcd non torna, quasi sempre sono i permessi del nuovo data-dir, o tutti e tre i path modificati.

Troubleshooting — el static pod que no vuelve

Troubleshooting — the static pod that never returns

Troubleshooting — lo static pod che non torna

~7 min hecho

kubectl deja de responder: The connection to the server … was refused. Alguien tocó el manifiesto del apiserver. Diagnosticá sin kubectl y devolvé el cluster a la vida.

Para plantarlo vos mismo: agregá un flag inválido al apiserver, por ejemplo - --this-flag-does-not-exist=true, en /etc/kubernetes/manifests/kube-apiserver.yaml.

kubectl stops answering: The connection to the server … was refused. Someone touched the apiserver manifest. Diagnose it without kubectl and bring the cluster back.

To plant it yourself: add an invalid flag to the apiserver, e.g. - --this-flag-does-not-exist=true, in /etc/kubernetes/manifests/kube-apiserver.yaml.

kubectl smette di rispondere: The connection to the server … was refused. Qualcuno ha toccato il manifest dell'apiserver. Diagnostica senza kubectl e riporta in vita il cluster.

Per prepararlo da solo: aggiungi un flag non valido all'apiserver, ad esempio - --this-flag-does-not-exist=true, in /etc/kubernetes/manifests/kube-apiserver.yaml.

Ver soluciónShow solutionMostra soluzione

# sin API server, kubectl no sirve: se baja al nivel del nodo# with no API server, kubectl is useless: drop to node level# senza API server, kubectl è inutile: si scende a livello nodo
sudo crictl ps -a | grep apiserver        # Exited, reiniciando# Exited, restarting# Exited, in riavvio
sudo crictl logs <container-id>           # unknown flag: --this-flag-does-not-exist# unknown flag: --this-flag-does-not-exist# unknown flag: --this-flag-does-not-exist
sudo journalctl -u kubelet -n 50 --no-pager

sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml   # sacar el flag# remove the flag# togliere il flag
# el kubelet lo recrea solo al guardar; esperá ~1 min# the kubelet recreates it on save; wait ~1 min# il kubelet lo ricrea al salvataggio; aspetta ~1 min
k get nodes

Claves

Key points

Punti chiave

Cuando el apiserver está caído, kubectl no existe. Tus herramientas son crictl (containers) y journalctl -u kubelet (el que los levanta).
Un static pod no se arregla con kubectl: se arregla editando el archivo. Borrar el pod con kubectl no sirve — el kubelet lo recrea igual desde el manifiesto.
Truco de reinicio limpio: mover el manifiesto fuera de la carpeta, esperar, y volverlo a poner. El kubelet apaga y prende.

When the apiserver is down, kubectl does not exist. Your tools are crictl (containers) and journalctl -u kubelet (whatever starts them).
A static pod is not fixed with kubectl: you fix it by editing the file. Deleting the pod with kubectl achieves nothing — the kubelet recreates it from the manifest anyway.
Clean-restart trick: move the manifest out of the folder, wait, then put it back. The kubelet stops and starts it.

Quando l'apiserver è giù, kubectl non esiste. I tuoi strumenti sono crictl (container) e journalctl -u kubelet (chi li avvia).
Uno static pod non si aggiusta con kubectl: si aggiusta modificando il file. Cancellare il pod con kubectl non serve — il kubelet lo ricrea comunque dal manifest.
Trucco per un riavvio pulito: sposta il manifest fuori dalla cartella, aspetta, e rimettilo. Il kubelet lo spegne e lo riaccende.

Troubleshooting — nodo NotReady

Troubleshooting — node NotReady

Troubleshooting — nodo NotReady

~6 min hecho

Un worker aparece NotReady y sus pods quedan Terminating o se recrean en otro lado. Diagnosticá la causa y devolvelo a Ready.

Para plantarlo vos mismo: en el worker, sudo systemctl stop kubelet. Variante más interesante: sudo systemctl stop containerd.

A worker shows NotReady and its pods sit Terminating or get recreated elsewhere. Diagnose the cause and get it back to Ready.

To plant it yourself: on the worker, sudo systemctl stop kubelet. A more interesting variant: sudo systemctl stop containerd.

Un worker risulta NotReady e i suoi pod restano Terminating o vengono ricreati altrove. Diagnostica la causa e riportalo a Ready.

Per prepararlo da solo: sul worker, sudo systemctl stop kubelet. Variante più interessante: sudo systemctl stop containerd.

Ver soluciónShow solutionMostra soluzione

k get nodes
k describe node w1 | grep -A10 Conditions
#   Ready  Unknown  "kubelet stopped posting node status"#   Ready  Unknown  "kubelet stopped posting node status"#   Ready  Unknown  "kubelet stopped posting node status"

# en el worker: el kubelet es un servicio, no un pod# on the worker: the kubelet is a service, not a pod# sul worker: il kubelet è un servizio, non un pod
sudo systemctl status kubelet
sudo journalctl -u kubelet -n 50 --no-pager
sudo systemctl status containerd     # si el kubelet corre pero se queja del CRI# if the kubelet runs but complains about the CRI# se il kubelet gira ma si lamenta del CRI

sudo systemctl start kubelet        # (o containerd)# (or containerd)# (o containerd)
sudo systemctl enable --now kubelet
k get nodes -w

Claves

Key points

Punti chiave

NotReady es casi siempre del nodo, no del cluster: kubelet caído, containerd caído, CNI roto, disco lleno. Las Conditions del describe node te dicen cuál.
Si el kubelet corre pero el nodo sigue NotReady, mirá el runtime (containerd) y el CNI. El mensaje típico del CNI: network plugin is not ready.
Tras ~5 minutos NotReady, el taint node.kubernetes.io/unreachable:NoExecute empieza a desalojar los pods. Eso conecta directo con M5.

NotReady is nearly always the node, not the cluster: kubelet down, containerd down, broken CNI, full disk. The Conditions in describe node tell you which.
If the kubelet runs but the node stays NotReady, look at the runtime (containerd) and the CNI. The classic CNI message: network plugin is not ready.
After ~5 minutes NotReady, the node.kubernetes.io/unreachable:NoExecute taint starts evicting pods. That connects straight to M5.

NotReady è quasi sempre il nodo, non il cluster: kubelet giù, containerd giù, CNI rotto, disco pieno. Le Conditions di describe node ti dicono quale.
Se il kubelet gira ma il nodo resta NotReady, guarda il runtime (containerd) e il CNI. Il messaggio tipico del CNI: network plugin is not ready.
Dopo ~5 minuti di NotReady, il taint node.kubernetes.io/unreachable:NoExecute inizia a espellere i pod. Questo si collega direttamente a M5.

Autoevaluación — antes de marcar M1 como ★ dominado

Self-check — before marking M1 as ★ mastered

Autovalutazione — prima di segnare M1 come ★ padroneggiato

Nombrar los 5 componentes, decir cuál es static pod y cuál servicio de systemd.
Regenerar un join command y sacar un nodo del cluster en los 3 pasos.
Upgrade completo del control plane con el cambio de repo, sin mirar apuntes.
Upgrade de un worker sabiendo qué comando va en cada máquina.
Backup de etcd sacando las rutas del manifiesto.
Restore completo tocando solo el hostPath, y saber que en 1.34 es etcdutl.
Diagnosticar un control plane caído con crictl y journalctl, sin kubectl.
Diagnosticar un NotReady leyendo las Conditions del nodo.

Name the 5 components and say which is a static pod and which a systemd service.
Regenerate a join command and remove a node in the 3 steps.
Full control plane upgrade including the repo change, from memory.
Worker upgrade, knowing which command runs on which machine.
etcd backup, pulling the paths out of the manifest.
Complete restore touching only the hostPath, knowing 1.34 uses etcdutl.
Diagnose a downed control plane with crictl and journalctl, without kubectl.
Diagnose a NotReady by reading the node's Conditions.

Nominare i 5 componenti e dire quale è static pod e quale servizio systemd.
Rigenerare un join command e togliere un nodo nei 3 passi.
Upgrade completo del control plane incluso il cambio di repo, a memoria.
Upgrade di un worker sapendo quale comando va su quale macchina.
Backup di etcd ricavando i percorsi dal manifest.
Restore completo toccando solo l'hostPath, sapendo che in 1.34 si usa etcdutl.
Diagnosticare un control plane caduto con crictl e journalctl, senza kubectl.
Diagnosticare un NotReady leggendo le Conditions del nodo.

Miembros	Quórum	Tolera caídos
Members	Quorum	Failures tolerated
Membri	Quorum	Guasti tollerati
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2

Componente	Función
Component	Role
Componente	Ruolo
etcd	Base de datos. Guarda TODO el estado del cluster
etcd	Database. Holds ALL cluster state
etcd	Database. Contiene TUTTO lo stato del cluster
kube-apiserver	Única puerta de entrada. Todo pasa por él; el único que habla con etcd
kube-apiserver	The single front door. Everything goes through it; the only one that talks to etcd
kube-apiserver	L'unica porta d'ingresso. Tutto passa da lui; l'unico che parla con etcd
kube-scheduler	Decide en qué nodo va cada pod nuevo
kube-scheduler	Decides which node each new pod lands on
kube-scheduler	Decide su quale nodo va ogni pod nuovo
controller-manager	Vigila que realidad = deseado. Recrea pods caídos, etc.
controller-manager	Keeps reality = desired. Recreates dead pods, etc.
controller-manager	Tiene realtà = desiderato. Ricrea i pod caduti, ecc.
kubelet	Agente en cada nodo. Recibe órdenes y arranca containers
kubelet	Agent on every node. Takes orders and starts containers
kubelet	Agente su ogni nodo. Riceve ordini e avvia i container
kube-proxy	Ruteo de red de los Services (Módulo 6)
kube-proxy	Service network routing (Module 6)
kube-proxy	Routing di rete dei Service (Modulo 6)

Paso	Qué hace
Step	What it does
Passo	Cosa fa
restore	Desempaqueta el .db en un data-dir nuevo
restore	Unpacks the .db into a new data-dir
restore	Estrae il .db in un data-dir nuovo
editar manifest	Decirle a etcd que use ese data-dir
edit manifest	Tell etcd to use that data-dir
modificare manifest	Dire a etcd di usare quel data-dir
kubelet recrea	Al cambiar el static pod, etcd reinicia con los datos restaurados
kubelet recreates	The static pod changed, so etcd restarts on the restored data
il kubelet ricrea	Cambiato lo static pod, etcd riparte sui dati ripristinati

Componente	Modo	Por qué
Component	Mode	Why
Componente	Modo	Perché
kube-apiserver	Activo-activo	No guarda estado (todo está en etcd): cualquiera atiende, el LB reparte
kube-apiserver	Active-active	It keeps no state (everything is in etcd): any of them serves, the LB spreads load
kube-apiserver	Attivo-attivo	Non tiene stato (è tutto in etcd): uno qualsiasi risponde, il LB distribuisce
scheduler, controller-manager	Activo-pasivo	Si dos decidieran a la vez habría conflictos: eligen un líder con un objeto `Lease`
scheduler, controller-manager	Active-passive	Two deciding at once would conflict: they elect a leader through a `Lease` object
scheduler, controller-manager	Attivo-passivo	Se due decidessero insieme ci sarebbero conflitti: eleggono un leader con un oggetto `Lease`
etcd	Consenso (raft)	Cada escritura necesita la confirmación de la mayoría de los miembros
etcd	Consensus (raft)	Every write needs confirmation from a majority of the members
etcd	Consenso (raft)	Ogni scrittura richiede la conferma della maggioranza dei membri

Componentes del control plane

Control plane components

Componenti del control plane

Los static pods del control plane

The control plane's static pods

Gli static pod del control plane

El kubelet no es un static pod

The kubelet is not a static pod

Il kubelet non è uno static pod

El modelo "estado deseado"

The "desired state" model

Il modello "stato desiderato"

Lo que ya viviste

What you already lived through

Quello che hai già vissuto

kubeadm init / join

Inicializar el control plane

Initialise the control plane

Inizializzare il control plane

Unir un worker

Join a worker

Aggiungere un worker

Las fases de kubeadm init

The phases of kubeadm init

Le fasi di kubeadm init

Qué hace join

What join does

Cosa fa join

Upgrade del cluster

Cluster upgrade

Upgrade del cluster

Orden en el CONTROL PLANE

Order on the CONTROL PLANE

Ordine sul CONTROL PLANE

Actualizar el repo de apt a la línea destino (solo en salto de minor)

Point the apt repo at the target line (minor jumps only)

Puntare il repo apt alla riga di destinazione (solo salti di minor)

Upgradear el binario de kubeadm

Upgrade the kubeadm binary

Aggiornare il binario di kubeadm

Ver el plan

Check the plan

Guardare il piano

Aplicar el upgrade del control plane

Apply the control plane upgrade

Applicare l'upgrade del control plane

Drenar el nodo

Drain the node

Drenare il nodo

Upgradear kubelet y kubectl, y reiniciar

Upgrade kubelet and kubectl, then restart

Aggiornare kubelet e kubectl, poi riavviare

Devolver el nodo al servicio

Put the node back in service

Rimettere il nodo in servizio

Orden en cada WORKER

Order on each WORKER

Ordine su ogni WORKER

Repo + kubeadm (en el worker)

Repo + kubeadm (on the worker)

Repo + kubeadm (sul worker)

Drenar (DESDE el control plane)

Drain (FROM the control plane)

Drenare (DAL control plane)

Upgrade del node config (en el worker)

Upgrade the node config (on the worker)

Upgrade della node config (sul worker)

kubelet + reiniciar (en el worker)

kubelet + restart (on the worker)

kubelet + riavvio (sul worker)

Uncordon (DESDE el control plane)

Uncordon (FROM the control plane)

Uncordon (DAL control plane)

etcd backup & restore

Las credenciales que siempre necesitás

The credentials you always need

Le credenziali che servono sempre

BACKUP — snapshot save (etcdctl)

BACKUP — snapshot save (etcdctl)

BACKUP — snapshot save (etcdctl)