Durée estimée : 15 minutes
Objective: Create a Pod that uses environment variables from a ConfigMap and defines resource requests and limits.
Context: You need to deploy a simple application Pod that requires some basic configuration and resource allocation.
Instructions:
app-config in the default namespace with the following data:
APP_ENV=developmentDEBUG_MODE=true/opt/cka_exercises/pods_containers/Ex1/configmap-app-config.yaml and apply it.my-app-pod in the default namespace.
app-container using the image busybox:1.36.sh -c "echo Environment: $MY_APP_ENV, Debug: $MY_DEBUG_MODE; sleep 3600".MY_APP_ENV in the container should get its value from the APP_ENV key in the app-config ConfigMap.MY_DEBUG_MODE in the container should get its value from the DEBUG_MODE key in the app-config ConfigMap.app-container should have the following resource settings:
cpu: "50m", memory: "32Mi"cpu: "100m", memory: "64Mi"restartPolicy to Never./opt/cka_exercises/pods_containers/Ex1/pod-my-app-pod.yaml and apply it./opt/cka_exercises/pods_containers/Ex1/pod_logs.txt./opt/cka_exercises/pods_containers/Ex1/pod_qos_class.txt. (Manually identify the QoS class from the describe output and write it to the file).1. Création du ConfigMap app-config:
Impérative : kubectl create configmap app-config --from-literal=APP_ENV=development --from-literal=DEBUG_MODE=true --dry-run=client -o yaml
Fichier /opt/cka_exercises/pods_containers/Ex1/configmap-app-config.yaml:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: default
data:
APP_ENV: development
DEBUG_MODE: "true"
Appliquez-le :
mkdir -p /opt/cka_exercises/pods_containers/Ex1
kubectl apply -f /opt/cka_exercises/pods_containers/Ex1/configmap-app-config.yaml
2. Création du Pod my-app-pod:
Impérative (sans l'association configmap) : kubectl run my-app-pod --image=busybox:1.36 --dry-run=client -o yaml --command -- sh -c "echo Environment: \$MY_APP_ENV, Debug: \$MY_DEBUG_MODE; sleep 3600"
Fichier /opt/cka_exercises/pods_containers/Ex1/pod-my-app-pod.yaml:
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
namespace: default
spec:
restartPolicy: Never
containers:
- name: app-container
image: busybox:1.36
command: ["sh", "-c", "echo Environment: $MY_APP_ENV, Debug: $MY_DEBUG_MODE; sleep 3600"]
env:
- name: MY_APP_ENV
valueFrom:
configMapKeyRef:
name: app-config
key: APP_ENV
- name: MY_DEBUG_MODE
valueFrom:
configMapKeyRef:
name: app-config
key: DEBUG_MODE
resources:
requests:
cpu: "50m"
memory: "32Mi"
limits:
cpu: "100m"
memory: "64Mi"
Appliquez-le :
kubectl apply -f /opt/cka_exercises/pods_containers/Ex1/pod-my-app-pod.yaml
3. Vérification des logs du Pod :
Attendez que le Pod soit complété (ou en cours d'exécution si sleep est long) :
# kubectl get pod my-app-pod -w
kubectl logs my-app-pod > /opt/cka_exercises/pods_containers/Ex1/pod_logs.txt
# Contenu attendu dans pod_logs.txt (ou similaire) :
# Environment: development, Debug: true
4. Identification de la classe QoS du Pod :
Décrivez le Pod :
kubectl describe pod my-app-pod
Cherchez la section QoS Class dans la sortie. Elle devrait être Burstable parce que les requests et limits sont définis mais ne sont pas égaux pour toutes les ressources.
Sauvegardez la classe QoS dans le fichier :
echo "Burstable" > /opt/cka_exercises/pods_containers/Ex1/pod_qos_class.txt
Durée estimée : 25 minutes
Objective: Configure a Pod with liveness and readiness probes to ensure application health and readiness for traffic, and observe probe failure.
Context: You are deploying a web server application and need to configure Kubernetes to monitor its health and manage its readiness state.
Instructions:
healthy-web-app in the default namespace.
web-server using the image nginx:1.29 (which serves content on port 80 by default)./ on port 80.initialDelaySeconds: 10periodSeconds: 5failureThreshold: 2/ on port 80.initialDelaySeconds: 5periodSeconds: 3successThreshold: 1failureThreshold: 1/opt/cka_exercises/pods_containers/Ex2/pod-healthy-web-app.yaml and apply it.kubectl describe pod healthy-web-app to /opt/cka_exercises/pods_containers/Ex2/pod_description.txt.healthy-web-app Pod's liveness probe to point to a non-existent path, e.g., /nonexistent-healthz./opt/cka_exercises/pods_containers/Ex2/edit_liveness_probe_command.txt.kubectl describe pod healthy-web-app. Note how many times it restarts due to liveness probe failures. Store your observations in /opt/cka_exercises/pods_containers/Ex2/liveness_failure_observation.txt.1. Création du Pod healthy-web-app avec les sondes :
Solution impérative innefficace pour cette question. Créer le yaml du pod puis y ajouter les probes.
Fichier /opt/cka_exercises/pods_containers/Ex2/pod-healthy-web-app.yaml:
apiVersion: v1
kind: Pod
metadata:
name: healthy-web-app
namespace: default
spec:
containers:
- name: web-server
image: nginx:1.29
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 2
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 3
successThreshold: 1
failureThreshold: 1
Appliquez-le :
mkdir -p /opt/cka_exercises/pods_containers/Ex2
kubectl apply -f /opt/cka_exercises/pods_containers/Ex2/pod-healthy-web-app.yaml
2. Vérification du statut et des événements du Pod :
Attendez environ 30 secondes pour que les sondes aient eu le temps de s'exécuter plusieurs fois :
kubectl describe pod healthy-web-app > /opt/cka_exercises/pods_containers/Ex2/pod_description.txt
# Vous pouvez ensuite inspecter le fichier pod_description.txt.
# Recherchez les sections 'Liveness probe' et 'Readiness probe' ainsi que la section 'Events'.
# Vous devriez voir que les sondes réussissent et que le Pod est marqué comme 'Ready'.
3. Simulation d'un échec de la sonde Liveness :
Une façon de le faire est d'éditer le Pod en direct (pour un test rapide) ou de modifier le YAML et de réappliquer.
Option 1: Édition en direct (pour l'exercice)
echo "kubectl edit pod healthy-web-app # Puis manuellement changer livenessProbe.httpGet.path en /nonexistent-healthz" > /opt/cka_exercises/pods_containers/Ex2/edit_liveness_probe_command.txt
# Commande à exécuter :
# kubectl edit pod healthy-web-app
# Trouvez la section livenessProbe et changez `path: /` en `path: /nonexistent-healthz`.
# Sauvegardez et quittez l'éditeur.
Option 2: Modifier le YAML et réappliquer (plus propre pour la gestion de la configuration)
Créez un fichier /opt/cka_exercises/pods_containers/Ex2/pod-unhealthy-liveness.yaml avec le path modifié :
apiVersion: v1
kind: Pod
metadata:
name: healthy-web-app # Important: Garder le même nom pour mettre à jour
namespace: default
spec:
containers:
- name: web-server
image: nginx:1.29
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /nonexistent-healthz # <- CHANGEMENT ICI
port: 80
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 2
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 3
successThreshold: 1
failureThreshold: 1
# Sauvegarder la commande d'application du YAML modifié :
echo "kubectl apply -f /opt/cka_exercises/pods_containers/Ex2/pod-unhealthy-liveness.yaml # (après avoir créé ce fichier avec le path de la liveness probe modifié)" >> /opt/cka_exercises/pods_containers/Ex2/edit_liveness_probe_command.txt
# Exécutez kubectl apply -f /opt/cka_exercises/pods_containers/Ex2/pod-unhealthy-liveness.yaml (si vous choisissez cette option)
Après avoir appliqué la modification, observez le Pod :
# Utilisez watch pour observer les changements ou exécutez describe plusieurs fois
# watch kubectl describe pod healthy-web-app
(sleep 60; kubectl describe pod healthy-web-app) > /opt/cka_exercises/pods_containers/Ex2/liveness_failure_observation.txt
# Laissez-lui un peu de temps pour que les échecs de la liveness probe se produisent et que les redémarrages aient lieu.
# Dans liveness_failure_observation.txt, vous devriez noter :
# - Augmentation du compteur de RESTARTS pour le container.
# - Événements (Events) indiquant "Liveness probe failed... HTTP probe failed with statuscode: 404" ou similaire.
# - Le Pod sera tué et recréé par le Kubelet après failureThreshold (2) échecs consécutifs.
Durée estimée : 25 minutes
Objective: Create a multi-container Pod where an init container prepares data for an application container, and another sidecar container reads from a shared volume written to by the application container.
Context: An application writes logs to a file, and a sidecar container needs to process these logs. An init container is also required to set up some initial configuration or delay application startup.
Instructions:
complex-app-pod in the default namespace.
emptyDir volume named shared-data.init-myservicebusybox:1.36sh -c "echo Initial setup complete; sleep 15"app-mainbusybox:1.36sh -c "i=0; while true; do echo App log line $i >> /app/logs/app.log; i=$((i+1)); sleep 5; done"shared-data volume at /app/logs.log-processorbusybox:1.36sh -c "tail -f /app/data/app.log"shared-data volume at /app/data./opt/cka_exercises/pods_containers/Ex3/pod-complex-app.yaml and apply it.init-myservice container (it will likely be completed). Store the output in /opt/cka_exercises/pods_containers/Ex3/init_container_logs.txt.log-processor sidecar container. You should see the log lines written by app-main. Store a sample of these logs (e.g., the first 5-10 lines after it starts streaming) in /opt/cka_exercises/pods_containers/Ex3/sidecar_logs.txt.1. Création du Pod complex-app-pod:
Impérative : N/A
Fichier /opt/cka_exercises/pods_containers/Ex3/pod-complex-app.yaml:
apiVersion: v1
kind: Pod
metadata:
labels:
run: complex-app-pod
name: complex-app-pod
namespace: default
spec:
initContainers:
- name: init-myservice
image: busybox:1.36
command: ["sh", "-c", "echo Initial setup complete; sleep 15"]
containers:
- image: busybox:1.36
name: app-main
command: ["sh", "-c", "i=0; while true; do echo App log line $i >> /app/logs/app.log; i=$((i+1)); sleep 5; done"]
volumeMounts:
- name: shared-data
mountPath: /app/logs
- name: log-processor
image: busybox:1.36
command: ["sh", "-c", "tail -f /app/data/app.log"]
volumeMounts:
- name: shared-data
mountPath: /app/data
dnsPolicy: ClusterFirst
restartPolicy: Always
volumes:
- name: shared-data
emptyDir: {}
Appliquez-le :
mkdir -p /opt/cka_exercises/pods_containers/Ex3
kubectl apply -f /opt/cka_exercises/pods_containers/Ex3/pod-complex-app.yaml
2. Vérification des logs du container Init :
Attendez que le Pod passe l'étape d'initialisation :
# kubectl get pod complex-app-pod -w
# L'Init Container s'exécute en premier. Une fois terminé, le pod passe à l'exécution des containers principaux.
kubectl logs complex-app-pod -c init-myservice > /opt/cka_exercises/pods_containers/Ex3/init_container_logs.txt
# Contenu attendu dans init_container_logs.txt :
# Initial setup complete
3. Vérification des logs du container Sidecar :
Une fois que le Pod est en cours d'exécution (Running) et que le container app-main a eu le temps d'écrire quelques lignes :
kubectl logs complex-app-pod -c log-processor -f > /opt/cka_exercises/pods_containers/Ex3/sidecar_logs.txt &
# Laissez tourner pendant 10-15 secondes puis terminez la commande (Ctrl+C)
# Alternative pour prendre les premières lignes après un délai:
# sleep 15 # Attendre que des logs soient générés
# kubectl logs complex-app-pod -c log-processor --tail=10 > /opt/cka_exercises/pods_containers/Ex3/sidecar_logs.txt
# Le fichier sidecar_logs.txt devrait contenir des lignes comme :
# App log line 0
# App log line 1
# ...
Durée estimée : 25 minutes (Optionnel ou focus sur les concepts de base de Security Context si le temps est limité)
Objective: Create a Pod that utilizes Security Context to run as a non-root user and Downward API to expose Pod metadata as environment variables and files.
Context: You are deploying an application that needs to be aware of its own metadata (like name, IP, labels) and must run with specific user/group IDs for security reasons.
Instructions:
secure-metadata-pod in the default namespace.
runAsUser: 1001runAsGroup: 2002fsGroup: 3003main-app
busybox:1.36sh -c "echo UID is $(id -u), GID is $(id -g); echo Pod Name: $MY_POD_NAME, Pod IP: $MY_POD_IP; ls -l /etc/podinfo; cat /etc/podinfo/mylabels; sleep 3600"MY_POD_NAME from metadata.nameMY_POD_IP from status.podIPdownwardAPI volume named podinfo-vol at /etc/podinfo.metadata.labels as a file named mylabels.spec.nodeName as a file named mynodename.app=secure-app and environment=prod./opt/cka_exercises/pods_containers/Ex4/pod-secure-metadata.yaml and apply it./opt/cka_exercises/pods_containers/Ex4/pod_output.txt. The logs should show the UID/GID, Pod name, IP, and the content of the mylabels file.1. Création du Pod secure-metadata-pod:
Impérative : N/A
Fichier /opt/cka_exercises/pods_containers/Ex4/pod-secure-metadata.yaml:
apiVersion: v1
kind: Pod
metadata:
name: secure-metadata-pod
namespace: default
labels:
app: secure-app
environment: prod
spec:
securityContext:
runAsUser: 1001
runAsGroup: 2002
fsGroup: 3003
containers:
- name: main-app
image: busybox:1.36
command: ["sh", "-c", "echo UID is $(id -u), GID is $(id -g); echo Pod Name: $MY_POD_NAME, Pod IP: $MY_POD_IP, Node: $NODE_NAME; ls -l /etc/podinfo; echo Contents of /etc/podinfo/mylabels:; cat /etc/podinfo/mylabels; echo Contents of /etc/podinfo/mynodename:; cat /etc/podinfo/mynodename; sleep 3600"]
env:
- name: MY_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
volumeMounts:
- name: podinfo-vol
mountPath: /etc/podinfo
volumes:
- name: podinfo-vol
downwardAPI:
items:
- path: "mylabels"
fieldRef:
fieldPath: metadata.labels
- path: "mynodename"
fieldRef:
fieldPath: metadata.namespace
Appliquez-le :
mkdir -p /opt/cka_exercises/pods_containers/Ex4
kubectl apply -f /opt/cka_exercises/pods_containers/Ex4/pod-secure-metadata.yaml
2. Vérification des logs du Pod :
Attendez que le Pod soit en cours d'exécution (Running) :
# kubectl get pod secure-metadata-pod -w
kubectl logs secure-metadata-pod > /opt/cka_exercises/pods_containers/Ex4/pod_output.txt
# Le fichier pod_output.txt devrait contenir des informations similaires à :
# UID is 1001, GID is 2002
# Pod Name: secure-metadata-pod, Pod IP: <pod_ip_address>
# total 8
# ... (ls -l output for /etc/podinfo showing mylabels and mynodename)
# Contents of /etc/podinfo/mylabels:
# app="secure-app"
# environment="prod"
# Contents of /etc/podinfo/mynodename:
# <node_name_where_pod_is_scheduled>
(Note : La sortie exacte de ls -l et l'IP du pod varieront. Le fsGroup assure que le volume monté /etc/podinfo est accessible par le GID 3003. Les fichiers mylabels et mynodename seront créés avec cet GID.)