Introduction
Les tâches de l'examen CKAD exigent souvent que vous choisissiez la ressource de charge de travail Kubernetes appropriée avant de rédiger un manifeste. Un Pod est la plus petite unité exécutable, un Deployment maintient la disponibilité des réplicas d'une application longue durée, un Job exécute une tâche jusqu'à son achèvement, et un CronJob stocke un modèle de Job planifié.
Dans ce laboratoire, vous comparerez ces ressources par le biais de comportements observables plutôt que par la mémorisation de définitions. Vous constaterez qu'un Pod autonome ne revient pas après suppression, qu'un Deployment recrée son Pod, qu'un Job se termine après avoir enregistré son succès, et qu'un CronJob conserve les informations de planification pour des tâches récurrentes.
Préparer un espace de noms pour la comparaison des charges de travail
Dans cette étape, vous allez préparer un espace de noms (namespace) propre pour comparer les ressources de charge de travail.
Commencez dans /home/labex/project. Vous créerez de petits manifestes dans ce répertoire au fur et à mesure que vous comparerez les comportements des charges de travail.
mkdir -p /home/labex/project
cd /home/labex/project
Vérifiez que le serveur API Kubernetes est accessible. Si la machine virtuelle vient de démarrer et que le nœud n'est pas encore prêt, attendez quelques secondes et relancez la commande.
kubectl get nodes --request-timeout=5s
La sortie attendue inclut :
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Les charges de travail créent des Pods, attendez donc que le Pod réseau du cluster soit prêt (Ready).
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Sortie attendue :
pod/calico-node-... condition met
Créez un espace de noms nommé ckad-prep-workloads :
kubectl create namespace ckad-prep-workloads
Définissez cet espace de noms comme contexte actuel :
kubectl config set-context --current --namespace=ckad-prep-workloads
Confirmez l'espace de noms actuel :
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Sortie attendue :
ckad-prep-workloads
Comparer un Pod avec un Deployment
Dans cette étape, vous allez comparer un Pod autonome avec un Deployment en supprimant les deux Pods et en observant la réaction de Kubernetes.
Un Pod autonome est utile lorsque vous avez besoin d'une unité d'exécution gérée directement pour une tâche très simple ou une inspection. Un Deployment est préférable pour une application longue durée, car il possède un ReplicaSet, et ce dernier maintient le nombre de Pods requis en cours d'exécution.
Créez un manifeste de Pod autonome. Le conteneur est en veille (sleep) afin que le Pod reste actif assez longtemps pour être observé. Le champ terminationGracePeriodSeconds: 0 permet de garder ce laboratoire rapide lorsque vous supprimerez le Pod plus tard.
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
Créez un manifeste de Deployment. Ce Deployment demande à Kubernetes de maintenir un Pod managed-worker en cours d'exécution, et son modèle de Pod utilise le même paramètre de terminaison rapide.
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
Appliquez les deux manifestes :
kubectl apply -f standalone-pod.yaml
kubectl apply -f managed-deployment.yaml
Sortie attendue :
pod/standalone-task created
deployment.apps/managed-worker created
Attendez que les deux charges de travail soient prêtes :
kubectl wait --for=condition=Ready pod/standalone-task --timeout=120s
kubectl wait --for=condition=Available deployment/managed-worker --timeout=120s
Sortie attendue :
pod/standalone-task condition met
deployment.apps/managed-worker condition met
Capturez le nom du Pod du Deployment actuel, puis supprimez le Pod autonome et le Pod appartenant au Deployment :
managed_pod="$(kubectl get pods -l app=managed-worker -o 'jsonpath={.items[0].metadata.name}')"
kubectl delete pod standalone-task "$managed_pod"
La sortie attendue inclut :
pod "standalone-task" deleted
pod "managed-worker-..." deleted
Attendez que le Deployment redevienne disponible :
kubectl wait --for=condition=Available deployment/managed-worker --timeout=120s
Sortie attendue :
deployment.apps/managed-worker condition met
Listez les Pods. Le Pod autonome doit avoir disparu, tandis qu'un nouveau Pod managed-worker doit exister.
kubectl get pods
La sortie attendue inclut un Pod managed-worker, mais pas standalone-task :
NAME READY STATUS RESTARTS AGE
managed-worker-... 1/1 Running 0 ...
Choisir un Job pour une tâche à accomplir
Dans cette étape, vous choisirez un Job pour une tâche qui doit se terminer avec succès au lieu de s'exécuter indéfiniment.
Un Deployment est approprié lorsque l'état souhaité est « maintenir cette application en cours d'exécution ». Un Job est préférable lorsque l'état souhaité est « exécuter cette tâche jusqu'à son achèvement ». C'est pourquoi les migrations, le traitement par lots et les commandes de maintenance ponctuelles correspondent généralement à des Jobs.
Créez un Job nommé schema-migration :
kubectl create job schema-migration --image=busybox:1.36 -- /bin/sh -c 'echo migration-start; echo migration-complete'
Sortie attendue :
job.batch/schema-migration created
Attendez que le Job atteigne la condition Complete :
kubectl wait --for=condition=Complete job/schema-migration --timeout=120s
Sortie attendue :
job.batch/schema-migration condition met
Inspectez le résumé du Job. COMPLETIONS doit afficher 1/1, ce qui signifie que la tâche s'est exécutée avec succès une fois.
kubectl get job schema-migration
La sortie attendue inclut :
NAME STATUS COMPLETIONS DURATION AGE
schema-migration Complete 1/1 ... ...
Lisez les journaux (logs) du Job :
kubectl logs job/schema-migration
Sortie attendue :
migration-start
migration-complete
Choisir un CronJob pour une tâche récurrente
Dans cette étape, vous choisirez un CronJob pour une tâche qui doit s'exécuter selon un calendrier.
Un CronJob est un modèle de Job planifié. C'est le bon choix lorsque la tâche doit se répéter ultérieurement, et non pas simplement s'exécuter une fois. Pour que ce laboratoire guidé reste déterministe, vous créerez le CronJob dans un état suspendu. Cela vous permet d'inspecter le calendrier et le modèle sans attendre une limite temporelle.
Créez 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
Appliquez le manifeste :
kubectl apply -f cleanup-cronjob.yaml
Sortie attendue :
cronjob.batch/cleanup-schedule created
Inspectez le résumé du CronJob. SUSPEND est True car ce laboratoire utilise la définition du CronJob pour apprendre le choix de la ressource sans attendre les Jobs planifiés.
kubectl get cronjob cleanup-schedule
La sortie attendue inclut :
NAME SCHEDULE TIMEZONE SUSPEND ACTIVE LAST SCHEDULE AGE
cleanup-schedule */5 * * * * <none> True 0 <none> ...
Lisez le calendrier et l'image du modèle directement depuis l'objet :
kubectl get cronjob cleanup-schedule -o 'jsonpath={.spec.schedule}{" "}{.spec.suspend}{" "}{.spec.jobTemplate.spec.template.spec.containers[0].image}{"\n"}'
Sortie attendue :
*/5 * * * * true busybox:1.36
Listez les ressources de charge de travail que vous avez créées dans ce laboratoire. Cette vue relie le type de ressource au comportement attendu : un Deployment pour un réplica longue durée, un Job pour un achèvement, et un CronJob pour une récurrence.
kubectl get deployment,job,cronjob
La sortie attendue inclut :
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> ...
Résumé
Vous avez comparé les ressources de charge de travail Kubernetes en fonction de leur comportement. Un Pod autonome n'est pas revenu après suppression, un Deployment a recréé son Pod pour maintenir un réplica disponible, un Job a exécuté une tâche jusqu'à son succès, et un CronJob a stocké un modèle de Job récurrent. Ces observations vous aident à choisir la ressource appropriée avant de rédiger un manifeste de type CKAD.
