Introduction : L’Incontournable Duo Docker et Kubernetes en 2026

En 2026, l’écosystème du développement logiciel est dominé par la conteneurisation et l’orchestration. Les chiffres parlent d’eux-mêmes : selon la CNCF Annual Survey 2024, 90 % des organisations utilisent des conteneurs en production, et 84 % d’entre elles ont adopté Kubernetes pour orchestrer ces workloads critiques. Cette omniprésence souligne l’importance d’une stratégie CI/CD (Intégration Continue/Déploiement Continu) robuste, où Docker et Kubernetes jouent des rôles complémentaires et indispensables.

Cet article, rédigé par un expert technique senior de Nuvelia, s’adresse aux développeurs, architectes et DSI désireux de maîtriser l’intégration de Docker et Kubernetes dans des pipelines CI/CD modernes. Nous explorerons les mécanismes, les bonnes pratiques et les outils clés pour bâtir une chaîne de déploiement efficace et sécurisée, en nous appuyant sur des exemples concrets avec GitHub Actions et GitLab CI.

Comprendre les Rôles : Docker pour la Conteneurisation, Kubernetes pour l’Orchestration

Bien que souvent mentionnés ensemble, Docker et Kubernetes remplissent des fonctions distinctes mais synergiques dans un pipeline CI/CD. Cette distinction est cruciale pour concevoir des architectures résilientes.

Docker : La Fabrication d’Images et la Portabilité

Docker, via son moteur, reste l’outil de référence pour la conteneurisation. Il permet de packager une application et toutes ses dépendances dans une image portable et isolée. Cette image Docker est le livrable standard de la phase d’intégration continue. Un Dockerfile décrit précisément l’environnement d’exécution, garantissant que l’application se comportera de manière identique, qu’elle soit exécutée sur une machine de développement, un serveur de CI ou un cluster Kubernetes en production.

Il est important de noter que depuis Kubernetes 1.24+, le moteur Docker n’est plus le runtime conteneur par défaut. Kubernetes s’appuie désormais sur des runtimes compatibles CRI (Container Runtime Interface) comme containerd ou CRI-O. Cela signifie que même si vous utilisez Docker pour construire vos images, l’exécution de ces conteneurs dans Kubernetes est gérée par un runtime sous-jacent. Comme nous l’avons expliqué en détail, Kubernetes s’est séparé de Docker mais sans impact majeur pour les développeurs qui continuent de créer leurs images avec les outils Docker habituels.

Kubernetes : L’Orchestration et le Déploiement à Grande Échelle

Une fois les images Docker construites et testées, Kubernetes entre en jeu. Ce système d’orchestration de conteneurs, devenu un standard de facto, gère le déploiement, la mise à l’échelle, la gestion des ressources et la haute disponibilité des applications conteneurisées. Il abstrait l’infrastructure sous-jacente, permettant aux équipes de se concentrer sur l’application elle-même. Pour approfondir les capacités de cette plateforme, vous pouvez consulter notre page dédiée à notre expertise en matière de Kubernetes.

Kubernetes offre des primitives puissantes (Pods, Deployments, Services, Ingress, PersistentVolumes) pour définir l’état désiré de votre infrastructure applicative. Il assure que cet état est maintenu, même en cas de défaillance matérielle ou logicielle. C’est cette capacité à orchestrer des milliers de conteneurs de manière fiable qui en fait le pilier du déploiement continu moderne, surpassant les approches plus traditionnelles de gestion d’infrastructure.

Architecture d’un Pipeline CI/CD Docker et Kubernetes

Un pipeline CI/CD moderne intégrant Docker et Kubernetes suit généralement les étapes suivantes :

1. Développement et Versionnement : Le code source est développé et versionné, typiquement sur Git (GitHub, GitLab, Bitbucket).
2. Intégration Continue (CI) :
   • Build de l’image Docker : Un Dockerfile est utilisé pour construire l’image Docker de l’application.
   • Tag et Push : L’image est taguée (généralement avec le hash du commit ou un numéro de build) et poussée vers un registre de conteneurs (Docker Hub, GitLab Container Registry, AWS ECR, Google Container Registry, Azure Container Registry).
   • Tests : Des tests unitaires, d’intégration et de sécurité (scan de vulnérabilités d’images avec des outils comme Trivy ou Grype) sont exécutés sur l’image ou le code.
3. Déploiement Continu (CD) :
   • Mise à jour des Manifestes Kubernetes : Les fichiers de configuration Kubernetes (Deployment, Service, Ingress, etc.) sont mis à jour pour référencer la nouvelle image Docker. Des outils comme Kustomize ou Helm sont souvent utilisés pour gérer la paramétrisation des manifestes.
   • Application des Manifestes : Les manifestes sont appliqués au cluster Kubernetes cible (développement, staging, production).
   • Validation : Des tests post-déploiement (tests end-to-end, monitoring) sont effectués pour s’assurer du bon fonctionnement de l’application.

