Has llegado al final del recorrido técnico. Durante once módulos has construido, roto, arreglado, asegurado y escalado la plataforma Rutas Norte: desde el primer Pod suelto hasta un clúster de producción con Ingress, TLS, políticas de red, almacenamiento persistente, observabilidad completa y despliegues canario gobernados por GitOps. Ese conocimiento es exactamente el que mide la certificación CKA (Certified Kubernetes Administrator). Lo único que te separa del certificado es el formato: un examen práctico, en un terminal, contrarreloj, con un cronómetro que no perdona la duda.

Esta lección convierte el curso que acabas de hacer en un plan de estudio para el CKA. Vas a ver qué certifica exactamente, cómo es el examen por dentro, qué dominios entran y con qué peso, y —lo más importante— una tabla que mapea cada objetivo oficial del temario con la lección de este curso donde lo estudiaste. A partir de ahí tendrás un plan de seis semanas y una batería de ocho tareas tipo examen resueltas con el comando exacto y su tiempo objetivo.

Aviso imprescindible. Los datos concretos del examen (precio, duración exacta, número de intentos incluidos, porcentaje de aprobado y reparto de los dominios) cambian con el tiempo. Todo lo que leas aquí es orientativo y corresponde al momento de escribir esta lección. Antes de matricularte, consulta siempre el temario oficial vigente en la web de la Linux Foundation / CNCF (training.linuxfoundation.org y cncf.io/certification/cka). El programa de certificación revisa los objetivos con cada versión de Kubernetes.

1. Qué certifica el CKA y a quién va dirigido
2. El formato del examen por dentro
3. Los dominios del temario y su peso orientativo
4. Mapa completo: cada objetivo del CKA y su lección en este curso
5. Habilidades específicas del CKA que conviene practicar aparte
6. Plan de estudio de seis semanas
7. Recursos oficiales y el simulador de prácticas
8. Ocho tareas tipo CKA resueltas contrarreloj

El CKA certifica que sabes administrar y operar un clúster de Kubernetes. No es una certificación sobre teoría de contenedores ni sobre desarrollo de aplicaciones: es la certificación del perfil que mantiene el clúster vivo.

La persona con CKA es la que, en una organización como Rutas Norte, se encarga de:

• CKA: administrar el clúster. Nodos, plano de control, etcd, RBAC, red, almacenamiento y diagnóstico.
• CKAD: desarrollar sobre el clúster; manifiestos de aplicación y velocidad con kubectl (lección 12-02).
• CKS: asegurar el clúster; endurecimiento, políticas y detección (lección 12-03). Exige CKA vigente.

El CKA es el punto de entrada natural si tu trabajo es de plataforma, SRE o infraestructura.

No hay requisitos formales: cualquiera puede matricularse. Los requisitos reales son prácticos: manejo cómodo de la línea de comandos de Linux (systemctl, journalctl, permisos de fichero, vim), comprensión de contenedores, y haber tocado un clúster de verdad —el kilometraje que te ha dado este curso.

Y conviene saber qué no cae. No hay preguntas tipo test: todo es práctico. No entran Helm, Kustomize ni Argo CD en profundidad, ni los proveedores gestionados (EKS/AKS/GKE), ni Prometheus o Grafana como productos —sí kubectl top y el metrics-server—, ni desarrollo de aplicaciones. El examen se centra en Kubernetes puro.

Este es el apartado que más gente subestima. Conocer Kubernetes y aprobar el CKA son cosas distintas, y la diferencia está aquí.

Repito: todos estos números son orientativos. Verifica el temario y las condiciones vigentes en la web oficial antes de pagar la matrícula.

Esta es la trampa número uno del examen y la que más puntos regala a los descuidados.

El examen no te da un clúster: te da varios, cada uno con un nombre de contexto distinto. Cada tarea empieza indicándote en qué contexto debes trabajar, con un comando que puedes copiar y pegar:

Si resuelves la tarea perfectamente en el clúster equivocado, la puntuación es cero. No hay puntuación parcial por buena intención.

