CKA · Módulo 0 K8s v1.34

Setup + el arte del imperativo

El módulo de calentamiento. Aliases, dry-run como generador de YAML, y la diferencia imperativo/declarativo que te ahorra el 20% del tiempo en el examen. Sin esto, todo lo demás es lento.

Duración60 min
Peso examenBase (transversal)
Tipo100% hands-on
PrioridadCrítica para velocidad
El CKA no se gana sabiendo más Kubernetes que el resto. Se gana ejecutando más rápido. Tenés ~17 tareas en 120 minutos: eso es ~7 min por tarea, y varias requieren múltiples pasos. La diferencia entre aprobar y no llegar a tiempo casi nunca es el conocimiento — es la velocidad de generar manifiestos. Este módulo te da las tres herramientas que hacen esa diferencia: aliases, el patrón --dry-run, y saber cuándo usar imperativo vs declarativo.
01
Setup · 20 min

Cluster local multi-node

VMs con kubeadm — el entorno de máxima fidelidad con el examen
Práctica · Hands-on

El entorno: VMs con kubeadm (no kind)

El CKA corre sobre un cluster armado con kubeadm sobre máquinas Linux reales. El mejor entorno de práctica es el que más se parece al examen: 3 VMs Ubuntu con kubeadm.

El setup completo paso a paso está en su propia guía (CKA_Setup_VMs_kubeadm.html), con la estrategia de snapshots para repetir escenarios destructivos. Topología:

  • cp1 — control plane (2 vCPU, 2-4 GB)
  • w1, w2 — workers (2 vCPU, 2 GB cada uno)

Por qué NO kind ni minikube

kind corre cada nodo como contenedor Docker, sin systemd real. No podés practicar kubeadm, etcd backup/restore, ni systemctl restart kubelet — que juntos son más del 40% del examen.

minikube es mejor que kind pero tampoco te da kubeadm-from-scratch ni el control total del control plane que el examen evalúa.

Corrección respecto a versiones previas de este material: kind NO es la opción recomendada para CKA. Sirve para desarrollo de apps sobre K8s, pero el CKA evalúa administración (kubeadm, etcd, nodos) que kind no reproduce. Usá VMs.
Teoría · Por qué VMs + snapshots

Por qué 3 nodos reales

El examen evalúa tareas que solo tienen sentido con nodos reales y múltiples:

  • kubeadm: init, join, upgrade necesitan máquinas con systemd
  • etcd: backup/restore necesita acceso al filesystem del control plane
  • Scheduling: taints, affinity solo con varios nodos
  • Node troubleshooting: kubelet, static pods, systemctl reales

El superpoder: snapshots

Como muchos ejercicios son destructivos (romper el cluster a propósito para troubleshooting), los snapshots te dan repetición infinita: rompés, arreglás, restaurás, repetís.

Mantené 3 snapshots base: base-prep (sistema listo sin cluster), cluster-ready (3 nodos funcionales), y pre-upgrade (una versión atrás, para practicar upgrades). Detalle en la guía de setup.
02
Velocidad · 10 min

Aliases obligatorios

Lo primero que tipeás el día del examen. Practicá con ellos desde HOY.
Práctica · Copiá esto

El setup de los primeros 60 segundos del examen

Apenas empieza el examen, antes de leer la primera pregunta, tipeás esto:

# El alias k ya viene seteado en el examen, pero por si acaso:
alias k=kubectl

# Generador de YAML — el más importante
export do="--dry-run=client -o yaml"

# Borrado instantáneo (sin esperar grace period)
export now="--force --grace-period=0"

# Autocompletado (suele venir activo, verificalo)
source <(kubectl completion bash)
complete -F __start_kubectl k

Cómo se usan en la práctica

# Generar YAML de un pod sin crearlo (con el alias $do)
k run nginx --image=nginx $do > pod.yaml

# Borrar un pod al instante (con $now)
k delete pod nginx $now
No te vuelvas loco con aliases. Los que sobran te hacen perder tiempo recordándolos. k, $do y $now son suficientes. Más que eso es contraproducente bajo presión.
Teoría · El porqué

El cálculo de tiempo

Tipear kubectl completo vs k: son 7 caracteres menos por comando. En un examen donde tipeás ~100+ comandos, eso es tiempo real.

Pero el ahorro grande es $do. Escribir --dry-run=client -o yaml son 27 caracteres que vas a tipear decenas de veces. Con el alias son 3.

La regla de oro de aliases

AliasPara qué
kkubectl (siempre)
$dogenerar YAML sin aplicar
$nowborrar sin esperar
Si practicás con k desde el día 1, para el examen ya es automático. Si lo dejás para el final, vas a tipear kubectl por costumbre y perdés el beneficio.
03
Concepto core · 15 min

Imperativo vs Declarativo

El criterio que decide tu velocidad: cuándo tipear un comando, cuándo escribir YAML
Práctica · Los dos modos

Imperativo — decís QUÉ hacer

Un comando que ejecuta una acción directa. Rápido, ideal para objetos simples.

# Crear un pod directo
k run nginx --image=nginx

# Crear un deployment
k create deployment web --image=nginx --replicas=3

# Exponer como service
k expose deployment web --port=80 --type=ClusterIP

