CKA · Módulo 1 K8s v1.34 25% del examen

Cluster Architecture: kubeadm, etcd y el control plane

El módulo más denso de la Fase 1. Cómo está construido un cluster, cómo se arma y se une un nodo, cómo se actualiza sin romperlo, y cómo proteger su corazón: etcd. Buena parte de esto ya lo viviste armando tu cluster.

Duración75 min

Peso examen25% (Cluster Arch)

Conecta conTroubleshooting 30%

Snapshot clavepre-upgrade

Este módulo es el núcleo administrativo del CKA. Lo bueno: ya hiciste el 40% sin saberlo cuando armaste el cluster y debuggeaste etcd, el API server y el kubelet. Ahora le ponemos nombre formal a cada pieza y agregamos las dos operaciones que más caen en el examen: upgrade de cluster y etcd backup/restore. Ambas son destructivas para practicar — ahí entran tus snapshots.

1.1

Componentes del control plane

etcd, apiserver, scheduler, controller-manager + kubelet. Qué hace cada uno y dónde vive.

1.2

kubeadm init / join

Bootstrap del cluster, unir workers, tokens y certificados.

1.3

Upgrade del cluster

drain → upgrade → kubelet → uncordon. El orden correcto, control plane y workers.

1.4

etcd backup & restore

snapshot save / restore con etcdctl. El tema estrella del examen.

1.1

Fundamento · 15 min

Componentes del control plane

La base de todo. Sin esto, el resto del módulo flota en el aire.

Práctica · Verlos en tu cluster

Los static pods del control plane

En un cluster kubeadm, los 4 componentes corren como static pods: sus manifiestos viven en una carpeta y el kubelet los levanta solo.

# Los 4 manifiestos del control plane (en cp1)
ls /etc/kubernetes/manifests/
# etcd.yaml  kube-apiserver.yaml
# kube-controller-manager.yaml  kube-scheduler.yaml

# Verlos corriendo como pods
k get pods -n kube-system

# Inspeccionar el manifiesto del apiserver
sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml

El kubelet (no es static pod)

Corre en TODOS los nodos como servicio de systemd, no como pod.

sudo systemctl status kubelet
sudo journalctl -u kubelet -n 50 --no-pager

★

De examen: el kubelet vigila /etc/kubernetes/manifests/. Si editás o movés un manifiesto de ahí, el kubelet reacciona al instante (recrea o elimina el pod). Es la base de varios ejercicios de troubleshooting.

Teoría · Quién es quién

El modelo "estado deseado"

Vos declarás QUÉ querés; el cluster trabaja sin parar para que la realidad coincida. Los componentes hacen ese trabajo.

Componente	Función
etcd	Base de datos. Guarda TODO el estado del cluster
kube-apiserver	Única puerta de entrada. Todo pasa por él. El único que habla con etcd
kube-scheduler	Decide en qué nodo va cada pod nuevo
controller-manager	Vigila que realidad = deseado. Recrea pods caídos, etc.
kubelet	Agente en cada nodo. Recibe órdenes y arranca containers
kube-proxy	Ruteo de red de Services (Módulo 6)

★

etcd ES el cluster. Si lo perdés, perdés todo el estado aunque las VMs estén intactas. Por eso 1.4 (backup) es tan crítico.

Lo que ya viviste

El bind: cannot assign requested address era etcd. El API server que no levantaba dependía de etcd. El kubelet reiniciándose en loop. Ya conocés a los actores.

1.2

Bootstrap · 20 min

kubeadm init / join

Armar el cluster y unir nodos. Ya lo hiciste — acá lo formalizamos.

Práctica · Comandos

Inicializar el control plane

sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --apiserver-advertise-address=<IP-del-cp>

# Configurar kubectl para tu usuario
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# Instalar CNI (sin esto los nodos quedan NotReady)
k apply -f <calico.yaml>

Unir un worker

# El comando que imprime 'kubeadm init' al final:
sudo kubeadm join <IP>:6443 --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

Si perdiste el token (dura 24h)

# Regenerar el comando de join completo (en el cp)
kubeadm token create --print-join-command

# Listar tokens existentes
kubeadm token list

⚠

Tus 4 errores de armado fueron: IP inexistente (etcd no bindea), containerd caído, CRI deshabilitado, y kubeconfig faltante. Los 4 son clásicos de examen. Tenelos en la agenda.

Teoría · Qué hace init por dentro

Las fases de kubeadm init

Cuando corrés init, pasa por fases en orden (las viste en el output):

preflight: chequeos previos (swap, cgroups, runtime)
certs: genera todos los certificados en /etc/kubernetes/pki/
kubeconfig: genera admin.conf, kubelet.conf, etc.
control-plane: crea los static pod manifests
etcd: crea el static pod de etcd
kubelet-start: arranca el kubelet
bootstrap-token: crea el token para que se unan workers

Qué hace join

El worker contacta al API server, valida con el token + el hash del CA (para confiar en el control plane), recibe sus certificados, y arranca su kubelet. Por eso join necesita esos dos valores.

★

El discovery-token-ca-cert-hash es el mecanismo de confianza mutua: el worker verifica que el control plane es legítimo, no un impostor.

1.3

Operación crítica · 20 min

Upgrade del cluster

El orden importa. Equivocarse rompe el cluster. Practicalo en loop con snapshots.

◆

Antes de practicar: sacá el snapshot pre-upgrade con el cluster una versión atrás. Cada vez que termines (o rompas) un upgrade, restaurás y lo repetís. El upgrade se gana con repetición pura hasta que el orden sea automático.

Orden en el CONTROL PLANE (cp1)

Upgradear el binario de kubeadm

