Durée estimée : 15 minutes
Objective: Learn the basics of creating a Deployment, scaling it, and observing the underlying ReplicaSets and Pods.
Context: You need to deploy a stateless web application and be able to adjust its capacity based on demand.
Instructions:
app-suite.app-suite namespace, create a Deployment named frontend-app.
app=frontend,env=production.nginx-container, use the image nginx:1.27.4, and expose port 80./opt/cka_exercises/deploiements/Ex1/deployment-frontend.yaml and apply it.kubectl get deployment frontend-app -n app-suite -o wide in /opt/cka_exercises/deploiements/Ex1/deployment_status.txt.kubectl get rs -n app-suite -l app=frontend in /opt/cka_exercises/deploiements/Ex1/replicaset_status.txt.kubectl get pods -n app-suite -l app=frontend in /opt/cka_exercises/deploiements/Ex1/pods_status_initial.txt.frontend-app Deployment to 4 replicas.
kubectl scale command. Store the command used in /opt/cka_exercises/deploiements/Ex1/scale_command.txt.kubectl get pods -n app-suite -l app=frontend in /opt/cka_exercises/deploiements/Ex1/pods_status_scaled.txt.frontend-app Deployment and save the output to /opt/cka_exercises/deploiements/Ex1/deployment_describe.txt. Pay attention to the events section.1. Création du Namespace :
kubectl create namespace app-suite
mkdir -p /opt/cka_exercises/deploiements/Ex1
2. Création du Déploiement frontend-app:
Impérative : kubectl create deployment frontend-app --image=nginx:1.27 --replicas=2 --namespace=app-suite --port=80 --dry-run=client -o yaml puis ajouter les labels
Fichier /opt/cka_exercises/deploiements/Ex1/deployment-frontend.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend-app
namespace: app-suite
labels:
app: frontend
env: production
spec:
replicas: 2
selector:
matchLabels:
app: frontend
env: production
template:
metadata:
labels:
app: frontend
env: production
spec:
containers:
- name: nginx-container
image: nginx:1.27.4
ports:
- containerPort: 80
Appliquez-le :
kubectl apply -f /opt/cka_exercises/deploiements/Ex1/deployment-frontend.yaml
3. Vérification du Déploiement initial :
# Attendre que les pods soient prêts
# kubectl get pods -n app-suite -w
kubectl get deployment frontend-app -n app-suite -o wide > /opt/cka_exercises/deploiements/Ex1/deployment_status.txt
kubectl get rs -n app-suite -l app=frontend > /opt/cka_exercises/deploiements/Ex1/replicaset_status.txt
kubectl get pods -n app-suite -l app=frontend > /opt/cka_exercises/deploiements/Ex1/pods_status_initial.txt
# deployment_status.txt devrait montrer READY 2/2.
# replicaset_status.txt devrait montrer un ReplicaSet avec DESIRED 2, CURRENT 2, READY 2.
# pods_status_initial.txt devrait lister 2 Pods en état Running.
4. Mise à l'échelle du Déploiement :
echo "kubectl scale deployment frontend-app --replicas=4 -n app-suite" > /opt/cka_exercises/deploiements/Ex1/scale_command.txt
kubectl scale deployment frontend-app --replicas=4 -n app-suite
5. Vérification après la mise à l'échelle :
# Attendre que les nouveaux pods soient prêts
# kubectl get pods -n app-suite -w
kubectl get pods -n app-suite -l app=frontend > /opt/cka_exercises/deploiements/Ex1/pods_status_scaled.txt
# pods_status_scaled.txt devrait lister 4 Pods en état Running.
# Vous pouvez aussi vérifier `kubectl get deployment frontend-app -n app-suite` qui devrait montrer READY 4/4.
6. Description du Déploiement :
kubectl describe deployment frontend-app -n app-suite > /opt/cka_exercises/deploiements/Ex1/deployment_describe.txt
Commandes de Nettoyage :
kubectl delete namespace app-suite
rm -rf /opt/cka_exercises/deploiements/Ex1
Durée estimée : 30 minutes
Objective: Perform a rolling update on a Deployment to a new image version, troubleshoot a failed update, and then roll it back to the previous version.
Context: You need to update your web application to a new version and be prepared to quickly revert if issues arise.
Instructions:
frontend-app Deployment from Exercise 1 (with 4 replicas of nginx:1.27.4 or nginx:1.27) is running in the app-suite namespace. If not, recreate it.frontend-app Deployment to change the Nginx image to nginx:1.28.0 (ou une autre version que vous n'utilisiez pas, par exemple nginx:latest si vous utilisiez une version fixe, mais pour la CKA préférez des versions spécifiques).
kubectl set image command. Store the command used in /opt/cka_exercises/deploiements/Ex2/update_command.txt./opt/cka_exercises/deploiements/Ex2/rollout_status_command.txt./opt/cka_exercises/deploiements/Ex2/replicaset_observation_during_update.txt.nginx:1.28.0).
kubectl describe pod <pod-name> or kubectl get pod <pod-name> -o jsonpath) in /opt/cka_exercises/deploiements/Ex2/verify_new_image_command.txt.frontend-app Deployment to an image that does not exist, for example nginx:1.99.nonexistent.
kubectl set image again. Store the command in /opt/cka_exercises/deploiements/Ex2/failed_update_command.txt.ImagePullBackOff, ErrImagePull)? Store the command to check Pod statuses and a brief observation in /opt/cka_exercises/deploiements/Ex2/failed_update_pod_status.txt.kubectl describe pod <new-pod-name> -n app-suite to confirm the cause of the failure. Note key sections to check in the describe output in /opt/cka_exercises/deploiements/Ex2/describe_failed_pod.txt.kubectl rollout history deployment frontend-app -n app-suite in /opt/cka_exercises/deploiements/Ex2/rollout_history_before_undo.txt.frontend-app Deployment to its previous working version (nginx:1.28.0).
kubectl rollout undo command. Store the command used in /opt/cka_exercises/deploiements/Ex2/rollback_command.txt.nginx:1.28.0 image version.
/opt/cka_exercises/deploiements/Ex2/verify_rolled_back_image_command.txt.1. Prérequis : Déploiement frontend-app
Assurez-vous que frontend-app (4 réplicas, nginx:1.27.4 ou nginx:1.27) de l'Exercice 1 est en place.
# Si nettoyé, recréez le namespace et le déploiement de l\'Ex1 et scalez à 4.
# kubectl create namespace app-suite
# kubectl apply -f /opt/cka_exercises/deploiements/Ex1/deployment-frontend.yaml
# kubectl scale deployment frontend-app --replicas=4 -n app-suite
mkdir -p /opt/cka_exercises/deploiements/Ex2
2. Déclenchement de la mise à jour (Rolling Update) :
Image cible : nginx:1.28.0 (ou une version différente de celle initiale).
echo "kubectl set image deployment/frontend-app nginx-container=nginx:1.28.0 -n app-suite" > /opt/cka_exercises/deploiements/Ex2/update_command.txt
kubectl set image deployment/frontend-app nginx-container=nginx:1.28.0 -n app-suite
3. Suivi du déploiement :
echo "kubectl rollout status deployment/frontend-app -n app-suite" > /opt/cka_exercises/deploiements/Ex2/rollout_status_command.txt
# Exécutez la commande ci-dessus pour suivre en direct.
# kubectl rollout status deployment/frontend-app -n app-suite
# Observation des ReplicaSets :
echo "Pendant la mise à jour, un nouveau ReplicaSet est créé pour la version nginx:1.28.0 et monte en nombre de réplicas. L\'ancien ReplicaSet (nginx:1.27.4) diminue progressivement ses réplicas. Les deux coexistent temporairement jusqu\'à ce que le nouveau RS atteigne le nombre désiré de réplicas prêts." > /opt/cka_exercises/deploiements/Ex2/replicaset_observation_during_update.txt
# Pour observer : kubectl get rs -n app-suite --watch
4. Vérification de la nouvelle image des Pods :
# Choisissez un nom de Pod du déploiement mis à jour
# POD_NAME=$(kubectl get pods -n app-suite -l app=frontend -o jsonpath='{.items[0].metadata.name}')
# echo "kubectl describe pod $POD_NAME -n app-suite | grep Image:" > /opt/cka_exercises/deploiements/Ex2/verify_new_image_command.txt
# Ou pour tous les pods:
echo "kubectl get pods -n app-suite -l app=frontend -o jsonpath='{range .items[*]}{.metadata.name}{\"\\t\"}{.spec.containers[0].image}{\"\\n\"}{end}'" > /opt/cka_exercises/deploiements/Ex2/verify_new_image_command.txt
# Exécutez la commande :
# kubectl get pods -n app-suite -l app=frontend -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
# Tous les Pods devraient afficher nginx:1.28.0
5. Simulation d'une mise à jour échouée :
echo "kubectl set image deployment/frontend-app nginx-container=nginx:1.99.nonexistent -n app-suite" > /opt/cka_exercises/deploiements/Ex2/failed_update_command.txt
kubectl set image deployment/frontend-app nginx-container=nginx:1.99.nonexistent -n app-suite
# Laissez le déploiement tenter de créer les nouveaux pods.
# Après un moment, vérifiez les statuts des pods :
echo "kubectl get pods -n app-suite -l app=frontend -o wide
Observation: Les nouveaux Pods (ceux tentant de tirer nginx:1.99.nonexistent) seront dans un état comme ImagePullBackOff ou ErrImagePull. Les anciens Pods (nginx:1.28.0) resteront probablement en cours d'exécution et Ready (selon la stratégie de déploiement maxUnavailable)." > /opt/cka_exercises/deploiements/Ex2/failed_update_pod_status.txt
# Pour confirmer la cause, choisissez un des nouveaux pods en erreur :
# FAILED_POD_NAME=$(kubectl get pods -n app-suite -l app=frontend --field-selector=status.phase!=Running -o jsonpath='{.items[0].metadata.name}')
# Note: La commande ci-dessus pour FAILED_POD_NAME peut nécessiter un ajustement si aucun pod n'est "not Running" mais plutôt en CrashLoop etc.
# Une meilleure approche est de regarder les événements du déploiement ou les pods du nouveau ReplicaSet.
# Ou, plus simplement, notez le nom d'un pod en échec manuellement.
# Par exemple: FAILED_POD_NAME=frontend-app-xxxxxxxx-yyyyy (un pod du nouveau ReplicaSet)
echo "Pour un pod en échec (ex: FAILED_POD_NAME obtenu depuis 'kubectl get pods -n app-suite'):
kubectl describe pod <FAILED_POD_NAME> -n app-suite
Sections clés à vérifier dans la sortie de 'describe pod':
- Status: Devrait indiquer une phase comme Pending.
- Reason (dans Status): Peut être CreateContainerError.
- Events: Crucial. Recherchez des événements comme:
- Failed to pull image "nginx:1.99.nonexistent": rpc error: code = Unknown desc = Error response from daemon: manifest for nginx:1.99.nonexistent not found
- Error: ErrImagePull
- Error: ImagePullBackOff" > /opt/cka_exercises/deploiements/Ex2/describe_failed_pod.txt
6. Historique du déploiement avant rollback :
kubectl rollout history deployment frontend-app -n app-suite > /opt/cka_exercises/deploiements/Ex2/rollout_history_before_undo.txt
# Devrait montrer au moins trois révisions maintenant, la dernière étant celle qui a échoué.
7. Annulation de la mise à jour (Rollback vers la version nginx:1.28.0) :
echo "kubectl rollout undo deployment/frontend-app -n app-suite" > /opt/cka_exercises/deploiements/Ex2/rollback_command.txt
kubectl rollout undo deployment/frontend-app -n app-suite
# Ceci annulera à la révision précédente qui était nginx:1.28.0
8. Vérification après Rollback :
Suivez le statut du rollback avec kubectl rollout status deployment/frontend-app -n app-suite.
# Utilisez la même commande qu'à l'étape 4 pour vérifier les images.
echo "kubectl get pods -n app-suite -l app=frontend -o jsonpath='{range .items[*]}{.metadata.name}{\"\\t\"}{.spec.containers[0].image}{\"\\n\"}{end}'" > /opt/cka_exercises/deploiements/Ex2/verify_rolled_back_image_command.txt
# Exécutez la commande :
# kubectl get pods -n app-suite -l app=frontend -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
# Tous les Pods devraient de nouveau afficher nginx:1.28.0.
Commandes de Nettoyage :
# Optionnel: supprimer le déploiement si vous souhaitez le refaire proprement pour d\'autres exos
# kubectl delete deployment frontend-app -n app-suite
rm -rf /opt/cka_exercises/deploiements/Ex2
echo "Cleanup for Exercise 2 complete."
Durée estimée : 25 minutes
Objective: Understand how to run batch tasks using Jobs and schedule recurring tasks using CronJobs.
Context: You need to run a one-time data processing script and also schedule a nightly cleanup task.
Instructions:
batch-tasks.data-processor in the batch-tasks namespace.
busybox:1.36.sh -c "echo Starting data processing...; sleep 20; echo Data processing complete."restartPolicy should be OnFailure./opt/cka_exercises/deploiements/Ex3/job-data-processor.yaml and apply it.data-processor Job until it completes. Check the logs of the Pod created by the Job.
/opt/cka_exercises/deploiements/Ex3/job_status_command.txt./opt/cka_exercises/deploiements/Ex3/job_pod_logs_command.txt.nightly-cleaner in the batch-tasks namespace.
*/1 * * * *).busybox:1.36 image.sh -c "echo Performing nightly cleanup at $(date); sleep 5; echo Cleanup finished."restartPolicy should be OnFailure.successfulJobsHistoryLimit: 1, failedJobsHistoryLimit: 1)./opt/cka_exercises/deploiements/Ex3/cronjob-nightly-cleaner.yaml and apply it.nightly-cleaner CronJob. Check the logs of one of the Pods from a completed Job.
/opt/cka_exercises/deploiements/Ex3/cronjob_jobs_list_command.txt./opt/cka_exercises/deploiements/Ex3/cronjob_pod_logs_command.txt.1. Création du Namespace :
kubectl create namespace batch-tasks
mkdir -p /opt/cka_exercises/deploiements/Ex3
2. Création du Job data-processor:
Fichier /opt/cka_exercises/deploiements/Ex3/job-data-processor.yaml:
apiVersion: batch/v1
kind: Job
metadata:
name: data-processor
namespace: batch-tasks
spec:
template:
spec:
containers:
- name: processor
image: busybox:1.36
command: ["sh", "-c", "echo Starting data processing...; sleep 20; echo Data processing complete."]
restartPolicy: OnFailure
Appliquez-le :
kubectl apply -f /opt/cka_exercises/deploiements/Ex3/job-data-processor.yaml
3. Suivi du Job et des Logs :
echo "kubectl get job data-processor -n batch-tasks --watch" > /opt/cka_exercises/deploiements/Ex3/job_status_command.txt
# Exécutez la commande ci-dessus pour suivre.
# Une fois le Job complété (COMPLETIONS 1/1):
# POD_NAME_JOB=$(kubectl get pods -n batch-tasks -l job-name=data-processor -o jsonpath='{.items[0].metadata.name}')
# echo "kubectl logs $POD_NAME_JOB -n batch-tasks" > /opt/cka_exercises/deploiements/Ex3/job_pod_logs_command.txt
echo "POD_NAME_JOB=\$(kubectl get pods -n batch-tasks -l job-name=data-processor -o jsonpath='{.items[0].metadata.name}') && kubectl logs \$POD_NAME_JOB -n batch-tasks" > /opt/cka_exercises/deploiements/Ex3/job_pod_logs_command.txt
# Exécutez la commande sauvegardée. Les logs devraient être:
# Starting data processing...
# Data processing complete.
4. Création du CronJob nightly-cleaner:
Fichier /opt/cka_exercises/deploiements/Ex3/cronjob-nightly-cleaner.yaml:
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-cleaner
namespace: batch-tasks
spec:
schedule: "*/1 * * * *" # Toutes les minutes pour le test
jobTemplate:
spec:
template:
spec:
containers:
- name: cleaner
image: busybox:1.36
command: ["sh", "-c", "echo Performing nightly cleanup at $(date); sleep 5; echo Cleanup finished."]
restartPolicy: OnFailure
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
Appliquez-le :
kubectl apply -f /opt/cka_exercises/deploiements/Ex3/cronjob-nightly-cleaner.yaml
5. Vérification des Jobs et Logs du CronJob :
Attendez 1-2 minutes.
echo "kubectl get jobs -n batch-tasks" > /opt/cka_exercises/deploiements/Ex3/cronjob_jobs_list_command.txt
# Exécutez la commande ci-dessus. Vous devriez voir des jobs comme nightly-cleaner-<timestamp>.
# Pour les logs d\'un pod d\'un job créé par le cronjob (prenez le nom d\'un job complété):
# JOB_NAME_CRON=$(kubectl get jobs -n batch-tasks -l cronjob-name=nightly-cleaner -o jsonpath='{.items[0].metadata.name}') # Prend le premier, peut-être pas le dernier complété.
# POD_NAME_CRON=$(kubectl get pods -n batch-tasks -l job-name=$JOB_NAME_CRON -o jsonpath='{.items[0].metadata.name}')
# echo "kubectl logs $POD_NAME_CRON -n batch-tasks" > /opt/cka_exercises/deploiements/Ex3/cronjob_pod_logs_command.txt
echo "JOB_NAME_CRON=\$(kubectl get jobs -n batch-tasks -l cronjob-name=nightly-cleaner --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[-1:].metadata.name}') && POD_NAME_CRON=\$(kubectl get pods -n batch-tasks -l job-name=\$JOB_NAME_CRON -o jsonpath='{.items[0].metadata.name}') && kubectl logs \$POD_NAME_CRON -n batch-tasks" > /opt/cka_exercises/deploiements/Ex3/cronjob_pod_logs_command.txt
# Exécutez la commande sauvegardée. Les logs devraient montrer:
# Performing nightly cleanup at [date]
# Cleanup finished.
Commandes de Nettoyage :
kubectl delete namespace batch-tasks
rm -rf /opt/cka_exercises/deploiements/Ex3
Durée estimée : 30 minutes (Optionnel)
Objective: Configure a Horizontal Pod Autoscaler (HPA) to automatically scale a Deployment based on CPU utilization.
Context: Your application experiences variable load, and you want to automatically adjust the number of Pods to maintain performance without over-provisioning.
Note: This exercise requires the Metrics Server to be installed and running in your cluster. If it's not, the HPA won't be able to fetch CPU metrics, and kubectl top pods won't work.
Instructions:
autoscale-test.autoscale-test, deploy the sample PHP-Apache application that is often used for HPA demonstrations. This application consumes CPU when it receives requests.
php-apache-deployregistry.k8s.io/hpa-example (ou k8s.gcr.io/hpa-example si la nouvelle ne fonctionne pas pour vous)requests: cpu: "200m". HPA needs this to calculate utilization percentage./opt/cka_exercises/deploiements/Ex4/deployment-php-apache.yaml.php-apache-deploy Deployment via a ClusterIP Service named php-apache-svc on port 80 in the autoscale-test namespace.
/opt/cka_exercises/deploiements/Ex4/service-php-apache.yaml.php-apache-hpa in autoscale-test.
php-apache-deploy Deployment.minReplicas: 1maxReplicas: 550%./opt/cka_exercises/deploiements/Ex4/hpa-php-apache.yaml.<unknown> or low.
/opt/cka_exercises/deploiements/Ex4/hpa_status_command.txt.php-apache-svc. You can do this by running a temporary Pod that continuously sends requests to the service. For example, using busybox and wget