Comandos que debes tener automatizados en el dedo:

Hábito obligatorio: el primer comando de cada tarea es el use-context que te dan. Sin excepciones, ni siquiera cuando "es el mismo de antes".

Cada tarea tiene un peso en puntos que se muestra en el enunciado (por ejemplo, "Task weight: 7 %"). La suma de todas da 100.

Lo relevante:

• Existen puntuaciones parciales. Si una tarea pide crear un Deployment con 3 réplicas, exponerlo con un Service y añadirle una sonda, y solo haces las dos primeras cosas, te llevas parte de los puntos. Nunca dejes una tarea en blanco.
• La corrección es automática y por estado final del clúster. Nadie mira cómo lo hiciste. Si el objeto existe con la configuración pedida, puntúa; da igual si lo creaste con kubectl create, con un YAML o editando a mano.
• Eso significa que la vía imperativa es tan válida como la declarativa, y mucho más rápida.

Durante el examen puedes abrir una pestaña adicional del navegador para consultar:

• https://kubernetes.io/docs/ (incluida la referencia de la API y el blog)
• La documentación de los subproyectos oficiales que se enlazan desde ahí (por ejemplo kubernetes.io/docs/reference/kubectl/)

No puedes usar buscadores generales, foros, notas propias, otras webs ni herramientas de IA. Está supervisado.

Esto cambia por completo la estrategia de estudio: no necesitas memorizar YAML. Necesitas saber dónde está cada ejemplo y adaptarlo en segundos. Un manifiesto de PersistentVolume, una NetworkPolicy o un Ingress con TLS son largos de escribir y fáciles de copiar.

Páginas que conviene tener localizadas mentalmente (se detalla más en la lección 12-04):

• El terminal es un navegador. Copiar y pegar funciona, pero con atajos particulares (habitualmente Ctrl+Shift+C / Ctrl+Shift+V en Linux). Practícalo.
• El editor disponible es vim (y nano). Si no manejas vim con soltura mínima, dedícale un par de horas antes del examen.
• Tienes acceso sudo a los nodos vía ssh cuando la tarea lo requiere (por ejemplo, para arreglar el kubelet).
• Hay un bloc de notas en la interfaz del examen para apuntar cosas; úsalo para llevar la lista de tareas pendientes.

El temario oficial del CKA se organiza en cinco dominios. Este es el reparto publicado en el momento de escribir esta lección; verifícalo en la web oficial, porque el programa se revisa periódicamente.

Fíjate bien en el reparto: resolución de problemas es el dominio más pesado, casi un tercio del examen. No es un tema que se estudie leyendo: se entrena rompiendo cosas y arreglándolas. Es exactamente lo que hiciste en el módulo 7 (07-06) y en el módulo 11 (11-06).

Con dos horas y ~17 tareas, la media es de unos 7 minutos por tarea, pero el reparto real es muy desigual:

Deja 10 minutos finales sin asignar para revisar. Es el mejor uso posible de esos minutos.

Esta es la sección que convierte el curso en un plan de estudio. Cada objetivo del temario está enlazado con la lección donde lo trabajaste. Repasar el CKA es, literalmente, releer estas lecciones y volver a hacer sus ejercicios en un clúster real.

El curso te ha dado el conocimiento, pero hay siete procedimientos que en el examen aparecen casi con seguridad y que hay que tener memorizados como una coreografía. Repásalos hasta que salgan sin pensar.

En el nodo de control:

En el nodo trabajador:

Si el token caducó (dura 24 h), se regenera desde el nodo de control:

Comprobación: kubectl get nodes -o wide debe mostrar todos los nodos en Ready.

Procedimiento canónico (siempre: plano de control primero, después los trabajadores, de uno en uno).

Trampas clásicas: olvidar --ignore-daemonsets en el drain (falla siempre, porque hay DaemonSets del CNI y de kube-proxy); usar upgrade apply en un trabajador; olvidar el uncordon final.

Es la tarea que más puntos vale y la que más gente falla. Memorízala.

Copia de seguridad:

Verificar la copia:

