Comment obtenir la CKA ?

Qu’est-ce que cette certification ?

#

La Certified Kubernetes Administrator (CKA) est une certification Kubernetes qui se concentre essentiellement sur la partie administration et configuration d’un cluster ainsi que l’ensemble des briques qui permettent de rendre accessibles des services de l’extérieur, de gérer le stockage persistant et d’autres domaines qui seront abordés plus bas.

Elle se compose de 15 à 20 questions plus ou moins longues et avec un poids différent, qui est généralement indiqué sous forme de pourcentage. Ces questions sont à réaliser en moins de deux heures.

Pour ma part, j’ai eu 17 questions que j’ai trouvées de difficulté moyenne avec quelques-unes un peu déroutantes. Côté temps, il me restait environ une bonne trentaine de minutes avant que l’examen ne prenne fin.

Dans cet article, l’objectif est de vous présenter le contenu de l’examen via les domaines traités et de vous partager l’ensemble des astuces et remarques qui m’ont permis de l’obtenir, mais aussi de la renouveler deux fois.

Domaines évalués

#

La Cloud Native Computing Foundation (CNCF), qui s’occupe du programme de l’examen, a open sourcé l’ensemble des curriculums au sein d’un repo GitHub.

Dans le dernier programme en v1.35 en date, on retrouve :

• Cluster Architecture, Installation & Configuration (25%) : Une des plus grosses parties de l’examen qui se concentre principalement sur l’utilisation de kubeadm pour ajouter un nœud ou mettre à jour un cluster (Control Plane et Workers). Sans oublier tout ce qui se rapproche de près ou de loin de l’initialisation d’un cluster avec la mise en place d’un CNI (Container Network Interface), CSI (Container Storage Interface) ou encore CRI (Container Runtime Interface) comme Containerd. Cela inclut également la gestion de la sécurité des rôles avec le RBAC, la haute disponibilité (HA) du cluster, ainsi que la sauvegarde et la restauration de la base de données critique etcd.

• Workloads & Scheduling (15%) : Mise en place de Deployment, ou encore StatefulSet, et gestion de la planification des Pods sur des nœuds particuliers en jouant avec les taints, tolerations, affinity (node et Pod), nodeSelector, ainsi que la définition des resources (requests et limits) sans oublier la configuration d’applications via les ConfigMaps et les Secrets. Nouveauté intéressante : l’ajout de l’HorizontalPodAutoscaler (HPA) pour la mise à l’échelle automatique.

• Services & Networking (20%) : Cette partie évalue votre capacité à exposer vos applications et à sécuriser leurs flux de communication. Elle se concentre sur la création et la configuration des différents types de Service (ClusterIP, NodePort, LoadBalancer), la mise en place de règles de routage applicatif HTTP/HTTPS via l’Ingress (et son contrôleur), ainsi que le paramétrage de l’isolement réseau grâce aux NetworkPolicy (ingress/egress). La Gateway et les HTTPRoute font leur arrivée dans l’examen en complément de l’Ingress déjà évoqué.

• Storage (10%) : La gestion des données persistantes dans Kubernetes, petit chapitre mais à ne pas négliger. Au programme : la création de PersistentVolumes (PV) et de PersistentVolumeClaims (PVC), créer et déployer des configurations de stockage à l’aide des StorageClasses, et savoir configurer correctement les volumes au sein des Pods.

• Troubleshooting (30%) : Le bloc le plus lourd en termes de points, exigeant une méthodologie pour diagnostiquer et réparer un cluster en panne. Il s’agit de savoir debug un composant système défaillant (comme l’API Server, le Scheduler ou le Controller Manager), relancer ou configurer le kubelet planté sur un nœud, analyser les logs d’un conteneur, évaluer les coupures de connectivité (Pods/Services) et surveiller la saturation des ressources (CPU/Mémoire) du cluster, etc.

