Scaler les applications dans le cloud : Kubernetes et GitOps en pratique

L'orchestration de conteneurs transforme la façon dont nous déployons et gérons les applications. Ce guide couvre les fondamentaux de Docker, Vagrant, K3s et ArgoCD — des concepts de base aux modèles de production.

Fondamentaux de Docker

Docker regroupe les applications avec leurs dépendances dans des unités portables et isolées appelées conteneurs. Contrairement aux machines virtuelles, les conteneurs partagent le noyau de l'hôte, ce qui les rend légers et rapides.

Conteneurs vs Machines Virtuelles

CONTENEURS                          MACHINES VIRTUELLES

┌─────────┐ ┌─────────┐            ┌─────────┐ ┌─────────┐
│  App A  │ │  App B  │            │  App A  │ │  App B  │
├─────────┤ ├─────────┤            ├─────────┤ ├─────────┤
│  Libs   │ │  Libs   │            │  Libs   │ │  Libs   │
└────┬────┘ └────┬────┘            ├─────────┤ ├─────────┤
     │           │                 │ Guest OS│ │ Guest OS│
┌────┴───────────┴────┐            └────┬────┘ └────┬────┘
│   Container Engine  │                 │           │
├─────────────────────┤            ┌────┴───────────┴────┐
│     Host Kernel     │            │     Hypervisor      │
├─────────────────────┤            ├─────────────────────┤
│      Host OS        │            │      Host OS        │
└─────────────────────┘            └─────────────────────┘

Démarrage : Millisecondes          Démarrage : Minutes
Taille : Mo                        Taille : Go
Isolation : Niveau processus       Isolation : Niveau matériel

Quand utiliser les conteneurs : Microservices, pipelines CI/CD, environnements de développement, applications sans état.

Quand utiliser les VMs : Exécuter différents noyaux OS, isolation de sécurité renforcée, applications legacy.

Concepts Fondamentaux

Les images sont des modèles en lecture seule contenant le code de l'application, le runtime, les bibliothèques et la configuration. Elles utilisent un système de fichiers en couches où chaque instruction crée une nouvelle couche.

Les conteneurs sont des instances en cours d'exécution des images. Ils ajoutent une couche inscriptible par-dessus les couches de l'image. Plusieurs conteneurs peuvent partager les mêmes couches d'image, économisant de l'espace disque.

Les volumes permettent de persister les données au-delà du cycle de vie du conteneur. Les données dans la couche inscriptible du conteneur sont perdues lorsque le conteneur est supprimé.

Couches d'Image et Mise en Cache

Docker met en cache chaque couche. Si une couche n'a pas changé, Docker la réutilise. C'est pourquoi l'ordre des instructions est important :

# Mauvais : Copier le code avant les dépendances invalide le cache à chaque changement de code
FROM node:18
COPY . .
RUN npm install

# Bon : Les dépendances sont mises en cache séparément du code
FROM node:18
COPY package*.json .
RUN npm install
COPY . .
    

La deuxième approche ne ré-exécute npm install que lorsque package.json change.

Instructions Dockerfile

FROM debian:buster          # Image de base sur laquelle construire

WORKDIR /app                # Définit le répertoire de travail pour les instructions suivantes

COPY ./src /app/src         # Copie des fichiers du contexte de build vers l'image
ADD archive.tar.gz /app/    # Comme COPY, mais extrait automatiquement les archives

RUN apt-get update && \
    apt-get install -y nginx  # Exécute des commandes pendant le build

ENV NODE_ENV=production     # Définit les variables d'environnement
ARG VERSION=1.0             # Variables au moment du build (pas dans l'image finale)

EXPOSE 80                   # Documente les ports sur lesquels le conteneur écoute

VOLUME /data                # Crée un point de montage pour les données persistantes

ENTRYPOINT ["nginx"]        # Commande qui s'exécute toujours
CMD ["-g", "daemon off;"]   # Arguments par défaut (peuvent être remplacés)
    

ENTRYPOINT vs CMD

