Réussir le CKA : Préparer la Certification Kubernetes Administrator

Le CKA (Certified Kubernetes Administrator) est l'une des certifications techniques les plus exigeantes et les plus respectées dans le monde des infrastructures cloud-native. Contrairement aux certifications QCM classiques, le CKA est un examen 100 % pratique : vous avez 2 heures pour résoudre des tâches d'administration Kubernetes dans un vrai cluster, en ligne de commande. Ce guide vous prépare à relever ce défi.

Présentation de l'examen CKA

Développé par la CNCF (Cloud Native Computing Foundation) en partenariat avec la Linux Foundation, le CKA valide votre capacité à administrer un cluster Kubernetes en production.

Les domaines de l'examen (pondération approximative) :

• Stockage — 10 %
• Troubleshooting — 30 %
• Workloads et scheduling — 15 %
• Architecture du cluster, installation et configuration — 25 %
• Services et Networking — 20 %

Maîtriser kubectl : la base de tout

Pendant l'examen, vous vivrez dans le terminal. La rapidité d'exécution des commandes kubectl est un facteur critique. Voici les commandes essentielles à maîtriser :

Commandes de base

# Lister les ressources
kubectl get pods -n kube-system
kubectl get all --all-namespaces
kubectl get nodes -o wide

# Décrire une ressource (diagnostic)
kubectl describe pod <nom-pod> -n <namespace>

# Afficher les logs
kubectl logs <nom-pod> --previous
kubectl logs <nom-pod> -c <container>

# Accéder à un conteneur
kubectl exec -it <nom-pod> -- /bin/bash

# Supprimer rapidement (sans attendre la terminaison)
kubectl delete pod <nom> --force --grace-period=0

Génération de YAML avec --dry-run

Générer des manifestes YAML plutôt que de les écrire de zéro vous fait gagner un temps précieux :

# Générer un pod YAML sans le créer
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

# Générer un deployment
kubectl create deployment myapp --image=nginx --replicas=3 \
  --dry-run=client -o yaml > deploy.yaml

# Générer un service
kubectl expose deployment myapp --port=80 --type=ClusterIP \
  --dry-run=client -o yaml > svc.yaml

alias k=kubectl
source <(kubectl completion bash)
complete -F __start_kubectl k

Workloads : Pods, Deployments, Services

Pods et conteneurs

Les concepts à maîtriser sur les pods :

• Static Pods : définis directement dans /etc/kubernetes/manifests/, gérés par le kubelet sans le contrôleur
• Init Containers : s'exécutent avant le conteneur principal, utiles pour l'initialisation
• Sidecars : conteneurs auxiliaires dans le même pod (logs, proxy)
• Resource requests et limits : cpu et memory pour garantir la qualité de service
• Probes : livenessProbe, readinessProbe, startupProbe pour la santé des conteneurs

Deployments et mises à jour

• Stratégies de déploiement : RollingUpdate (par défaut) et Recreate
• Rollback : kubectl rollout undo deployment/myapp
• Scaling : kubectl scale deployment myapp --replicas=5

Services

• ClusterIP : accessible uniquement à l'intérieur du cluster (par défaut)
• NodePort : expose le service sur chaque nœud sur un port statique (30000-32767)
• LoadBalancer : provisionne un load balancer cloud externe
• Ingress : routage HTTP/HTTPS vers plusieurs services via un contrôleur Ingress

RBAC et sécurité Kubernetes

Le RBAC (Role-Based Access Control) est fréquemment testé dans le CKA.

Les objets RBAC

• Role : permissions dans un namespace spécifique
• ClusterRole : permissions à l'échelle du cluster
• RoleBinding : associe un Role à un utilisateur/groupe/ServiceAccount dans un namespace
• ClusterRoleBinding : associe un ClusterRole à l'échelle du cluster

# Créer un role permettant de lire les pods
kubectl create role pod-reader \
  --verb=get,list,watch \
  --resource=pods \
  -n default

# Attacher ce role à un utilisateur
kubectl create rolebinding read-pods \
  --role=pod-reader \
  --user=alice \
  -n default

