Introducción
Las tareas del examen CKAD a menudo requieren que elija el recurso de carga de trabajo de Kubernetes adecuado antes de escribir un manifiesto. Un Pod es la unidad ejecutable más pequeña, un Deployment mantiene disponibles las réplicas de aplicaciones de larga duración, un Job ejecuta una tarea hasta su finalización y un CronJob almacena una plantilla de Job programada.
En este laboratorio, comparará estos recursos a través de su comportamiento observable en lugar de memorizar definiciones. Verá que un Pod independiente no vuelve a aparecer tras ser eliminado, un Deployment recrea su Pod, un Job finaliza y registra el éxito, y un CronJob almacena información de programación para tareas recurrentes.
Preparar un espacio de nombres para la comparación de cargas de trabajo
En este paso, preparará un espacio de nombres (namespace) limpio para comparar los recursos de carga de trabajo.
Comience en /home/labex/project. Creará pequeños manifiestos en este directorio a medida que compare el comportamiento de las cargas de trabajo.
mkdir -p /home/labex/project
cd /home/labex/project
Compruebe que el servidor de la API de Kubernetes sea accesible. Si la máquina virtual acaba de iniciarse y el nodo aún no está listo, espere unos segundos y vuelva a ejecutar el comando.
kubectl get nodes --request-timeout=5s
La salida esperada incluye:
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Las cargas de trabajo crean Pods, así que espere hasta que el Pod de red del clúster esté listo (Ready).
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Salida esperada:
pod/calico-node-... condition met
Cree un espacio de nombres llamado ckad-prep-workloads:
kubectl create namespace ckad-prep-workloads
Establezca este espacio de nombres como el espacio de nombres del contexto actual:
kubectl config set-context --current --namespace=ckad-prep-workloads
Confirme el espacio de nombres actual:
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Salida esperada:
ckad-prep-workloads
Comparar un Pod con un Deployment
En este paso, comparará un Pod independiente con un Deployment eliminando ambos Pods y observando qué hace Kubernetes a continuación.
Un Pod independiente es útil cuando necesita una unidad de ejecución gestionada directamente para una tarea muy pequeña o una inspección. Un Deployment es mejor para una aplicación de larga duración porque un Deployment posee un ReplicaSet, y el ReplicaSet mantiene el número solicitado de Pods en ejecución.
Cree un manifiesto de Pod independiente. El contenedor entra en modo de espera (sleep) para que el Pod permanezca activo el tiempo suficiente para observarlo. El campo terminationGracePeriodSeconds: 0 hace que este laboratorio sea más rápido cuando elimine el Pod más adelante.
cat > standalone-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: standalone-task
labels:
app: standalone-task
workload.labex.io/intent: direct-pod
spec:
terminationGracePeriodSeconds: 0
containers:
- name: sleeper
image: busybox:1.36
command: ["/bin/sh", "-c", "sleep 3600"]
EOF
Cree un manifiesto de Deployment. Este Deployment le pide a Kubernetes que mantenga un Pod managed-worker en ejecución, y su plantilla de Pod utiliza la misma configuración de terminación rápida.
cat > managed-deployment.yaml <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
name: managed-worker
labels:
workload.labex.io/intent: long-running
spec:
replicas: 1
selector:
matchLabels:
app: managed-worker
template:
metadata:
labels:
app: managed-worker
spec:
terminationGracePeriodSeconds: 0
containers:
- name: sleeper
image: busybox:1.36
command: ["/bin/sh", "-c", "sleep 3600"]
EOF
Aplique ambos manifiestos:
kubectl apply -f standalone-pod.yaml
kubectl apply -f managed-deployment.yaml
Salida esperada:
pod/standalone-task created
deployment.apps/managed-worker created
Espere hasta que ambas cargas de trabajo estén listas:
kubectl wait --for=condition=Ready pod/standalone-task --timeout=120s
kubectl wait --for=condition=Available deployment/managed-worker --timeout=120s
Salida esperada:
pod/standalone-task condition met
deployment.apps/managed-worker condition met
Capture el nombre del Pod del Deployment actual, luego elimine el Pod independiente y el Pod propiedad del Deployment:
managed_pod="$(kubectl get pods -l app=managed-worker -o 'jsonpath={.items[0].metadata.name}')"
kubectl delete pod standalone-task "$managed_pod"
La salida esperada incluye:
pod "standalone-task" deleted
pod "managed-worker-..." deleted
Espere a que el Deployment vuelva a estar disponible:
kubectl wait --for=condition=Available deployment/managed-worker --timeout=120s
Salida esperada:
deployment.apps/managed-worker condition met
Enumere los Pods. El Pod independiente debería haber desaparecido, mientras que debería existir un nuevo Pod managed-worker.
kubectl get pods
La salida esperada incluye un Pod managed-worker, pero no standalone-task:
NAME READY STATUS RESTARTS AGE
managed-worker-... 1/1 Running 0 ...
Elegir un Job para tareas de finalización
En este paso, elegirá un Job para el trabajo que debe finalizar con éxito en lugar de ejecutarse indefinidamente.
Un Deployment es adecuado cuando el estado deseado es "mantener esta aplicación en ejecución". Un Job es más adecuado cuando el estado deseado es "ejecutar esta tarea hasta que se complete". Es por esto que las migraciones, el procesamiento por lotes y los comandos de mantenimiento únicos generalmente se asignan a Jobs.
Cree un Job llamado schema-migration:
kubectl create job schema-migration --image=busybox:1.36 -- /bin/sh -c 'echo migration-start; echo migration-complete'
Salida esperada:
job.batch/schema-migration created
Espere hasta que el Job alcance la condición Complete:
kubectl wait --for=condition=Complete job/schema-migration --timeout=120s
Salida esperada:
job.batch/schema-migration condition met
Inspeccione el resumen del Job. COMPLETIONS debería mostrar 1/1, lo que significa que la tarea se ejecutó correctamente una vez.
kubectl get job schema-migration
La salida esperada incluye:
NAME STATUS COMPLETIONS DURATION AGE
schema-migration Complete 1/1 ... ...
Lea los registros (logs) del Job:
kubectl logs job/schema-migration
Salida esperada:
migration-start
migration-complete
Elegir un CronJob para trabajo recurrente
En este paso, elegirá un CronJob para el trabajo que debe ejecutarse según una programación.
Un CronJob es una plantilla de Job programada. Es la elección correcta cuando la tarea debe repetirse más tarde, no solo completarse una vez. Para mantener este laboratorio guiado de forma determinista, creará el CronJob en un estado suspendido. Esto le permite inspeccionar la programación y la plantilla sin esperar a que se cumpla el tiempo programado.
Cree cleanup-cronjob.yaml:
cat > cleanup-cronjob.yaml <<'EOF'
apiVersion: batch/v1
kind: CronJob
metadata:
name: cleanup-schedule
labels:
workload.labex.io/intent: recurring-task
spec:
schedule: "*/5 * * * *"
suspend: true
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: cleanup
image: busybox:1.36
command:
- /bin/sh
- -c
- 'echo cleanup-ready'
EOF
Aplique el manifiesto:
kubectl apply -f cleanup-cronjob.yaml
Salida esperada:
cronjob.batch/cleanup-schedule created
Inspeccione el resumen del CronJob. SUSPEND es True porque este laboratorio utiliza la definición del CronJob para aprender la elección del recurso sin esperar a que se ejecuten los Jobs programados.
kubectl get cronjob cleanup-schedule
La salida esperada incluye:
NAME SCHEDULE TIMEZONE SUSPEND ACTIVE LAST SCHEDULE AGE
cleanup-schedule */5 * * * * <none> True 0 <none> ...
Lea la programación y la imagen de la plantilla directamente desde el objeto:
kubectl get cronjob cleanup-schedule -o 'jsonpath={.spec.schedule}{" "}{.spec.suspend}{" "}{.spec.jobTemplate.spec.template.spec.containers[0].image}{"\n"}'
Salida esperada:
*/5 * * * * true busybox:1.36
Enumere los recursos de carga de trabajo que creó en este laboratorio. Esta vista conecta el tipo de recurso con el comportamiento previsto: un Deployment para una réplica de larga duración, un Job para la finalización y un CronJob para la recurrencia.
kubectl get deployment,job,cronjob
La salida esperada incluye:
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/managed-worker 1/1 1 1 ...
NAME STATUS COMPLETIONS DURATION AGE
job.batch/schema-migration Complete 1/1 ... ...
NAME SCHEDULE TIMEZONE SUSPEND ACTIVE LAST SCHEDULE AGE
cronjob.batch/cleanup-schedule */5 * * * * <none> True 0 <none> ...
Resumen
Comparó los recursos de carga de trabajo de Kubernetes según su comportamiento. Un Pod independiente no volvió a aparecer tras ser eliminado, un Deployment recreó su Pod para mantener una réplica disponible, un Job ejecutó una tarea hasta su finalización exitosa y un CronJob almacenó una plantilla de Job recurrente. Estas observaciones le ayudarán a elegir el recurso adecuado antes de escribir un manifiesto al estilo CKAD.