Comprendre la différence est essentiel :

• CMD : Commande par défaut, complètement remplacée si l'utilisateur fournit des arguments
• ENTRYPOINT : S'exécute toujours, les arguments de l'utilisateur sont ajoutés
• Combinés : ENTRYPOINT définit l'exécutable, CMD fournit les arguments par défaut

ENTRYPOINT ["python"]
CMD ["app.py"]
# Exécute : python app.py
# L'utilisateur lance : docker run myimage script.py
# Exécute : python script.py (CMD remplacé, ENTRYPOINT conservé)
    

Le Problème du PID 1

Dans les conteneurs, votre application s'exécute en tant que PID 1 (processus init). Cela crée deux problèmes :

1. Gestion des signaux : Le PID 1 ne reçoit pas les gestionnaires de signaux par défaut. SIGTERM ne tuera pas votre application à moins que vous ne le gériez explicitement.
2. Récupération des zombies : Le PID 1 doit récupérer les processus enfants orphelins, sinon ils deviennent des zombies.

Solutions :

• Utiliser le flag --init : docker run --init myimage
• Utiliser dumb-init ou tini comme entrypoint
• Gérer les signaux dans votre application

Cycle de Vie d'un Conteneur

                    docker create
    [Image] ──────────────────────► [Créé]
                                        │
                                        │ docker start
                                        ▼
                ┌──────────────────► [En cours] ◄──────────────────┐
                │                       │                         │
                │ docker restart        │ docker stop/kill        │ docker start
                │                       ▼                         │
                └─────────────────── [Arrêté] ────────────────────┘
                                        │
                                        │ docker rm
                                        ▼
                                    [Supprimé]

Réseau Docker

Docker fournit plusieurs pilotes réseau :

• bridge (par défaut) : Les conteneurs sur le même bridge peuvent communiquer. Isolés du réseau hôte.
• host : Le conteneur partage la pile réseau de l'hôte. Pas d'isolation, mais pas de surcharge NAT.
• none : Pas de réseau. Isolation complète.
• overlay : Réseau multi-hôte pour Docker Swarm.

Les conteneurs sur le même réseau bridge défini par l'utilisateur peuvent se résoudre mutuellement par nom de conteneur (DNS interne de Docker) :

# Créer un réseau
docker network create mynet

# Les conteneurs peuvent se joindre par nom
docker run --name db --network mynet postgres
docker run --name app --network mynet myapp
# app peut se connecter à "db:5432"
    

Types de Volumes

• Volumes nommés : Gérés par Docker, persistent dans la zone de stockage Docker
• Bind mounts : Associent un répertoire hôte à un chemin de conteneur
• tmpfs : Stocké uniquement en mémoire, jamais écrit sur disque

# Volume nommé
docker run -v mydata:/app/data myimage

# Bind mount
docker run -v /host/path:/container/path myimage

# tmpfs (secrets, données sensibles)
docker run --tmpfs /app/secrets myimage
    

Docker Compose

Docker Compose définit des applications multi-conteneurs dans un seul fichier YAML. Il gère le réseau, les volumes et les dépendances entre services.

Structure de Base

version: '3.8'

services:
  web:
    build: ./web
    ports:
      - "80:80"
    depends_on:
      - api
    environment:
      - API_URL=http://api:3000
    networks:
      - frontend
      - backend

  api:
    image: node:18
    volumes:
      - ./api:/app
      - node_modules:/app/node_modules
    networks:
      - backend

  db:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - backend

networks:
  frontend:
  backend:

volumes:
  db_data:
  node_modules:
    

Configuration des Services

Build vs Image :

• build: Construire à partir d'un Dockerfile
• image: Récupérer depuis un registre
• Les deux : Construire et étiqueter avec ce nom

Dépendances :

• depends_on: Contrôle uniquement l'ordre de démarrage, pas la disponibilité
• Pour la disponibilité, utilisez des health checks ou des scripts d'attente

services:
  api:
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    

Politiques de Redémarrage :