# Vérifier les permissions
kubectl auth can-i list pods --as=alice -n default

ServiceAccounts

Les ServiceAccounts permettent aux pods d'interagir avec l'API Kubernetes. Associez toujours des ServiceAccounts dédiés avec des permissions minimales plutôt que d'utiliser le compte par défaut.

Networking dans Kubernetes

DNS interne

CoreDNS résout automatiquement les noms de service dans le cluster :

• Service dans le même namespace : mon-service
• Service dans un autre namespace : mon-service.autre-namespace
• FQDN complet : mon-service.namespace.svc.cluster.local

NetworkPolicies

Les NetworkPolicies contrôlent le trafic entre pods. Elles nécessitent un plugin réseau compatible (Calico, Cilium, Weave). Points clés pour l'examen :

• Par défaut, tous les pods communiquent librement entre eux
• Une NetworkPolicy en Ingress contrôle qui peut atteindre vos pods
• Une NetworkPolicy en Egress contrôle où vos pods peuvent se connecter
• Un pod sans NetworkPolicy est totalement ouvert

Stockage persistant

PersistentVolumes et PersistentVolumeClaims

• PersistentVolume (PV) : ressource de stockage provisionnée par un administrateur ou dynamiquement via une StorageClass
• PersistentVolumeClaim (PVC) : demande de stockage faite par un pod
• StorageClass : définit le type de stockage et le provisionneur dynamique

Modes d'accès importants :

• ReadWriteOnce (RWO) : un seul nœud peut monter le volume en lecture-écriture
• ReadOnlyMany (ROX) : plusieurs nœuds en lecture seule
• ReadWriteMany (RWX) : plusieurs nœuds en lecture-écriture (NFS, CephFS)

Troubleshooting du cluster

Avec 30 % des points, le troubleshooting doit être une priorité absolue. Apprenez une méthode systématique :

Pod en erreur : diagnostic

# Étape 1 : voir l'état du pod
kubectl get pod <nom> -o wide

# Étape 2 : lire les événements
kubectl describe pod <nom>

# Étape 3 : logs du conteneur actuel
kubectl logs <nom>

# Étape 4 : logs du conteneur précédent (après crash)
kubectl logs <nom> --previous

Nœud Not Ready

# Vérifier l'état des nœuds
kubectl get nodes
kubectl describe node <nom-noeud>

# Se connecter au nœud et vérifier kubelet
systemctl status kubelet
journalctl -u kubelet -n 50

Problèmes réseau entre pods

# Tester la connectivité depuis un pod temporaire
kubectl run test --image=busybox --rm -it -- wget -O- http://mon-service:80

# Vérifier les endpoints d'un service
kubectl get endpoints mon-service

Stratégie de préparation

La pratique intensive est la seule voie pour réussir le CKA. Comptez 8 à 12 semaines si vous débutez avec Kubernetes, 4 à 6 semaines avec une expérience préalable.

Conseils spécifiques pour le jour de l'examen

• Configurez vos alias et l'autocomplétion dès le début de l'examen
• Notez le contexte kubectl de chaque tâche : chaque question peut pointer vers un cluster différent (kubectl config use-context <cluster>)
• Utilisez --dry-run=client -o yaml pour générer vos manifestes rapidement
• La documentation kubernetes.io est autorisée : préparez vos favoris (RBAC, NetworkPolicy, PV/PVC)
• Attaquez les tâches les plus faciles en premier pour sécuriser les points
• Ne passez pas plus de 5-6 minutes sur une tâche difficile ; passez à la suivante et revenez-y

Conclusion

Le CKA est une certification qui récompense vraiment la pratique. Il ne s'agit pas de mémoriser des réponses mais de démontrer une maîtrise opérationnelle réelle de Kubernetes. Chaque heure passée dans un terminal vaut plus que plusieurs heures de lecture. Avec une préparation rigoureuse et des entraînements intensifs, le badge CKA est à votre portée — et il ouvrira de nombreuses portes dans le monde DevOps et cloud-native.