Restauración:

Claves que se olvidan:

• Los certificados de etcd están en /etc/kubernetes/pki/etcd/, no en /etc/kubernetes/pki/.
• Si el enunciado te da rutas de certificados distintas, usa las suyas.
• Hay que restaurar a un directorio nuevo, no sobre el existente.
• Lo que se modifica es el volumen hostPath, no solo el argumento --data-dir del contenedor. Cambia ambos si el manifiesto los tiene desalineados.

Tras renovar hay que reiniciar los pods estáticos del plano de control —moviendo temporalmente los manifiestos fuera de /etc/kubernetes/manifests/ o reiniciando el kubelet— y regenerar ~/.kube/config si ha cambiado el certificado de administración.

También puede pedirse aprobar una CSR para un usuario nuevo:

El manifiesto de la CertificateSigningRequest (grupo certificates.k8s.io/v1, con el campo request en base64, signerName: kubernetes.io/kube-apiserver-client y usages: ["client auth"]) se copia de la documentación buscando "certificate signing requests": es más rápido y más seguro que escribirlo.

Este es el escenario estrella del dominio de resolución de problemas. La secuencia mental es siempre la misma:

Causas típicas que te van a poner, y su síntoma:

Regla de oro: los pods estáticos no se gestionan con kubectl. Se gestionan editando ficheros en /etc/kubernetes/manifests/, y el kubelet reacciona en segundos.

Aparece en prácticamente todos los exámenes. Estos cuatro comandos resuelven el 90 % de los casos:

Y la comprobación que siempre hay que dejar hecha:

Este plan asume entre 8 y 10 horas semanales y que ya has hecho el curso. La regla que lo gobierna: por cada hora de lectura, dos horas de teclado.

Cómo usarlo. La semana 6 no es para aprender nada nuevo: es para medir, corregir y descansar. Deja el último día para preparar el entorno físico del examen (ver 12-04) y no toques temas nuevos en las últimas 48 horas.

La matrícula suele incluir acceso a un simulador de examen (habitualmente dos sesiones de unas 36 horas cada una, en un entorno equivalente al real). Consejos de uso:

• No lo gastes pronto. Úsalo cuando ya te sientas razonablemente preparado, en la semana 6.
• Su dificultad suele ser superior a la del examen real. Si sacas un 60 % ahí, vas bien.
• Lo valioso no es la nota, sino el solucionario: léelo entero, incluidas las tareas que acertaste, porque casi siempre hay una forma más rápida.

No hace falta nada de pago. Con kind tienes un clúster de un nodo de control y dos trabajadores en menos de un minuto (repasa 10-01):

Ahora bien, para practicar kubeadm, etcd y el plano de control roto necesitas máquinas de verdad (VMs con Multipass, Vagrant o similar): kind ejecuta el plano de control dentro de contenedores y no reproduce fielmente ni systemctl ni los pods estáticos del host.

Practica estas ocho como si fueran el examen: cronómetro en marcha, solo kubernetes.io abierto. Los escenarios son de Rutas Norte.

Contexto: kubectl config use-context rutas-norte-dev

En el namespace rutas-norte-dev, crea un Deployment llamado tienda-web con la imagen nginx:1.27-alpine y 3 réplicas. Expónlo con un Service ClusterIP llamado tienda-web-svc en el puerto 80.

Comprobación:

La trampa: si endpoints sale vacío, el selector no casa. kubectl expose lo hereda bien; escribirlo a mano es donde se rompe.

Contexto: kubectl config use-context rutas-norte-pro

Haz una copia de seguridad de etcd en /opt/etcd-rutas-norte.db. Después, restaura la copia previa /opt/snapshot-anterior.db en el directorio /var/lib/etcd-restore. Los certificados están en /etc/kubernetes/pki/etcd/.

En el manifiesto, el volumen queda así:

Comprobación:

La trampa: snapshot save no necesita sudo si tu usuario lee los certificados, pero restore escribe en /var/lib, así que sí. Y hay que cambiar el hostPath del volumen, no basta con el --data-dir del contenedor.