Comme vous pouvez le voir, la CKA se concentre sur une grosse partie administration d’un cluster et la résolution des soucis de configuration.

De plus, des connaissances sur Linux sont un gros plus, notamment pour être à l’aise avec l’installation de paquets sur Ubuntu (apt-get ou dpkg) ou piloter kubeadm avec la ligne de commande.

Car oui, Ubuntu 24.04 LTS est le système d’exploitation de référence et Kubeadm la distribution officielle de l’examen.

Il faut tout de même garder à l’esprit que la création d’objets basiques (Pod, Service, etc.) est requise dans cette certification.

Est-ce que cela vaut encore le coup ?

#

Ayant maintenant plusieurs années d’expérience dans l’univers Kubernetes ainsi que dans l’écosystème CNCF, je me suis posé la question de la renouveler une deuxième fois.

Hormis la perte de mon prestigieux titre Kubestronaut, eh oui ! Cette question reste légitime… En effet, je ne fais plus réellement de YAML pur, ni d’exécution de kubectl car le GitOps a pris beaucoup de terrain.

Néanmoins, il est toujours bon, de mon point de vue, de rester aligné avec les bases de Kubernetes. Et pour cause, la certification a bien évolué si je la compare à la première version que j’ai pratiquée cinq ans en arrière.

Pour moi, c’est une sorte de veille technologique pour rester familier aux concepts de base mais peut-être aussi pour en découvrir ou en manipuler de nouveaux ?

L’exemple est le “véritable” conteneur sidecar que je n’ai pas encore eu l’occasion d’expérimenter grandeur nature. Plusieurs labs m’ont permis de mettre la main dessus et de comprendre les avantages mais aussi les limites.

De plus, certains scénarios sont assez proches de la réalité : même si mes clusters Kubernetes persos et pros ne sont ni sur Ubuntu, ni sur kubeadm, le fait de comprendre comment troubleshooter et avoir les bons réflexes peut toujours aider.

Autre cas : la migration de l’Ingress vers l’HTTPRoute, la Gateway API prend de l’ampleur et cela se ressent. Un bon moyen d’éveiller les consciences sur la facilité de migration.

Vous l’aurez compris, pour moi, c’est un grand oui ! Ces examens pratiques ont une réelle valeur ajoutée qui est indiscutable dans des rôles où l’on met les mains dans le cambouis.

La CKA avant la CKAD ?

#

Beaucoup de personnes se posent la question : faut-il passer la CKA ou la CKAD en premier ?

Pour ma part, le choix est clair : il vaut mieux commencer par la CKAD.

Pourquoi ? Tout simplement parce que la CKAD (Certified Kubernetes Application Developer) se concentre essentiellement sur la création et la gestion des objets au sein d’un cluster existant.

Elle est beaucoup plus accessible et facile à appréhender au premier abord. En gros, si la CKAD apprend à conduire la voiture, la CKA demande d’ouvrir le capot pour réparer le moteur. La CKA regroupe une bonne partie des concepts de la CKAD, mais en y ajoutant toute la couche d’administration pure : l’installation du cluster, la gestion des nœuds, le troubleshooting réseau ou la maintenance des composants système.

Néanmoins, l’avantage en commençant par la CKA, c’est qu’une fois celle-ci en poche, la CKAD deviendra une simple formalité. Il est donc tout à fait possible de tenter la CKA en premier pour les profils plus aguerris, pour ceux qui ont déjà une bonne expérience sur Kubernetes et son écosystème.

À chacun de voir comment aborder les choses selon son propre profil.

Place maintenant aux ressources utilisées pour réussir cette certification.

Les ressources utilisées

#

Pour apprendre et balayer l’ensemble des domaines de la CKA, je vous conseille la formation Udemy de Mumshad Mannambeth. Elle est fournie avec les labs interactifs de sa plateforme KodeKloud, ce qui permet de pratiquer directement chaque chapitre. Je vous conseille de faire et refaire les labs : c’est là que vous allez commencer à retenir les commandes kubectl et la méthode pour diagnostiquer les problèmes.

