Saltar al contenido principal

Preparación del examen CKAD

Cierre de la especialización de desarrollo: el plan de ataque para el CKAD (Certified Kubernetes Application Developer). Si vienes de leer la guía del CKA, buena parte de la logística es idéntica; aquí nos centramos en lo que hace al CKAD diferente: es el examen más rápido de los tres.

Cómo es el examen​

  • Formato: 100% práctico, 15-20 ejercicios en 2 horas, sobre varios clusters reales.
  • Puntuación: se aprueba con un 66%; cada pregunta indica su peso.
  • Documentación permitida: una pestaña con kubernetes.io/docs y los sitios oficiales (incluida la doc de Helm).
  • Incluye: un retake gratuito y dos sesiones del simulador killer.sh. Validez de 2 años.
  • Sin requisitos previos (a diferencia de la CKS, que exige la CKA).

La diferencia de carácter con el CKA: menos administración de cluster (no hay etcd, ni kubeadm, ni nodos rotos) y más volumen de ejercicios cortos de crear y configurar recursos. El CKAD se gana con dedos rápidos.

Temario oficial y dónde lo hemos cubierto​

DominioPesoCapítulos del curso
Diseño y construcción de aplicaciones20%106, 109, 110, 301, 302, 116
Despliegue de aplicaciones20%108, 303, 125
Observabilidad y mantenimiento15%114, 124, 306, 203 (deprecaciones de API)
Configuración y entorno de aplicaciones25%115, 117, 118, 120 (service accounts), 119 (security context)
Servicios y redes20%111, 112, 304, 119 (network policies)

Fíjate en que gran parte del CKAD vive en la parte común del curso: si la trabajaste bien, ya tienes el 70% hecho.

La estrategia: imperativo por defecto​

En el CKAD, escribir YAML a mano es perder el examen. La secuencia mental para cada ejercicio:

  1. ¿Puedo resolverlo entero con un comando? (kubectl run, create, expose, set, scale, label, annotate...)
  2. Si no, genero el esqueleto con $do y edito solo lo necesario.
  3. Si el recurso no se puede generar (NetworkPolicy, PVC, Ingress...), plantilla de la documentación.

El repertorio imperativo que debe salir solo (todo visto en el curso):

export do="--dry-run=client -o yaml"

k run nginx --image=nginx --port=80 --env=MODE=prod --labels=app=web $do
k create deployment web --image=nginx --replicas=3 $do
k expose deployment web --port=80 --target-port=8080 --type=NodePort
k create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(100)'
k create cronjob backup --image=busybox --schedule="0 2 * * *" -- sh -c "echo backup"
k create configmap cfg --from-literal=k=v --from-file=app.properties
k create secret generic s --from-literal=pass=1234
k create sa mi-app
k create role r --verb=get,list --resource=pods
k create rolebinding rb --role=r --serviceaccount=default:mi-app
k autoscale deployment web --min=2 --max=8 --cpu-percent=70
k set image deployment/web nginx=nginx:1.27
k set env deployment/web MODE=debug
k set sa deployment/web mi-app
k rollout status/history/undo deployment web

Y los tres comandos de inspección que resuelven cualquier duda sin salir de la terminal:

k explain pod.spec.containers.securityContext   # La spec exacta de cualquier campo
k api-resources                                  # Nombres, grupos y abreviaturas
k get pod x -o yaml | less                       # Qué hay realmente desplegado

Los clásicos que caen (casi) seguro​

  1. Pod multi-contenedor con volumen compartido (302): app + sidecar sobre un emptyDir.
  2. Init container que prepara algo para el principal (301).
  3. ConfigMap/Secret consumido como env y como volumen (115).
  4. Probes: añadir liveness/readiness a un deployment existente (114).
  5. Arreglar un pod roto: CrashLoopBackOff, imagen errónea, OOMKilled (306).
  6. Canary con dos deployments y reparto por réplicas (303).
  7. SecurityContext: runAsUser, capabilities, readOnlyRootFilesystem (119).
  8. NetworkPolicy que permita solo cierto tráfico (119).
  9. Ingress para un service existente (112).
  10. Job/CronJob con completions, parallelism o schedule (110).
  11. Service account en un deployment + RBAC básico (120, 121).
  12. Helm: instalar, actualizar o hacer rollback de una release (125).
  13. Deprecaciones de API: actualizar un manifiesto con apiVersion antigua (203).

Plan de entrenamiento​

  1. Práctica diaria corta: el CKAD premia la memoria muscular. Mejor 30 minutos al día de ejercicios imperativos que un atracón semanal.
  2. Killercoda CKAD: escenarios gratuitos por tema.
  3. killer.sh: las dos sesiones incluidas. Más difícil que el examen real: úsalo para calibrar tiempos, no para hundirte la moral.
  4. Cronometra todo: si un ejercicio básico (deployment + service + probe) te lleva más de 4-5 minutos, repítelo hasta que no.

El día del examen​

Los mismos consejos logísticos del CKA aplican (proctor, identificación, sala). Específicos del CKAD:

  • Contexto y namespace: cada pregunta indica ambos. kubectl config set-context --current --namespace=<ns> nada más empezar el ejercicio.
  • Triaje agresivo: con tantos ejercicios cortos, saltar rápido lo que se atasca es aún más rentable que en el CKA.
  • Verifica el estado final: pod Running, endpoints poblados, rollout completado. Es lo que puntúa.

¡A por ello! Y si después quieres el cinturón completo: CKA para administrar el cluster y CKS para asegurarlo.

Volver al índice