Intégrer les déploiements Kubernetes dans les outils CI/CD (Jenkins, GitLab CI, GitHub Actions)

L'étape logique : Automatiser le déploiement après l'intégration

Une fois que votre code est testé et qu'une image conteneur est construite et poussée vers un registre, l'étape suivante naturelle dans un processus DevOps moderne est d'automatiser le déploiement de cette nouvelle version sur votre cluster Kubernetes. L'intégration continue (CI) s'étend alors logiquement vers la livraison continue (CD) ou le déploiement continu (CD).

L'approche la plus directe consiste à intégrer les commandes de déploiement Kubernetes directement dans les outils de CI/CD que vous utilisez déjà. Que ce soit Jenkins, GitLab CI, GitHub Actions ou un autre système, l'idée est d'ajouter des étapes au pipeline qui interagissent avec l'API Kubernetes pour mettre à jour les applications. Cette méthode est souvent qualifiée d'approche "push", car c'est le système CI/CD qui initie et pousse activement les changements vers le cluster.

Le workflow typique d'un pipeline CI/CD avec déploiement K8s

Un pipeline CI/CD intégrant un déploiement sur Kubernetes suit généralement ces étapes après la réussite des tests :

1. Construire l'image conteneur : Création de l'image Docker (ou autre format OCI) contenant l'application et ses dépendances, souvent taguée avec un identifiant unique (commit SHA, tag Git, numéro de build).
2. Pousser l'image vers un registre : Envoi de l'image construite vers un registre d'images conteneurs (Docker Hub, GitLab Registry, AWS ECR, Google GCR, Azure ACR, Harbor, etc.) accessible par le cluster Kubernetes.
3. Préparer les manifestes/le Chart : Mise à jour des fichiers manifestes Kubernetes (par exemple, un Deployment YAML) pour utiliser le tag de la nouvelle image, ou mise à jour de la version/valeurs d'un Chart Helm.
4. Déployer sur Kubernetes : Exécution de commandes via le système CI/CD pour appliquer les changements au cluster cible. C'est l'étape clé de l'interaction.
5. (Optionnel) Vérifications post-déploiement : Exécution de tests de fumée (smoke tests) ou d'autres vérifications pour s'assurer que le déploiement a réussi et que l'application répond correctement.

Mécanismes d'interaction avec Kubernetes depuis le CI/CD

Pour que l'outil CI/CD puisse effectuer l'étape de déploiement, il doit pouvoir communiquer avec l'API Server du cluster Kubernetes. Plusieurs méthodes sont couramment utilisées :

• Utilisation de kubectl : L'outil CI/CD exécute directement des commandes kubectl. Cela nécessite que l'environnement d'exécution du pipeline (le runner ou l'agent CI/CD) ait accès à kubectl et à un fichier kubeconfig valide (ou un token de ServiceAccount) lui donnant les permissions nécessaires sur le cluster cible. Les commandes typiques sont :
  • kubectl apply -f : Pour appliquer un ou plusieurs manifestes.
  • kubectl set image deployment/ =: : Pour mettre à jour l'image d'un Deployment existant.
  • kubectl rollout status deployment/ : Pour attendre la fin du déploiement.
• Utilisation de la CLI helm : Si vous gérez vos applications avec Helm, le pipeline exécutera des commandes helm. Là encore, l'accès au cluster via kubeconfig ou un token est requis. La commande la plus courante est :
  • helm upgrade --install --namespace --set image.tag= -f : Installe ou met à jour une Release en spécifiant le nouveau tag d'image et potentiellement d'autres valeurs.
• Plugins/Intégrations spécifiques à l'outil CI/CD : De nombreux outils proposent des plugins ou des intégrations dédiées pour Kubernetes, qui peuvent abstraire l'utilisation directe de kubectl ou helm et faciliter la gestion des credentials.

Gestion des Credentials : C'est un point crucial. Le système CI/CD doit disposer de credentials (typiquement un fichier kubeconfig ou un token de Service Account Kubernetes) pour s'authentifier auprès de l'API Server et être autorisé (via RBAC) à effectuer les actions de déploiement. Ces credentials doivent être stockés de manière sécurisée dans les secrets de l'outil CI/CD.