Après avoir terminé cette formation et en ayant au préalable acheté votre certification sur le site de la Linux Foundation, vous aurez droit à deux accès gratuits au simulateur killer.sh.

Il est réputé pour être bien plus difficile, plus long et plus stressant que l’examen final (comptez environ 20 questions bien denses).

Si vous finissez par obtenir plus de 66% de manière autonome, vous pouvez être vraiment confiant pour votre examen.

Néanmoins, pas de panique si vous ratez votre premier essai, chaque session de killer.sh reste active pendant 36 heures dès son initialisation.

Une fois votre session terminée et le score évalué, profitez du temps restant : étudiez les corrections détaillées fournies par le site, puis faites et refaites les exercices donnés via le simulateur pour entraîner vos points faibles et gagner en rapidité.

Les domaines à connaître

#

Cette section regroupe les liens vers la documentation officielle, les commandes indispensables et les réflexes à acquérir pour optimiser le temps le jour de l’examen.

Pour compléter ces astuces, la lecture de l’article sur la CKAD reste fortement recommandée, de nombreuses bases communes n’étant pas dupliquées ici.

Une règle d’or avant de toucher à la configuration du cluster : toujours sauvegarder les fichiers d’origine. Une mauvaise manipulation sur un composant critique peut rapidement bloquer ou casser tout l’environnement.

Cas du kubelet :

cp /etc/default/kubelet ~/kubelet.bak
# Ou pour le fichier de conf
cp /var/lib/kubelet/config.yaml ~/kubelet-config.yaml.bak

Mettre à jour un cluster avec Kubeadm

#

C’est le gros morceau de l’examen, vous ne pourrez pas y échapper !

Vous devez mettre à jour le Control Plane puis les Workers, un par un. La documentation détaille chaque étape.

Pour cette étape, deux commandes Linux vous aideront énormément :

• apt-cache madison : Elle permet de lister toutes les versions exactes d’un paquet disponibles dans les dépôts. C’est un moyen fiable d’obtenir le tag de version précis (comme 1.35.0-1.1) requis par la commande apt-get install ;

• apt-mark hold / unhold : Par sécurité, il est préférable de bloquer les versions de Kubernetes pour ne pas les embarquer avec les mises à jour du système, c’est ce que fait hold. Quant à unhold, il permet au paquet d’être mis à jour.

Sur le nœud Control Plane :

# Débloquer les paquets pour la mise à jour
apt-mark unhold kubeadm

# Trouver la version exacte du paquet disponible (par exemple 1.35.0-1.1)
apt-cache madison kubeadm | grep 1.35

# Mettre à jour kubeadm avec la version trouvée
apt-get update
apt-get install -y kubeadm=1.35.0-1.1

# Vérifier le plan de mise à jour et l'appliquer
kubeadm upgrade plan
kubeadm upgrade apply v1.35.0

# Mettre à jour kubectl et kubelet
apt-mark unhold kubelet kubectl
apt-get install -y kubelet=1.35.0-1.1 kubectl=1.35.0-1.1
apt-mark hold kubeadm kubelet kubectl

# Relancer le kubelet
systemctl daemon-reload
systemctl restart kubelet

Pour les Workers :

# Depuis le control Plane, drainer le nœud
kubectl drain node01 --ignore-daemonsets --delete-emptydir-data

# Sur le worker (node01), mettre à jour kubeadm et lancer l'upgrade
apt-mark unhold kubeadm
apt-get update
apt-get install -y kubeadm=1.35.0-1.1
kubeadm upgrade node

# Mettre à jour kubelet et relancer
apt-mark unhold kubelet
apt-get install -y kubelet=1.35.0-1.1
apt-mark hold kubeadm kubelet
systemctl daemon-reload
systemctl restart kubelet

