Optimisation de la chaîne CI/CD avec GitHub Actions et Kubernetes
Introduction
GitHub Actions pour le CI, Kubernetes pour le runtime, ArgoCD comme pont GitOps entre les deux : c'est l'architecture que je déploie sur la majorité de mes projets. Sur WizOps.fr, ce trio permet de passer du code pushé au déploiement en production en moins de 5 minutes. Voici comment construire et optimiser cette chaîne.
GitHub Actions : le CI qui s'adapte au Kubernetes
L'avantage de GitHub Actions pour un pipeline orienté Kubernetes, c'est la richesse de l'écosystème d'actions. docker/build-push-action pour builder et pousser les images, azure/k8s-set-context ou aws-actions/configure-aws-credentials pour s'authentifier sur les clusters, helm/chart-releaser-action pour publier des Helm Charts. Chez Bloomflow, le workflow CI est structuré en étapes : lint, test, build Docker, scan Trivy, push GHCR. Chaque étape est conditionnelle : si les tests échouent, le build Docker ne se lance même pas, économisant des minutes de compute.
Le pattern GitOps : séparer le build du deploy
Un anti-pattern classique : avoir le déploiement Kubernetes directement dans le pipeline CI. Chez Padam Mobility, j'ai implémenté le pattern GitOps : GitHub Actions build l'image et met à jour le tag dans un repo de manifests Kubernetes dédié. ArgoCD surveille ce repo et applique les changements. Cette séparation a plusieurs avantages : le CI est découplé du CD, le repo de manifests est la source de vérité pour l'état du cluster, et n'importe qui peut voir l'historique des déploiements dans Git. Le rollback se fait par un simple git revert.
Optimiser les runners pour les builds Kubernetes
Les builds Docker pour Kubernetes nécessitent souvent des images volumineuses et des dépendances lourdes. Chez KNDS, les builds multi-arch (amd64 + arm64) prenaient 25 minutes sur les runners GitHub-hosted. En passant à des runners self-hosted avec cache Docker local et SSD NVMe, le temps est descendu à 7 minutes. L'astuce supplémentaire : utiliser Actions Runner Controller (ARC) sur Kubernetes lui-même pour avoir des runners éphémères qui scalent automatiquement. Le runner s'instancie au lancement du job et se détruit à la fin, sans gaspillage de ressources.
Tests de déploiement Kubernetes dans le CI
Valider que les manifests Kubernetes sont corrects avant le déploiement, c'est éviter 90% des échecs. Dans le pipeline, j'exécute systématiquement helm lint, helm template suivi de kubectl apply --dry-run=server, et des tests Kustomize si applicable. Chez Bloomflow, on va plus loin avec des namespaces éphémères : chaque PR crée un namespace Kubernetes dédié, déploie l'application complète, exécute des tests de smoke, puis nettoie tout. Le coût est minime (quelques cents par PR) mais la confiance dans le déploiement est maximale.
Monitoring de la chaîne complète
La chaîne CI/CD elle-même doit être monitorée. Chez Bloomflow, je remonte les métriques GitHub Actions (durée de build, taux d'échec, temps d'attente des runners) dans Grafana via une action custom qui publie dans Prometheus. Côté Kubernetes, les métriques ArgoCD (sync status, health status, dernière synchronisation) alimentent un dashboard dédié. Quand un déploiement reste en "Progressing" plus de 5 minutes, une alerte Slack est envoyée. Cette observabilité de bout en bout, du commit au pod running, élimine les angles morts.
Conclusion
L'optimisation de la chaîne GitHub Actions + Kubernetes passe par trois axes : des builds rapides (cache, runners optimisés), une séparation clean du CI et du CD (pattern GitOps), et un monitoring de bout en bout. Cette architecture, éprouvée sur des projets de toutes tailles, est à la fois robuste et évolutive. C'est le standard que je recommande et que je mets en place chez WizOps.