Contexto: kubectl config use-context rutas-norte-pro

El nodo nodo-2 va a recibir mantenimiento. Vacíalo de cargas de trabajo sin eliminar los DaemonSets, y asegúrate de que no se planifiquen pods nuevos en él.

Comprobación:

La trampa: drain ya hace cordon. Si falla por un pod suelto sin controlador, añade --force.

Contexto: kubectl config use-context rutas-norte-pro

Crea la ServiceAccount soporte en rutas-norte-pro. Concédele permiso para ver pods y leer sus logs en ese namespace, y nada más. Verifica el resultado.

Comprobación:

La trampa: pods/log es un subrecurso independiente. Sin él, kubectl logs falla aunque puedas listar pods.

Contexto: kubectl config use-context rutas-norte-pre

Crea un PersistentVolume pv-informes de 2Gi, modo ReadWriteOnce, hostPath en /mnt/informes, con storageClassName: manual. Crea un PVC pvc-informes de 1Gi que lo consuma, y un Pod informes-ocupacion con imagen busybox:1.36 que lo monte en /datos y ejecute sleep 3600.

Comprobación:

La trampa: si el storageClassName no coincide exactamente entre PV y PVC, el PVC se queda en Pending para siempre. Y el PV es de ámbito de clúster: no lleva namespace.

Contexto: kubectl config use-context rutas-norte-pro

El nodo nodo-3 aparece como NotReady. Investiga y devuélvelo al estado Ready sin reinstalar nada.

Salida típica del diagnóstico:

La trampa: enable además de start. Si solo haces start, el corrector puede reiniciar el nodo y volverás a suspender. Si el kubelet arranca pero muere, mira journalctl: suele ser una ruta mal puesta en /var/lib/kubelet/config.yaml o un kubeconfig inválido.

Contexto: kubectl config use-context rutas-norte-pro

En rutas-norte-pro, postgres-reservas solo debe aceptar tráfico entrante en el puerto 5432 desde pods con la etiqueta app=api-reservas del mismo namespace. Todo lo demás, denegado.

Comprobación:

La trampa: declarar policyTypes: [Ingress] es lo que hace que la política deniegue todo lo no permitido. Si lo omites y no hay reglas de egress, el comportamiento no es el que esperas. Y el CNI debe soportar NetworkPolicies (Calico sí; el CNI por defecto de kind, no).

Contexto: kubectl config use-context rutas-norte-pro

Actualiza el nodo trabajador nodo-1 de la versión 1.30.4 a la 1.31.1. El plano de control ya está en 1.31.1.

Comprobación:

La trampa: en trabajadores es kubeadm upgrade node, nunca upgrade apply. Y si el repositorio de paquetes está pinneado a la minor 1.30, primero hay que cambiar la URL del repositorio de pkgs.k8s.io a v1.31, o apt no verá la versión nueva.

1. Practica en un clúster real, no leyendo. El CKA se aprueba con las manos.
2. Cronometra desde el día uno. Saber hacer algo en 15 minutos no sirve si el objetivo son 6.
3. Domina kubectl explain. kubectl explain pod.spec.containers.livenessProbe --recursive te ahorra abrir el navegador.
4. Ten la documentación en la cabeza como un mapa. No memorices YAML: memoriza en qué página está.
5. Aprende a leer eventos. kubectl describe pod y kubectl get events --sort-by=.lastTimestamp resuelven la mitad del dominio de troubleshooting.
6. Trabaja con sudo cómodo. Muchas tareas de administración son en el nodo, no en kubectl.
7. Simula el entorno del examen. Mismo navegador, mismo terminal, mismo teclado. Reduce fricción el día D.

Toma el temario oficial vigente del CKA (descárgalo del repositorio cncf/curriculum) y, para cada objetivo, anota en una tabla propia tres cosas: la lección de este curso donde se cubre, tu nivel de confianza del 1 al 5, y si sabrías resolverlo sin documentación. Ordena la tabla por confianza ascendente: ese orden es tu plan de repaso.