# Depuis le control plane, rendre le nœud à nouveau disponible
kubectl uncordon node01

Sauvegarde et restauration d’etcd

#

Etcd, la base de données du cluster, est un point critique de l’infrastructure Kubernetes. Plusieurs commandes peuvent être effectuées avec etcdctl. Dans la CKA, il est surtout question de backuper ou de restaurer.

La documentation donne les arguments exacts. La première étape consiste à récupérer le chemin des certificats et du port d’etcd dans /etc/kubernetes/manifests/kube-apiserver.yaml.

Une fois les informations obtenues, et pour réaliser un snapshot :

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /tmp/etcd-backup.db # Ou le chemin demandé...

Autre point : la restauration. Celle-ci a souvent lieu dans un autre dossier pour ne pas écraser l’existant en cas d’erreur :

ETCDCTL_API=3 etcdctl --data-dir=/var/lib/etcd-backup \
  snapshot restore /tmp/etcd-backup.db

Ensuite, modifiez le paramètre --data-dir et le volume hostPath associé dans /etc/kubernetes/manifests/etcd.yaml. Cela aura pour conséquence de demander au kubelet de recharger le Pod statique automatiquement.

Gestion des utilisateurs et RBAC

#

On vous demandera de restreindre des accès à l’aide de Role, ClusterRole, RoleBinding et ClusterRoleBinding. Utilisez, de préférence, le mode impératif pour générer vos fichiers rapidement sans ouvrir la documentation.

Voici quelques exemples…

Créer un Role et son Binding dans un namespace :

kubectl -n namespace create role pod-reader --verb=get,list,watch --resource=pods
kubectl -n namespace create rolebinding admin-user-binding --role=pod-reader --user=[email protected]

N’oubliez pas d’utiliser auth can-i pour valider vos réglages :

kubectl -n namespace auth can-i get pods --as=axinorm

Placer des Pods (Taints, Tolerations, Affinity, etc.)

#

Le Scheduler est l’organe de décision du placement des Pods. Néanmoins certains concepts existent pour surcharger le comportement de ce dernier et faire en sorte que vos Pods atterrissent sur les nœuds désirés :

kubectl taint nodes node01 key1=value1:NoSchedule
kubectl taint nodes node01 key1=value1:NoSchedule- # Le moins à la fin supprime la taint

Que ce soit pour ajouter une toleration, un nodeSelector ou une affinity, prenez le temps de générer le YAML du pod et complétez la section spec en vous basant sur la documentation.

Exemple d’une affinité sur les labels d’un nœud :

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/region
            operator: In
            values:
            - switzerland

NetworkPolicy

#

La NetworkPolicy est un objet incontournable pour sécuriser les communications entre vos Pods. La documentation fournit un bon squelette de l’objet, prêt à l’emploi.

Exemple pour isoler un backend afin qu’il ne reçoive du trafic que depuis le frontend sur le port 80 :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

Stockage persistant

#

Ah le stockage… plein de ressources à créer et d’éléments à ajouter dans un Pod.

Un point important : les éléments d’un PersistentVolumeClaim (PVC) doivent correspondre aux critères du PersistentVolume (PV) (capacité, mode d’accès, StorageClass) pour passer à l’état Bound.

Cette partie de la documentation vous permettra de récupérer l’ensemble des objets à créer, sans oublier de monter votre volume dans un Pod :

spec:
  volumes:
    - name: html
      persistentVolumeClaim:
        claimName: nginx-html
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: html
          mountPath: "/usr/share/nginx/html"

Troubleshooting

#

Si un nœud passe en état NotReady, le problème vient souvent du service kubelet. L’objectif est de trouver la cause avec une première série de commandes, une fois en ssh :

systemctl status kubelet # Voir l'état du service
journalctl -u kubelet    # Consulter les logs

Si le service refuse de démarrer, vérifiez la configuration dans /var/lib/kubelet/config.yaml ou le fichier au sein de systemd.