L’adoption des pratiques GitOps, utilisées par 56 % des organisations selon la CNCF, renforce ce modèle en rendant le dépôt Git la source unique de vérité pour l’état désiré de l’infrastructure et des applications. Des outils comme Argo CD ou Flux, des projets CNCF Graduated, surveillent le dépôt Git et appliquent automatiquement les changements au cluster Kubernetes.

Mise en Pratique : Exemples avec GitHub Actions et GitLab CI

Illustrons ces principes avec des exemples de pipelines pour GitHub Actions et GitLab CI.

Exemple avec GitHub Actions

Ce workflow GitHub Actions va construire une image Docker, la pousser vers GitHub Container Registry et déclencher un déploiement sur un cluster Kubernetes.

name: CI/CD Docker et Kubernetes

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to the Container registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=sha,format=true,prefix=

      - name: Build and push Docker image
        uses: docker/build-and-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

      - name: Deploy to Kubernetes
        if: github.ref == 'refs/heads/main'
        uses: azure/k8s-set-context@v3
        with:
          method: kubeconfig
          kubeconfig: ${{ secrets.KUBE_CONFIG_DATA }}

      - name: Update image in Kubernetes manifests
        if: github.ref == 'refs/heads/main'
        run: |
          # Exemple avec Kustomize
          kustomize edit set image ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}=${{ steps.meta.outputs.tags }}
          # Ou avec sed pour un fichier YAML simple
          # sed -i "s|image: .*/${{ env.IMAGE_NAME }}:.*|image: ${{ steps.meta.outputs.tags }}|" k8s/deployment.yaml

      - name: Apply Kubernetes manifests
        if: github.ref == 'refs/heads/main'
        run: |
          kubectl apply -k k8s/ # Pour Kustomize
          # kubectl apply -f k8s/deployment.yaml # Pour un fichier simple

Exemple avec GitLab CI

Voici un .gitlab-ci.yml pour une approche similaire avec GitLab CI, utilisant le Container Registry intégré et kubectl.

stages:
  - build
  - deploy

variables:
  DOCKER_IMAGE_NAME: $CI_REGISTRY_IMAGE
  DOCKER_TAG: $CI_COMMIT_SHORT_SHA

build_image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE_NAME:$DOCKER_TAG .
    - docker push $DOCKER_IMAGE_NAME:$DOCKER_TAG
  only:
    - main
    - merge_requests

deploy_to_kubernetes:
  stage: deploy
  image: 
    name: bitnami/kubectl:latest # Ou une image avec kubectl et kustomize
    entrypoint: ["/bin/sh", "-c"]
  script:
    - echo "$KUBE_CONFIG" > kubeconfig.yaml
    - export KUBECONFIG=$(pwd)/kubeconfig.yaml
    - kubectl config use-context default # Assurez-vous que le contexte est correct
    - # Option 1: Utilisation de Kustomize pour patcher l'image
    - kustomize edit set image $DOCKER_IMAGE_NAME=$DOCKER_IMAGE_NAME:$DOCKER_TAG
    - kubectl apply -k k8s/
    - # Option 2: Utilisation de sed pour un fichier YAML simple
    - # sed -i "s|image: ${DOCKER_IMAGE_NAME}:.*|image: ${DOCKER_IMAGE_NAME}:${DOCKER_TAG}|" k8s/deployment.yaml
    - # kubectl apply -f k8s/deployment.yaml
  environment:
    name: production
  only:
    - main

Ces exemples illustrent la flexibilité des outils CI/CD pour orchestrer la construction d’images Docker et leur déploiement sur Kubernetes. Les variables d’environnement et les secrets sont essentiels pour gérer les informations sensibles (identifiants de registre, kubeconfig).

Bonnes Pratiques et Sécurité dans le Pipeline CI/CD

Un pipeline CI/CD efficace ne se limite pas à l’automatisation ; il doit intégrer les meilleures pratiques en matière de performance, de résilience et de sécurité.

Sécurité (DevSecOps)

La sécurité doit être intégrée à chaque étape du pipeline :