Exemples d'intégration par outil

Jenkins : Dans un Jenkinsfile (pipeline as code), vous pouvez utiliser des étapes sh pour exécuter kubectl ou helm. Jenkins dispose également de plugins Kubernetes pour gérer les credentials (kubeconfig) de manière sécurisée et potentiellement pour exécuter les agents Jenkins directement sous forme de Pods dans le cluster cible, simplifiant l'accès.

// Extrait simplifié de Jenkinsfile
stage('Deploy to K8s') {
    steps {
        withKubeConfig([credentialsId: 'k8s-cluster-creds']) { // Utilisation d'un credential Jenkins
            sh 'kubectl set image deployment/mon-app mon-app-container=myregistry/mon-app:${env.BUILD_ID} -n production'
            sh 'kubectl rollout status deployment/mon-app -n production'
        }
    }
}

GitLab CI : Dans le fichier .gitlab-ci.yml, vous pouvez utiliser des images Docker contenant kubectl ou helm et exécuter les commandes dans les sections script. GitLab permet de stocker le kubeconfig ou le token dans les variables CI/CD (marquées comme protégées et masquées). GitLab propose également des intégrations plus poussées avec Kubernetes, notamment via le GitLab Agent for Kubernetes.

# Extrait simplifié de .gitlab-ci.yml
deploy_prod:
  stage: deploy
  image: bitnami/kubectl:latest # Utilisation d'une image avec kubectl
  script:
    - echo $KUBE_CONFIG_PROD | base64 -d > kubeconfig.yaml # Récupération du KubeConfig depuis variable CI/CD
    - export KUBECONFIG=kubeconfig.yaml
    - kubectl config use-context prod-cluster
    - helm upgrade --install my-app ./chart -n prod --set image.tag=$CI_COMMIT_SHA
  environment:
    name: production
  only:
    - main

GitHub Actions : Dans les fichiers de workflow (.github/workflows/), vous pouvez utiliser des étapes run pour exécuter kubectl ou helm. Les credentials (kubeconfig) sont stockés de manière sécurisée dans les Secrets GitHub. De nombreuses Actions pré-construites sont disponibles sur le Marketplace pour faciliter l'authentification auprès des fournisseurs cloud (Azure, GCP, AWS) et l'exécution des déploiements.

# Extrait simplifié de workflow GitHub Actions
name: Deploy to Prod
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Set up Kubeconfig
      uses: azure/k8s-set-context@v3 # Exemple avec Azure AKS
      with:
        method: kubeconfig
        kubeconfig: ${{ secrets.KUBE_CONFIG_PROD }}

    - name: Deploy with Helm
      run: |
        helm upgrade --install my-app ./chart \
          --namespace prod \
          --set image.tag=${{ github.sha }}

Avantages et inconvénients de l'approche "Push" CI/CD

Avantages :

• Intégration naturelle : S'intègre facilement dans les flux de travail CI/CD existants.
• Contrôle centralisé : Le pipeline CI/CD orchestre l'ensemble du processus, du code au déploiement.
• Flexibilité : Permet d'exécuter n'importe quelle commande ou script nécessaire au déploiement.

Inconvénients :

• Sécurité des credentials : Le système CI/CD doit détenir des droits potentiellement élevés sur le cluster Kubernetes, ce qui représente une surface d'attaque.
• Dérive de configuration (Drift) : L'état réel du cluster peut diverger de ce que le pipeline a déployé si des modifications manuelles sont effectuées sur le cluster. Le pipeline n'a pas connaissance de ces dérives.
• Accès réseau requis : Le runner CI/CD doit avoir un accès réseau direct à l'API Server du cluster Kubernetes cible, ce qui peut être complexe dans des environnements sécurisés.
• Moins déclaratif : Bien que les manifestes K8s soient déclaratifs, le processus de déploiement piloté par le CI/CD est souvent plus impératif (exécution de commandes spécifiques).

Cette approche basée sur le push depuis le CI/CD est une méthode éprouvée et largement utilisée pour automatiser les déploiements Kubernetes. Cependant, ses limitations en matière de sécurité et de gestion de l'état ont conduit à l'émergence de l'approche GitOps, qui adopte un modèle "pull" basé sur Git comme source de vérité.