sudo apt-mark unhold kubeadm
sudo apt-get update && sudo apt-get install -y kubeadm=1.34.x-*
sudo apt-mark hold kubeadm

Ver el plan de upgrade

sudo kubeadm upgrade plan
# Te muestra a qué versiones podés ir

Aplicar el upgrade del control plane

sudo kubeadm upgrade apply v1.34.x

Drenar el nodo (mover pods fuera)

k drain cp1 --ignore-daemonsets

Upgradear kubelet y kubectl

sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.34.x-* kubectl=1.34.x-*
sudo apt-mark hold kubelet kubectl

Reiniciar el kubelet

sudo systemctl daemon-reload
sudo systemctl restart kubelet

Devolver el nodo al servicio

k uncordon cp1

Orden en cada WORKER (w1, w2)

Casi igual, pero con kubeadm upgrade node en vez de apply, y el drain/uncordon se corren desde el control plane.

Upgradear kubeadm (en el worker)

sudo apt-mark unhold kubeadm
sudo apt-get update && sudo apt-get install -y kubeadm=1.34.x-*
sudo apt-mark hold kubeadm

Drenar el worker (DESDE el control plane)

# En cp1:
k drain w1 --ignore-daemonsets

Upgrade del node config (en el worker)

sudo kubeadm upgrade node

Upgradear kubelet + reiniciar (en el worker)

sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.34.x-* kubectl=1.34.x-*
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload && sudo systemctl restart kubelet

Uncordon (DESDE el control plane)

# En cp1:
k uncordon w1

★

Regla de oro del upgrade: control plane PRIMERO, workers DESPUÉS. Y dentro de cada nodo: kubeadm → drain → kubelet → uncordon. El drain protege las cargas moviéndolas antes de tocar el nodo; el uncordon lo reincorpora al final.

⚠

El --ignore-daemonsets en el drain es obligatorio: los DaemonSets (como kube-proxy y calico-node) corren en todos los nodos y no se pueden mover, así que drain falla sin ese flag. Si hay pods con almacenamiento local, puede que necesites --delete-emptydir-data también.

1.4

El tema estrella · 20 min

etcd backup & restore

Cae casi siempre en el examen. Protegés el corazón del cluster.

Práctica · etcdctl

Las credenciales que SIEMPRE necesitás

etcdctl habla con etcd por TLS. Estos 4 valores van en casi todos los comandos:

# Endpoint + los 3 certificados
--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

BACKUP — snapshot save

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

# Verificar el snapshot
sudo ETCDCTL_API=3 etcdctl snapshot status /opt/backup.db -w table

RESTORE — snapshot restore

# 1. Restaurar a un data-dir NUEVO
sudo ETCDCTL_API=3 etcdctl snapshot restore /opt/backup.db \
  --data-dir=/var/lib/etcd-restore

# 2. Apuntar etcd al nuevo data-dir
sudo vim /etc/kubernetes/manifests/etcd.yaml
#    cambiar hostPath de /var/lib/etcd
#    a /var/lib/etcd-restore (en volumes Y volumeMounts)

# 3. El kubelet recrea etcd solo al detectar el cambio
#    Esperá a que el control plane vuelva
k get pods -n kube-system

Teoría · Por qué y cómo

Qué es un backup de etcd

Un snapshot de etcd es una foto completa del estado del cluster en ese instante: todos los objetos, todo. Restaurarlo es viajar en el tiempo a ese momento.

El flujo mental del restore

Paso	Qué hace
restore	Desempaqueta el .db en un data-dir nuevo
editar manifest	Decirle a etcd que use ese data-dir
kubelet recrea	Al cambiar el static pod, etcd reinicia con los datos restaurados

★

El ETCDCTL_API=3 es obligatorio en versiones donde no es el default. Ponelo siempre por las dudas — no molesta y evita errores raros.

★

Truco de examen: los paths de los certificados los podés sacar del propio manifiesto de etcd: sudo cat /etc/kubernetes/manifests/etcd.yaml | grep file. Si no te acordás las rutas, ahí están.

◆

Practicá destructivo: restaurá a cluster-ready, hacé un backup, borrá un deployment a propósito, restaurá el backup, y verificá que el deployment volvió. Si rompés etcd, restaurás el snapshot de la VM y reintentás.

★

Cierre del módulo

Lo que te llevás del Módulo 1

Resumen · Comandos clave

Para tu agenda

# Ver componentes del control plane
ls /etc/kubernetes/manifests/
k get pods -n kube-system

# Token de join nuevo
kubeadm token create --print-join-command

# Upgrade (orden): kubeadm → plan → apply →
#   drain → kubelet → uncordon

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

# etcd restore
sudo ETCDCTL_API=3 etcdctl snapshot restore /opt/backup.db \
  --data-dir=/var/lib/etcd-restore
# + editar /etc/kubernetes/manifests/etcd.yaml

Teoría · Lo esencial

Las 4 ideas que no se negocian

etcd ES el cluster. Todo el estado vive ahí.
El control plane son static pods en /etc/kubernetes/manifests/.
Upgrade: control plane primero, workers después. drain antes, uncordon después.
Backup de etcd: 4 credenciales + save. Restore: data-dir nuevo + editar manifest.

★

Como en DP-700: anotá a mano en tu agenda los comandos de etcd y el orden del upgrade. Son los dos que más se preguntan y los que más se olvidan bajo presión.

Checkpoint Módulo 1: componentes claros, kubeadm dominado, upgrade practicado en loop, etcd backup/restore automático. Siguiente: Módulo 2 — RBAC y seguridad (tu punto a reforzar).

Módulo 1 completado · El núcleo administrativo del cluster · Siguiente: RBAC, ServiceAccounts y kubeconfig