• Scan d’images Docker : Utilisez des scanners comme Trivy ou Grype dans votre CI pour détecter les vulnérabilités (CVE) dans vos images avant même le déploiement. Bloquez les builds si des vulnérabilités critiques sont détectées.
• Principe du Moindre Privilège : Configurez des ServiceAccounts Kubernetes dédiés avec les RBAC (Role-Based Access Control) les plus restrictifs possibles pour chaque workload.
• NetworkPolicy : Implémentez des NetworkPolicies pour restreindre les communications réseau entre les pods. Une approche deny-all par défaut avec des règles d’autorisation explicites, souvent gérée par un CNI avancé comme Cilium, réduit considérablement la surface d’attaque latérale (east-west). Pour une exploration approfondie des stratégies de défense, consultez notre guide sur la sécurité Kubernetes en 2026.
• Pod Security Admission (PSA) : Utilisez le Pod Security Admission de Kubernetes pour appliquer des standards de sécurité aux pods, complété par des outils comme OPA Gatekeeper pour des politiques plus granulaires.
• Secrets Management : Ne stockez jamais de secrets en clair dans Git. Utilisez des solutions comme HashiCorp Vault, Kubernetes Secrets avec des solutions de chiffrement (Sealed Secrets, External Secrets Operator) ou les gestionnaires de secrets des fournisseurs de cloud.

Gestion des Ressources et Résilience

• Requests et Limits : Définissez systématiquement les requests et limits de CPU et de mémoire pour chaque conteneur. Cela permet à Kubernetes de planifier les pods efficacement et d’éviter les problèmes de noisy-neighbor, tout en permettant l’auto-scaling vertical (VPA).
• PodDisruptionBudget (PDB) : Pour les workloads critiques ou stateful, un PDB est indispensable pour garantir un nombre minimal de pods disponibles lors des opérations de maintenance de cluster (drain de nœuds, mises à jour).
• Stratégies de Déploiement : Mettez en œuvre des stratégies de déploiement progressives (Rolling Updates, Blue/Green, Canary Deployments) pour minimiser les interruptions et faciliter les rollbacks.

Observabilité

Intégrez des outils d’observabilité dès le début pour comprendre le comportement de vos applications en production :

• Métriques : Prometheus est le standard pour la collecte de métriques, visualisées avec Grafana.
• Logs : Centralisez les logs de vos conteneurs (via Fluentd, Fluent Bit, Loki).
• Traces : OpenTelemetry, projet CNCF Graduated, unifie la collecte de traces, métriques et logs pour une visibilité complète sur les transactions distribuées.

Choisir l’Infrastructure pour votre Cluster Kubernetes

Le choix de l’infrastructure sous-jacente pour votre cluster Kubernetes impacte directement votre pipeline CI/CD. Que vous optiez pour une solution managée cloud (EKS, GKE, AKS) ou un déploiement sur bare metal, chaque approche présente ses avantages et inconvénients en termes de gestion, de coût et de flexibilité. Pour une analyse détaillée des arbitrages, nous vous invitons à lire notre article sur Kubernetes sur bare metal vs cloud managé en 2026.

Il est également pertinent de distinguer Kubernetes d’autres systèmes d’orchestration plus larges comme OpenStack, qui gère une infrastructure complète allant au-delà des conteneurs. Nous avons analysé les différences clés entre OpenStack et Kubernetes pour la gestion des applications et de l’infrastructure.

Nuvelia : Votre Partenaire pour des Pipelines CI/CD Robustes

L’implémentation et l’optimisation de pipelines CI/CD basés sur Docker et Kubernetes peuvent s’avérer complexes, surtout pour les applications critiques nécessitant une conformité stricte, comme celles gérant la signature électronique ou les paiements bancaires. Chez Nuvelia, nous accompagnons les équipes de développement et les DSI dans la mise en place de ces architectures. Nos services de formation et consulting Kubernetes sont conçus pour transférer notre expertise, vous permettant de maîtriser les défis techniques et d’adopter les meilleures pratiques DevSecOps.

Nous aidons nos clients à concevoir, déployer et maintenir des pipelines CI/CD performants, sécurisés et évolutifs, en tirant parti des dernières avancées technologiques et des standards de l’industrie. Que ce soit pour une migration vers Kubernetes, l’optimisation de vos déploiements existants, ou la formation de vos équipes, notre approche est pragmatique et orientée résultats.

Conclusion : Vers une Agilité et une Fiabilité Accrues

L’association de Docker et Kubernetes dans un pipeline CI/CD est la pierre angulaire de toute stratégie DevOps moderne en 2026. Elle permet non seulement d’automatiser les déploiements, mais aussi d’améliorer considérablement la portabilité, la scalabilité et la résilience des applications. En intégrant les bonnes pratiques de sécurité, de gestion des ressources et d’observabilité dès la conception du pipeline, les organisations peuvent livrer des logiciels plus rapidement, avec une qualité et une fiabilité inégalées.

Maîtriser cette synergie est un avantage compétitif majeur. C’est un investissement qui se traduit par une meilleure agilité, une réduction des erreurs humaines et une capacité accrue à innover. Chez Nuvelia, nous sommes convaincus que l’avenir du développement logiciel passe par ces architectures conteneurisées et orchestrées, et nous sommes là pour vous guider dans cette transformation.