• no : Ne jamais redémarrer (par défaut)
• always : Toujours redémarrer
• on-failure : Redémarrer uniquement en cas de sortie non nulle
• unless-stopped : Comme always, mais respecte les arrêts manuels

Réseau dans Compose

Compose crée un réseau par défaut pour votre application. Tous les services peuvent se joindre mutuellement par nom de service :

services:
  web:
    # Peut se connecter à "db:5432" - le nom du service est le nom d'hôte
  db:
    image: postgres
    

Les réseaux personnalisés permettent l'isolation entre groupes de services :

services:
  frontend:
    networks:
      - public
  api:
    networks:
      - public
      - private
  db:
    networks:
      - private  # Non accessible depuis le frontend

networks:
  public:
  private:
    

Variables d'Environnement

Priorité (de la plus haute à la plus basse) :

1. Variables d'environnement du shell
2. environment: dans le fichier compose
3. Contenu de env_file:
4. ENV du Dockerfile

services:
  app:
    env_file:
      - .env           # Chargé en premier
      - .env.local     # Remplace .env
    environment:
      - DEBUG=true     # Remplace env_file
    

Fondamentaux de Vagrant

Vagrant crée des environnements de machines virtuelles reproductibles. Il abstrait les différences de fournisseur (VirtualBox, VMware, AWS) derrière un fichier de configuration simple.

Concepts Fondamentaux

• Box : Image VM pré-packagée (comme une image Docker pour les VMs)
• Provider : Backend de virtualisation (VirtualBox, VMware, Hyper-V, cloud)
• Provisioner : Outil pour configurer la VM après démarrage (shell, Ansible, Puppet)
• Dossier Synchronisé : Répertoire partagé entre l'hôte et l'invité

Structure du Vagrantfile

Vagrant.configure("2") do |config|
  # Box de base
  config.vm.box = "ubuntu/focal64"

  # Configuration réseau
  config.vm.network "private_network", ip: "192.168.56.10"
  config.vm.network "forwarded_port", guest: 80, host: 8080

  # Dossiers synchronisés
  config.vm.synced_folder "./data", "/vagrant_data"

  # Paramètres spécifiques au provider
  config.vm.provider "virtualbox" do |vb|
    vb.memory = 2048
    vb.cpus = 2
  end

  # Provisionnement
  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get install -y nginx
  SHELL
end
    

Modes Réseau

• NAT (par défaut) : La VM peut accéder à Internet, l'hôte ne peut pas accéder directement à la VM
• Ports transférés : Associent un port hôte à un port invité via NAT
• Réseau privé : Réseau hôte uniquement, les VMs peuvent communiquer entre elles et avec l'hôte
• Réseau public : Bridgé vers le réseau physique, la VM obtient une IP du routeur

Configuration Multi-Machine

Vagrant excelle dans la création d'environnements multi-nœuds :

Vagrant.configure("2") do |config|
  config.vm.define "master" do |master|
    master.vm.box = "ubuntu/focal64"
    master.vm.network "private_network", ip: "192.168.56.10"
    master.vm.provision "shell", path: "scripts/master.sh"
  end

  config.vm.define "worker" do |worker|
    worker.vm.box = "ubuntu/focal64"
    worker.vm.network "private_network", ip: "192.168.56.11"
    worker.vm.provision "shell", path: "scripts/worker.sh"
  end
end
    

Les dossiers synchronisés permettent une communication inter-VM simple (par exemple, partage de tokens, certificats).

Commandes Essentielles

vagrant up              # Créer et démarrer les VMs
vagrant halt            # Arrêter les VMs (préserve l'état)
vagrant destroy         # Supprimer complètement les VMs
vagrant ssh [name]      # Se connecter en SSH à une VM
vagrant provision       # Ré-exécuter les provisioners
vagrant reload          # Redémarrer avec les nouveaux paramètres du Vagrantfile
vagrant status          # Afficher l'état des VMs
    

Fondamentaux de Kubernetes (K3s)