# Crear configmap desde literales
k create configmap app-cfg --from-literal=KEY=value

# Escalar
k scale deployment web --replicas=5

Declarativo — describís el ESTADO deseado

Un archivo YAML que define cómo querés que sea el objeto. Necesario para configuraciones complejas.

# Aplicar un manifiesto
k apply -f deployment.yaml

# Aplicar todos los YAML de un directorio
k apply -f ./manifests/
La estrategia ganadora: generá el esqueleto con imperativo + $do, después editás el YAML solo para lo que el comando no soporta. Nunca escribas YAML desde cero.
Teoría · Cuándo cada uno

Decisión rápida

SituaciónModo
Objeto simple (pod, deploy)Imperativo
Necesita campos no soportados por flagsGenera + edita
Multi-container, volumes, probesDeclarativo
Borrar / escalar / exponer rápidoImperativo

Lo que el imperativo NO puede

Algunas cosas requieren YAML sí o sí porque no hay flag:

  • Multi-container pods
  • Volumes y volumeMounts
  • initContainers
  • Probes (readiness/liveness)
  • securityContext detallado
  • affinity / topology constraints

Para estos: generás el esqueleto con $do y agregás a mano solo el bloque que falta.

04
La técnica clave · 15 min

--dry-run como generador de YAML

El patrón que usás 30+ veces en el examen. Internalizalo hasta que sea reflejo.
Práctica · El patrón maestro

El flujo completo: generar → editar → aplicar

Esta es LA técnica del CKA. En vez de escribir YAML desde cero (lento, propenso a errores de indentación), generás el esqueleto y editás.

# 1. Generar el esqueleto YAML (NO crea nada todavía)
k run nginx --image=nginx $do > pod.yaml

# 2. Editar el YAML para agregar lo que falta
vim pod.yaml
#    (agregás resources, volumes, probes, etc.)

# 3. Crear desde el YAML editado
k apply -f pod.yaml

Recetas imperativas que generan YAML

# Pod
k run nginx --image=nginx $do

# Deployment con replicas
k create deploy web --image=nginx --replicas=3 $do

# Service (requiere que exista el deploy o usar --dry-run sobre expose)
k expose deploy web --port=80 $do

# Job
k create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(20)' $do

# CronJob
k create cronjob backup --image=busybox --schedule="*/5 * * * *" $do

# ConfigMap y Secret
k create cm app --from-literal=K=V $do
k create secret generic db --from-literal=pass=1234 $do

Pod con comando custom

# Pod que ejecuta un comando y termina
k run test --image=busybox $do -- /bin/sh -c "sleep 3600" > pod.yaml
Teoría · Por qué funciona

Las 3 piezas del flag

FlagQué hace
--dry-run=clientsimula, no envía al API server
-o yamloutput en formato YAML
> archivoguarda en archivo en vez de stdout

dry-run=client vs dry-run=server

client: solo valida localmente y muestra el YAML. NO toca el cluster. Es el que usás para generar.

server: envía al API server que valida pero no persiste. Útil para testear que algo es válido sin crearlo.

Para generar YAML siempre usás =client. El =server es para validación avanzada, rara vez en el examen.

El error de indentación que NO querés

Escribir YAML a mano en vim bajo presión = errores de indentación que te hacen perder minutos. Generar el esqueleto correcto y solo editar elimina el 90% de esos errores.

Config de vim para YAML (ponelo en ~/.vimrc al practicar): set et ts=2 sw=2 — expande tabs a 2 espacios, esencial para que el YAML no se rompa.
05
Cierre del módulo

Lo que te llevás del Módulo 0

Resumen · Comandos clave

Tu kit de arranque del examen

# Los 3 aliases (primeros 30 segundos)
alias k=kubectl
export do="--dry-run=client -o yaml"
export now="--force --grace-period=0"

# vim para YAML
# ~/.vimrc: set et ts=2 sw=2

# El patrón maestro
k <crear-algo> $do > obj.yaml   # generar
vim obj.yaml                       # editar
k apply -f obj.yaml               # aplicar

Practicá esto ahora (15 min)

  1. Levantá tu cluster kind multi-node
  2. Seteá los 3 aliases
  3. Generá un pod, un deployment y un service usando $do
  4. Editá uno de los YAML y aplicalo
  5. Borrá todo con $now
Teoría · Mentalidad CKA

La diferencia con DP-700

En DP-700 ganabas eligiendo la respuesta correcta. En CKA ganás ejecutando correcto Y rápido. El conocimiento es necesario pero no suficiente — la velocidad es lo que separa.

Los 3 principios de velocidad

  • Nunca escribas YAML desde cero. Generá con $do.
  • Imperativo para lo simple, declarativo solo cuando hace falta.
  • kubernetes.io/docs es tu amigo. Tenés 1 tab permitida — aprendé a navegarla rápido (lo vemos en Fase 2).
Mismo método que DP-700: este cheat sheet lo anotás a mano en tu agenda (los 3 aliases + el patrón maestro). Escribirlo lo fija.
Checkpoint Módulo 0: cluster armado, aliases automáticos, patrón dry-run internalizado. Listos para el Módulo 1: Cluster Architecture con kubeadm.
Módulo 0 completado · La base de velocidad está puesta · Siguiente: kubeadm y el control plane