Si un composant du Control Plane (comme l’API Server) est en panne, inspectez directement les logs des conteneurs sur le nœud cible avec la commande crictl :

crictl ps -a
crictl logs [ID du conteneur]

Autre sujet, si vos Pods n’arrivent plus à communiquer avec vos Services via leur nom, le problème vient sûrement de la résolution DNS interne.

Vérifiez que les Pods CoreDNS s’exécutent correctement :

kubectl get pods -n kube-system -l k8s-app=kube-dns

Puis testez la résolution depuis un Pod de test :

kubectl run -it --rm busybox --image=busybox --restart=Never -- /bin/sh -c "nslookup kubernetes.default"

Si la commande échoue, vérifiez le Service lié à CoreDNS et sa configuration Corefile stockée dans la ConfigMap au sein du namespace kube-system.

Helm

#

L’examen demande de savoir manipuler des packages avec Helm. Pas besoin d’éditer du YAML ici, l’essentiel se passe en ligne de commande pour installer, mettre à jour ou lister des releases dans un namespace spécifique.

Quelques commandes indispensables :

# Ajouter un dépôt de chart et le mettre à jour
helm repo add traefik https://traefik.github.io/charts
helm repo update

# Rechercher un chart disponible
helm search repo traefik

# Installer ou mettre à jour une release dans un namespace
helm -n web install my-traefik traefik/traefik
helm -n web upgrade my-traefik traefik/traefik

# Lister les releases existantes (historique ou statut)
helm -n web list
helm -n web history my-traefik

# Désinstaller une release et nettoyer les ressources
helm -n web uninstall my-traefik

Gateway API (HTTPRoute)

#

La Gateway API représente le futur du routage réseau dans Kubernetes et s’installe de plus en plus dans le contenu de l’examen en remplacement ou complément des Ingress traditionnels. La documentation regorge d’exemples pour lier une Gateway à des objets HTTPRoute.

Le point critique est de s’assurer que l’objet HTTPRoute cible le bon service et la bonne Gateway via la section parentRefs.

Exemple d’un routage HTTP simple vers un service de backend :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: web-app
spec:
  parentRefs:
  - name: prod-gateway # Nom de la Gateway cible
    namespace: infrastructure
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: backend-service
      port: 8080

PriorityClass et Pod Priority

#

Pour gérer l’éviction et l’ordonnancement des Pods lorsque le cluster manque de ressources, Kubernetes utilise le mécanisme de priorité. La documentation montre comment définir l’importance d’une charge de travail.

La première étape consiste à créer un objet PriorityClass avec une valeur numérique (plus la valeur est haute, plus le Pod est prioritaire) :

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-apps
value: 1000000
globalDefault: false
description: "Priority class for critical production components"

Une fois l’objet créé au sein du cluster, il suffit d’assigner cette priorité dans la configuration de votre Pod en complétant la section spec :

spec:
  priorityClassName: high-priority-apps
  containers:
  - name: nginx
    image: nginx

Si le cluster s’effondre par manque de CPU ou de mémoire, le Scheduler supprimera (préemption) les Pods avec une priorité plus faible pour faire de la place à celui-ci.

Et pour finir, est-ce une certification facile ou pas ?

#

Je trouve que la difficulté de la CKA ne réside pas dans le temps nécessaire pour compléter l’ensemble des questions comme la CKAD, mais plutôt dans le très (très) large périmètre de cette certification.

En effet, beaucoup de domaines sont traités, et si vous débutez dans l’univers Kubernetes, il est possible que cette certification soit dure à appréhender. C’est pourquoi, il faudra peut-être préférer l’étape du dessous : la CKAD.

Comme vous avez pu le constater, le public visé n’est pas le même non plus, ici on parle de notions d’administration : des connaissances sur l’installation, la mise à jour des machines, le fonctionnement du réseau et des certificats.

Bonne chance à celles et ceux qui souhaitent passer cette certification !