Kubernetes orchestre les applications conteneurisées sur un cluster de machines. K3s est une distribution Kubernetes légère et certifiée, packagée dans un binaire unique de moins de 100 Mo.

Pourquoi K3s ?

KUBERNETES (K8s)                    K3s

┌─────────────────────┐            ┌─────────────────────┐
│ etcd (séparé)       │            │                     │
├─────────────────────┤            │   Binaire Unique    │
│ API Server          │            │   ┌───────────────┐ │
├─────────────────────┤            │   │ SQLite/etcd   │ │
│ Controller Manager  │     ──►    │   │ API Server    │ │
├─────────────────────┤            │   │ Controller    │ │
│ Scheduler           │            │   │ Scheduler     │ │
├─────────────────────┤            │   └───────────────┘ │
│ Cloud Controller    │            │                     │
└─────────────────────┘            └─────────────────────┘

Mémoire : 1 Go+ par composant      Mémoire : 512 Mo au total
Installation : Complexe            Installation : Commande unique

K3s inclut tout le nécessaire : containerd, Flannel (CNI), CoreDNS, Traefik (Ingress), ServiceLB.

Concepts Fondamentaux

Architecture du Cluster :

• Plan de Contrôle (Master) : API Server, Scheduler, Controller Manager, etcd
• Nœuds Workers : Exécutent les charges de travail, gérés par kubelet

Ressources de Charge de Travail :

• Pod : Unité déployable la plus petite. Un ou plusieurs conteneurs partageant réseau/stockage.
• Deployment : Gère les ReplicaSets, gère les mises à jour progressives et les rollbacks.
• ReplicaSet : Garantit qu'un nombre spécifié de réplicas de pods sont en cours d'exécution.
• StatefulSet : Pour les applications avec état nécessitant une identité réseau stable et un stockage persistant.
• DaemonSet : Exécute un pod sur chaque nœud (surveillance, agents de journalisation).

Cycle de Vie d'un Pod

[En attente] ──► [En cours] ──► [Succès/Échec]
    │               │
    │               ▼
    │         [CrashLoopBackOff]
    │               │
    └───────────────┘
         redémarrage

