Aller au contenu principal

Lab 7.4 - Init Containers et Sidecars

Objectifs du Lab​

À la fin de ce lab, vous serez capable de:

  • Comprendre le concept d'Init Container.
  • Créer des Pods avec Init Containers.
  • Utiliser les Init Containers pour la préparation de l'environnement.
  • Comprendre le pattern Sidecar.
  • Implémenter un pattern Sidecar pour le logging.

Durée Estimée​

45-60 minutes

Prérequis​

  • kubectl installé et configuré.
  • Cluster Kubernetes local fonctionnel (minikube ou kind).
  • Connaissances sur les Init Containers et Sidecars (Chapitre 7.4).

Partie 1: Comprendre les Init Containers​

Les Init Containers s'exécutent avant les conteneurs principaux d'un Pod. Ils sont utiles pour:

  • Initialiser des données ou des configurations
  • Attendre que des dépendances soient prêtes
  • Préparer l'environnement avant le démarrage de l'application

Caractéristiques:​

  • S'exécutent séquentiellement (un après l'autre)
  • Doivent tous réussir avant que les conteneurs principaux ne démarrent
  • Ont accès aux mêmes volumes que les conteneurs principaux

Partie 2: Création d'un Pod avec Init Container​

Nous allons créer un Pod avec un Init Container qui prépare des fichiers avant le démarrage de l'application.

Étape 2.1: Créer le Pod avec Init Container​

Créez un fichier pod-init-container.yaml:

# pod-init-container.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  volumes:
  - name: shared-data
    emptyDir: {} # Volume partagé entre Init Container et conteneur principal
  initContainers:
  - name: init-setup
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Init Container: Préparation de l'environnement..."
      echo "Configuration initialisée" > /shared/config.txt
      echo "Données préparées" > /shared/data.txt
      echo "Init Container terminé avec succès"
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  containers:
  - name: app-container
    image: nginx:1.20
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Application: Lecture des fichiers préparés par Init Container"
      cat /shared/config.txt
      cat /shared/data.txt
      echo "Application démarrée"
      nginx -g "daemon off;"
    volumeMounts:
    - name: shared-data
      mountPath: /shared
    ports:
    - containerPort: 80

Explication:

  • L'Init Container prépare des fichiers dans le volume partagé.
  • Le conteneur principal lit ces fichiers après le démarrage.

Appliquez le Pod:

kubectl apply -f pod-init-container.yaml

Étape 2.2: Vérifier l'Exécution​

Vérifiez le statut du Pod:

kubectl get pods app-with-init

Vous devriez voir le Pod passer par les phases:

  1. Init:0/1 (Init Container en cours d'exécution)
  2. PodInitializing
  3. Running (conteneur principal démarré)

Vérifiez les logs de l'Init Container:

kubectl logs app-with-init -c init-setup

Vérifiez les logs du conteneur principal:

kubectl logs app-with-init -c app-container

Vous devriez voir que le conteneur principal a lu les fichiers créés par l'Init Container.

Partie 3: Init Container avec Attente de Dépendance​

Les Init Containers peuvent attendre que des services externes soient disponibles.

Étape 3.1: Créer un Pod qui Attend un Service​

Créez un fichier pod-init-wait.yaml:

# pod-init-wait.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-wait-service
spec:
  initContainers:
  - name: wait-for-service
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Attente que le service soit disponible..."
      until nslookup kubernetes.default.svc.cluster.local; do
        echo "Service non disponible, attente..."
        sleep 2
      done
      echo "Service disponible!"
  containers:
  - name: app-container
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args: ["echo 'Application démarrée après vérification du service' && sleep 3600"]

Appliquez le Pod:

kubectl apply -f pod-init-wait.yaml

Vérifiez les logs de l'Init Container:

kubectl logs app-wait-service -c wait-for-service

Partie 4: Pattern Sidecar​

Un Sidecar est un conteneur auxiliaire qui s'exécute dans le même Pod que le conteneur principal pour fournir des fonctionnalités complémentaires (logging, monitoring, proxy, etc.).

Étape 4.1: Créer un Pod avec Pattern Sidecar pour Logging​

Créez un fichier pod-sidecar-logging.yaml:

# pod-sidecar-logging.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  volumes:
  - name: shared-logs
    emptyDir: {} # Volume partagé pour les logs
  containers:
  - name: app-container
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      counter=0
      while true; do
        echo "[$(date)] Log entry $counter from application" >> /logs/app.log
        counter=$((counter+1))
        sleep 5
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
  - name: log-collector
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Sidecar: Collecte des logs de l'application..."
      while true; do
        if [ -f /logs/app.log ]; then
          echo "=== Nouveaux logs ==="
          tail -n 5 /logs/app.log
        fi
        sleep 10
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
      readOnly: true # Le sidecar lit seulement les logs

Explication:

  • Le conteneur principal écrit des logs dans un volume partagé.
  • Le sidecar lit ces logs et les traite (ici, les affiche).

Appliquez le Pod:

kubectl apply -f pod-sidecar-logging.yaml

Étape 4.2: Vérifier le Pattern Sidecar​

Vérifiez que les deux conteneurs s'exécutent:

kubectl get pods app-with-sidecar

Vérifiez les logs du conteneur principal:

kubectl logs app-with-sidecar -c app-container

Vérifiez les logs du sidecar:

kubectl logs app-with-sidecar -c log-collector

Vous devriez voir le sidecar afficher les logs collectés du conteneur principal.

Partie 5: Sidecar pour Monitoring​

Créons un autre exemple avec un sidecar pour le monitoring.

Étape 5.1: Créer un Pod avec Sidecar de Monitoring​

Créez un fichier pod-sidecar-monitoring.yaml:

# pod-sidecar-monitoring.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-monitored
spec:
  containers:
  - name: app-container
    image: nginx:1.20
    ports:
    - containerPort: 80
  - name: metrics-collector
    image: busybox:1.35
    command: ["/bin/sh", "-c"]
    args:
    - |
      echo "Sidecar: Collecte de métriques..."
      while true; do
        # Simuler la collecte de métriques
        echo "[$(date)] Métriques collectées: CPU, Memory, Network"
        sleep 15
      done

Appliquez le Pod:

kubectl apply -f pod-sidecar-monitoring.yaml

Vérifiez les logs du sidecar:

kubectl logs app-monitored -c metrics-collector

Partie 6: Avantages des Patterns​

Init Containers:​

  • Séparation des préoccupations: Préparation vs exécution
  • Ordre garanti: S'exécutent avant les conteneurs principaux
  • Réutilisabilité: Même Init Container pour plusieurs Pods

Sidecars:​

  • Cohésion: Conteneurs dans le même Pod partagent le réseau et le stockage
  • Flexibilité: Ajout de fonctionnalités sans modifier l'application principale
  • Isolation: Chaque conteneur peut avoir ses propres ressources

Partie 7: Nettoyage​

Supprimez les Pods créés:

kubectl delete pod app-with-init app-wait-service app-with-sidecar app-monitored

Résumé du Lab​

Dans ce lab, vous avez exploré les Init Containers et le pattern Sidecar. Vous avez appris à utiliser les Init Containers pour préparer l'environnement avant le démarrage des applications, à implémenter des sidecars pour le logging et le monitoring, et à comprendre les avantages de ces patterns pour l'architecture des applications.

Prochaines Étapes​

Ce module sur les Workloads Avancés est maintenant complet. Vous pouvez passer au Module 8 sur Ingress et Load Balancing.

Module 8: Ingress et Load Balancing

Lab créé le: Décembre 2024