Préparation à la CKA - 02 - Pod

Avant-propos

Bonjour à tous les curieux de Kubernetes,

Cet article est le premier d’une longue série qui aura pour but d’apprendre et de comprendre comment fonctionne Kubernetes, et qui permet de préparer la CKA.

La certification CKA (Certified Kubernetes Administrator) teste la capacité des administrateurs à :

• Installer et configurer un cluster Kubernetes :

  • Comprendre les différentes architectures de cluster.
  • Installer Kubernetes sur des machines physiques ou virtuelles.

• Gérer les applications :

  • Déployer, mettre à l’échelle et gérer des applications conteneurisées.
  • Utiliser des objets Kubernetes tels que Pods, Deployments et Services.

• Surveiller et dépanner :

  • Utiliser des outils de surveillance pour suivre les performances des applications et du cluster.
  • Diagnostiquer et résoudre des problèmes liés aux applications et au cluster.

• Sécuriser le cluster :

  • Mettre en œuvre des pratiques de sécurité pour protéger le cluster et les applications.
  • Gérer les accès et les autorisations.

• Maintenir le cluster :

  • Effectuer des mises à jour et des sauvegardes.
  • Gérer les ressources et l’intégrité du cluster.

Ce guide est basé sur mon repo de préparation de la CKA que vous pouvez trouver ici : https://github.com/alijahnas/CKA-practice-exercises/

Pendant l’examen de la CKA, vous aurez uniquement accès à la documentation officielle de Kubernetes, disponible à l’adresse suivante : https://kubernetes.io/docs/

Une compétence essentielle est de savoir chercher efficacement dans la documentation officielle, car la plupart des réponses s’y trouvent. L’objectif n’est pas de tout retenir par cœur, mais de savoir où et comment chercher.

Pod

Kubernetes est un orchestrateur de containers, mais l’unité fondamentale qu’il manipule est le Pod. Kubernetes orchestre donc des pods plutôt que des containers directement.

Un pod contient un ou plusieurs containers, auxquels peuvent s’ajouter zéro ou plusieurs volumes.

Cas d’usage typique : Un conteneur par Pod

La majorité du temps, un Pod contient un seul conteneur exécutant un processus applicatif unique. Cette approche s’aligne parfaitement avec l’architecture microservices :

• Isolation : Chaque service est déployé dans son propre Pod
• Mise à l’échelle indépendante : On peut scaler chaque service séparément
• Mises à jour indépendantes : Chaque service peut être mis à jour sans affecter les autres
• Communication réseau : Les services communiquent via le réseau Kubernetes

Pourquoi plusieurs conteneurs dans un même Pod ?

C’est ici que cela devient intéressant ! Parfois, on a besoin de regrouper plusieurs conteneurs dans un même Pod pour qu’ils puissent :

• Communiquer via localhost : Partager le même espace réseau
• Accéder aux mêmes volumes : Traiter les mêmes données partagées
• Avoir un cycle de vie commun : Démarrer et s’arrêter ensemble

Exemples concrets de multi-conteneurs

Un exemple courant est l’utilisation d’un service mesh comme Istio, qui injecte un proxy Envoy dans chaque pod du mesh. Ce container supplémentaire intercepte les flux pour offrir visibilité, sécurité et contrôle.

Un autre cas d’usage concerne les Init container, exécutés avant le container applicatif principal. Ils servent à préparer des fichiers, initialiser un volume ou récupérer des secrets depuis un outil externe comme HashiCorp Vault, avant que l’application ne démarre.

Lancement d’un pod

Voici un exemple de définition de pod :

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: ns-nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
    - containerPort: 80

Explications

• apiVersion : version de l’API Kubernetes utilisée (ex : v1, apps/v1, etc.).
• kind : type d’objet souhaité (ici un Pod).
• metadata : métadonnées associées à l’objet.
• name : nom du pod.
• namespace : espace logique dans lequel le pod sera créé.
• spec : spécification fonctionnelle du pod.
• containers : liste des containers que le pod doit exécuter.
• ports : ports réseaux exposés par le container.

Pour déployer ce pod, on doit d’abord créer le namespace ns-nginx :

$ kubectl create ns ns-nginx

Ensuite, il suffit d’utiliser la commande kubectl apply avec le fichier nginx.yaml, qui contient la description du pod présentée plus haut, afin d’appliquer sa configuration:

$ kubectl apply -f nginx.yaml
pod/nginx created

Si on est assez rapide, on peut voir le pod en train d’être créé :

$ kubectl get pods -n ns-nginx
NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     ContainerCreating   0          2s

$ kubectl get pods -n ns-nginx
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          14s

Le pod a été schédulé sur un des nœuds du cluster. Il tourne bien, mais on ne peut pas en faire grand-chose, car il faudrait pouvoir y accéder depuis notre réseau, configurer le nginx, voir s’il y a besoin d’espace disque, et bien d’autres choses.

Dans les prochains articles, nous découvrirons d’autres ressources Kubernetes essentielles :

• Services : Pour exposer nos applications
• ConfigMaps & Secrets : Pour la configuration
• Volumes : Pour le stockage persistant
• Deployments : Pour gérer les déploiements et les redémarrages

Conclusion

Les Pods sont le cœur de Kubernetes. Comprendre leur fonctionnement - y compris quand utiliser un ou plusieurs conteneurs - est fondamental pour maîtriser l’orchestration de conteneurs et préparer la certification CKA.

Rappel clé : Un Pod = une unité de déploiement, qui peut contenir un ou plusieurs conteneurs étroitement couplés partageant le même cycle de vie.