• En attente (Pending) : Accepté mais non planifié (aucun nœud disponible, téléchargement d'images)
• En cours (Running) : Lié à un nœud, au moins un conteneur en cours d'exécution
• Succès (Succeeded) : Tous les conteneurs se sont terminés avec succès
• Échec (Failed) : Tous les conteneurs terminés, au moins un a échoué
• CrashLoopBackOff : Le conteneur continue de planter, Kubernetes retarde les redémarrages

Types de Services

Les services fournissent des points d'accès réseau stables pour les pods :

• ClusterIP (par défaut) : IP interne au cluster uniquement. Les pods peuvent y accéder, pas le trafic externe.
• NodePort : Expose sur l'IP de chaque nœud à un port statique (30000-32767).
• LoadBalancer : Provisionne un équilibreur de charge externe (fournisseurs cloud).
• ExternalName : Associe le service à un nom DNS externe.

                   Trafic Externe
                         │
                         ▼
┌───────────────────────────────────────────┐
│              LoadBalancer                 │
│        (Cloud Provider / MetalLB)         │
└───────────────────────────────────────────┘
                         │
                         ▼
┌───────────────────────────────────────────┐
│             NodePort :30080               │
│         (Chaque Nœud du Cluster)          │
└───────────────────────────────────────────┘
                         │
                         ▼
┌───────────────────────────────────────────┐
│          ClusterIP (10.96.x.x)            │
│            (Interne Uniquement)           │
└───────────────────────────────────────────┘
                         │
                         ▼
                   ┌─────────┐
                   │  Pods   │
                   └─────────┘

Labels et Sélecteurs

Les labels sont des paires clé-valeur attachées aux objets. Les sélecteurs filtrent les objets par labels :

# Le Deployment crée des pods avec des labels
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: web        # Le Deployment gère les pods avec ce label
  template:
    metadata:
      labels:
        app: web      # Les pods reçoivent ce label
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx
---
# Le Service sélectionne les pods par label
apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web          # Achemine le trafic vers les pods avec app=web
  ports:
  - port: 80
    

Ingress

Ingress gère l'accès HTTP/HTTPS externe aux services. Il fournit :

• Routage basé sur l'hôte (app1.example.com → service1)
• Routage basé sur le chemin (/api → api-service, /web → web-service)
• Terminaison TLS

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: traefik
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  - host: web.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
    

ConfigMaps et Secrets

Séparer la configuration des images de conteneurs :

# ConfigMap pour les données non sensibles
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "postgres"
  LOG_LEVEL: "info"
---
# Secret pour les données sensibles (encodées en base64)
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DATABASE_PASSWORD: cGFzc3dvcmQxMjM=  # encodé en base64
---
# Utilisation dans un Pod
spec:
  containers:
  - name: app
    envFrom:
    - configMapRef:
        name: app-config
    - secretRef:
        name: app-secrets
    

Limites de Ressources

Toujours définir des demandes et des limites de ressources en production :

spec:
  containers:
  - name: app
    resources:
      requests:        # Utilisé par le planificateur pour le placement
        memory: "128Mi"
        cpu: "250m"    # 0,25 cœurs CPU
      limits:          # Le conteneur ne peut pas dépasser
        memory: "256Mi"
        cpu: "500m"
    

Commandes kubectl Essentielles

# Infos cluster
kubectl cluster-info
kubectl get nodes

# Charges de travail
kubectl get pods -A                    # Tous les namespaces
kubectl get deployments
kubectl describe pod             # Informations détaillées
kubectl logs  -f                  # Suivre les logs
kubectl exec -it  -- /bin/sh      # Shell dans le conteneur

# Appliquer/Supprimer
kubectl apply -f manifest.yaml
kubectl delete -f manifest.yaml

# Débogage
kubectl get events --sort-by=.lastTimestamp
kubectl top pods                       # Utilisation des ressources
    

K3d : K3s dans Docker

K3d exécute des clusters K3s à l'intérieur de conteneurs Docker. Plus rapide que les VMs, idéal pour le développement local et CI/CD.

Quand Utiliser

• K3s dans des VMs (Vagrant) : Simule la production, teste les pannes de nœuds, les politiques réseau
• K3d (Docker) : Itération rapide, pipelines CI, ressources limitées

# Créer un cluster avec mappage de port
k3d cluster create dev -p "8080:80@loadbalancer"

# Cluster multi-nœuds
k3d cluster create prod --servers 3 --agents 2

# Avec registre local
k3d cluster create dev --registry-create dev-registry:5000

# Lister et supprimer
k3d cluster list
k3d cluster delete dev
    

GitOps avec ArgoCD

GitOps utilise Git comme source de vérité unique pour l'infrastructure et les applications. ArgoCD synchronise en continu l'état du cluster pour qu'il corresponde à Git.

Principes GitOps

1. Déclaratif : Tout le système décrit de manière déclarative (manifestes YAML)
2. Versionné : État souhaité stocké dans Git avec un historique complet
3. Automatisé : Les modifications sont automatiquement appliquées au cluster
4. Réconciliation Continue : Les agents s'assurent que le cluster correspond à Git

TRADITIONNEL                        GITOPS

Développeur ──► CI ──► kubectl      Développeur ──► Git ──► ArgoCD ──► Cluster
                          │                          │           │
                          ▼                          ▼           ▼
                      Cluster             Piste d'audit   Auto-réparation

Problèmes :                         Avantages :
- Qui a déployé quoi ?              - Piste d'audit complète
- Rollbacks manuels                 - Git revert = Rollback
- Dérive entre les envs             - Environnements cohérents

Architecture d'ArgoCD

Concepts Fondamentaux

Stratégies de Synchronisation

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/repo
    targetRevision: HEAD
    path: k8s/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # Supprimer les ressources retirées
      selfHeal: true    # Annuler les modifications manuelles
    syncOptions:
    - CreateNamespace=true
    

Santé de l'Application

ArgoCD suit l'état de santé de toutes les ressources :

Rollback

GitOps rend le rollback trivial :

# Option 1 : Git revert
git revert HEAD
git push
# ArgoCD synchronise automatiquement

# Option 2 : CLI ArgoCD
argocd app rollback myapp

# Option 3 : Synchroniser sur une révision spécifique
argocd app sync myapp --revision abc123
    

Assembler le Tout

STACK D'ORCHESTRATION DE CONTENEURS

┌────────────────────────────────────────────────────────────┐
│                          GitOps                            │
│    Dépôt Git ──► ArgoCD ──► Réconciliation Continue        │
└────────────────────────────────────────────────────────────┘
                             │
                             ▼
┌────────────────────────────────────────────────────────────┐
│                        Kubernetes                          │
│      Pods ◄── Deployments ◄── Services ◄── Ingress         │
└────────────────────────────────────────────────────────────┘
                             │
                             ▼
┌────────────────────────────────────────────────────────────┐
│                     Runtime de Conteneur                   │
│     Docker/containerd ──► Images ──► Conteneurs            │
└────────────────────────────────────────────────────────────┘
                             │
                             ▼
┌────────────────────────────────────────────────────────────┐
│                       Infrastructure                       │
│          VMs (Vagrant) / Cloud / Bare Metal                │
└────────────────────────────────────────────────────────────┘

Points Clés

• Docker : Packager les applications de manière cohérente. Comprendre les couches, le réseau et les volumes.
• Compose : Définir des applications multi-conteneurs. Utiliser des health checks et une gestion appropriée des dépendances.
• Vagrant : VMs reproductibles pour le développement et les tests de configurations multi-nœuds.
• Kubernetes : Orchestrer à grande échelle. Maîtriser les Pods, Services, Deployments et Ingress.
• GitOps : Git comme source de vérité. Déploiements automatisés, auditables et réversibles.

Quand Utiliser Quoi

Conclusion

L'orchestration de conteneurs n'est pas un outil unique, mais une approche en couches pour le déploiement d'applications. Chaque couche résout des problèmes spécifiques :

Docker résout le problème "ça marche sur ma machine" en packagéant les applications avec leurs dépendances. Comprendre les couches d'image, les modes réseau et les types de volumes est essentiel pour créer des conteneurs efficaces et prêts pour la production.

Docker Compose étend cela aux applications multi-conteneurs, gérant les dépendances entre services, le réseau et la configuration dans un seul fichier déclaratif. Les health checks et les politiques de redémarrage appropriées font la différence entre les configurations de développement et les déploiements de niveau production.

Vagrant reste précieux quand vous avez besoin d'une isolation VM complète, pour tester des clusters multi-nœuds ou simuler une infrastructure de production localement. Son abstraction de fournisseur signifie que le même Vagrantfile fonctionne avec VirtualBox, VMware et les fournisseurs cloud.

Kubernetes est le standard industriel pour l'orchestration de conteneurs à grande échelle. La courbe d'apprentissage est raide, mais comprendre les primitives de base — Pods, Services, Deployments et Ingress — débloque de puissants schémas de déploiement. K3s rend cela accessible sans la surcharge opérationnelle de Kubernetes complet.

GitOps avec ArgoCD complète le tableau en rendant les déploiements déclaratifs, auditables et réversibles. Quand Git est votre source de vérité, les rollbacks deviennent des git reverts, et l'historique de votre infrastructure vit dans le contrôle de version.

Commencez avec Docker pour les applications simples. Passez à Compose quand vous avez besoin de plusieurs services. Envisagez Kubernetes quand vous avez besoin de mise à l'échelle, d'auto-réparation et de stratégies de déploiement avancées. Ajoutez GitOps quand vous avez besoin de pistes d'audit et de réconciliation automatisée. Chaque outil s'appuie sur le précédent, et comprendre les fondamentaux facilite l'adoption de la couche suivante.