En un clúster de tres nodos montado con kubeadm (o VMs), resuelve en 30 minutos seguidos y sin pausas:

1. Copia de seguridad de etcd en /opt/backup.db y verificación con snapshot status.
2. Drenar nodo-1, actualizar su kubelet a la siguiente versión de parche, devolverlo al servicio.
3. Crear la ServiceAccount auditor con permisos de solo lectura sobre pods y services en todos los namespaces, y demostrarlo con auth can-i.

Provoca deliberadamente estos tres fallos, de uno en uno, y arregla cada uno midiendo el tiempo:

1. Cambia el puerto de --secure-port en /etc/kubernetes/manifests/kube-apiserver.yaml a 6444.
2. Renombra /etc/kubernetes/pki/etcd/server.key a server.key.bak.
3. Cambia staticPodPath en /var/lib/kubelet/config.yaml a /etc/kubernetes/manifiestos.

Objetivo: diagnosticar y arreglar cada uno en menos de 6 minutos.

Solución al Ejercicio 1

No hay solución única, pero tu tabla debe parecerse a esta (extracto); el criterio decisivo es la última columna:

Todo lo que tenga confianza ≤ 3 y "No" en la última columna va a las semanas 4 y 5 del plan. La trampa habitual es puntuarse alto en lo que se entiende pero nunca se ha ejecutado: si no lo has hecho con las manos esta semana, la confianza es 3 como mucho.

Solución al Ejercicio 2

Bloque de etcd (objetivo 8 min):

Bloque de nodo (objetivo 15 min):

Para un cambio solo de parche (1.30.4 → 1.30.5) basta con actualizar el kubelet; en un cambio de versión menor haría falta además sudo kubeadm upgrade node.

Bloque de RBAC (objetivo 7 min): al ser "todos los namespaces", exige ClusterRole + ClusterRoleBinding:

El error clásico es usar Role+RoleBinding: solo cubriría un namespace. El segundo error es ClusterRole con RoleBinding, que restringe los permisos a un namespace concreto —útil en otros casos, pero no es lo pedido.

Solución al Ejercicio 3

La secuencia de diagnóstico es siempre la misma, y merece la pena automatizarla:

Diferencia clave que este ejercicio graba: los manifiestos de /etc/kubernetes/manifests/ los relee el kubelet solo, en segundos; /var/lib/kubelet/config.yaml sí requiere sudo systemctl restart kubelet para surtir efecto.

El CKA no mide si sabes Kubernetes en abstracto: mide si sabes operar un clúster con las manos y con prisa. Después de once módulos construyendo Rutas Norte, el conocimiento ya lo tienes; lo que esta lección te ha dado es la traducción de ese conocimiento al lenguaje del examen.

Los puntos que debes llevarte:

• El CKA certifica el perfil de administración: nodos, plano de control, etcd, red, almacenamiento, RBAC y, sobre todo, diagnóstico (el dominio de mayor peso, en torno al 30 %).
• El examen es práctico, cronometrado y con varios clústeres. El use-context es el primer comando de cada tarea, sin excepción.
• Hay puntuación parcial: nunca dejes una tarea vacía.
• Puedes consultar la documentación oficial y solo esa. Estudia dónde está cada cosa, no memorices YAML.
• La tabla del apartado 4 convierte este curso en tu plan de estudio: cada objetivo oficial tiene su lección.
• Siete procedimientos hay que tenerlos automatizados: kubeadm, upgrade, etcd, certificados, drain, plano de control roto y RBAC.
• Consulta siempre el temario oficial vigente en la web de la Linux Foundation / CNCF antes de matricularte: pesos, duración y condiciones cambian.

En la siguiente lección cambiamos de perfil. Si el CKA es la certificación de quien mantiene el clúster, el CKAD es la de quien construye sobre él: menos etcd y más manifiestos de aplicación, menos administración y mucha más velocidad con kubectl. Veremos en qué se diferencian, qué dominios entran y cómo se entrena la competencia que decide ese examen: hacer muchas cosas correctas en muy poco tiempo.