🚀 Jour 1 : Administration du Cluster et Déploiements Fondamentaux

by Nicolas DELAHAYE | Août 16, 2026 | Sans Categorie

$
kubernetes –challenge day-01 –topic cluster-administration
█

Bienvenue dans le premier jour de notre challenge
« 20 jours pour se préparer à la certification Kubernetes » !

Pour cette première étape, nous allons poser les fondations indispensables
à l’administration d’un cluster Kubernetes. L’objectif n’est pas simplement
de mémoriser des commandes, mais de comprendre les mécanismes qui permettent
de construire, maintenir et faire évoluer un cluster.

🎯 Le thème du jour : les fondations de l’administration

Aujourd’hui, nous nous concentrons sur les bases de l’administration
d’un cluster Kubernetes.
La maîtrise de ces éléments constitue un socle essentiel pour préparer
efficacement la certification CKA.

Dans un environnement Kubernetes construit avec
kubeadm, plusieurs opérations fondamentales doivent être
maîtrisées : initialisation du plan de contrôle, ajout de nœuds,
sauvegarde de l’état du cluster et opérations de maintenance.

Cette première journée couvre notamment :

La configuration initiale et l’initialisation du
Control Plane.
L’ajout de ressources de calcul avec les
Worker Nodes.
Les opérations critiques de maintenance, notamment les
mises à jour.
La protection de l’état du cluster grâce aux
sauvegardes etcd.
Le déploiement et la mise à l’échelle d’une application.

🛠️ Aperçu des exercices du jour

Cinq exercices vont vous permettre de progresser progressivement,
du simple déploiement d’une application jusqu’à des opérations
d’administration plus sensibles.

Niveau	Exercice	Objectif principal
🟢 Simple	Exercice 1	Déployer et mettre à l’échelle une application basique.
🟡 Intermédiaire	Exercice 2	Initialiser le Control Plane avec `kubeadm`.
🟡 Intermédiaire	Exercice 3	Joindre un nouveau Worker Node au cluster.
🔴 Complexe	Exercice 4	Sécuriser l’état du cluster avec un snapshot etcd.
🔴 Complexe	Exercice 5	Procéder à une mise à jour du Control Plane.

💻 Les 5 défis pratiques

À vous de jouer !

Essayez de réaliser ces exercices sur votre propre environnement
de laboratoire. Ne cherchez pas immédiatement la solution :
prenez le temps de consulter la documentation Kubernetes et
d’expérimenter.

💡 Conseil :
Ne cherchez pas immédiatement la solution. Prenez le temps de réaliser
les exercices dans votre environnement de laboratoire et utilisez la
documentation Kubernetes pour vous guider.

📚 Les réponses demain

Les corrections détaillées des cinq exercices seront publiées
demain, dans l’article du Jour 2.

Vous pourrez ainsi comparer votre démarche avec la solution proposée,
comprendre les éventuelles erreurs et identifier les commandes ou
concepts à retenir pour la certification.

🎯 Méthode recommandée :
essayez d’abord de résoudre chaque exercice sans regarder la solution.
Même une tentative infructueuse est utile : elle vous permettra de
mieux comprendre la correction et de mémoriser les commandes.

🏁 À demain !

Cette première journée vous a permis de revoir les opérations
fondamentales nécessaires à l’administration d’un cluster :
déploiement d’une application, initialisation avec
kubeadm, ajout d’un nœud, sauvegarde d’etcd
et préparation d’une mise à jour.

À vous maintenant de passer à la pratique !

Rendez-vous demain pour le Jour 2 :
nous commencerons par les corrections des exercices d’aujourd’hui
avant d’attaquer les nouveaux défis. 🚀

Exercice 1 : Déploiement d’une application simple

🎯 Objectif

Commencer par une opération Kubernetes classique :
créer un Deployment et modifier son nombre de réplicas.

📋 Travail demandé

Créez un Deployment nommé nginx utilisant l’image
conteneur nginx.
Vérifiez que le Deployment est correctement exécuté et que
le nombre de réplicas disponibles correspond au nombre souhaité.
Mettez à l’échelle le Deployment afin de passer
d’un à trois réplicas.

Exercice 2 : Initialisation du cluster avec kubeadm

🎯 Objectif

Initialiser le Control Plane d’un nouveau cluster Kubernetes
à l’aide de kubeadm.

📋 Travail demandé

Désactivez le swap sur la machine.
Celui-ci doit être correctement configuré conformément
aux prérequis de la version de Kubernetes utilisée.
Initialisez le Control Plane avec kubeadm init
en utilisant un fichier de configuration YAML.
Déployez un réseau de Pods avec un plugin CNI tel que
Cilium.

BONUS

Refaite une installation du cluster avec un autre CNI : Calico

Exercice 3 : Agrandissement du cluster

🎯 Objectif

Ajouter un nouveau Worker Node au cluster et vérifier qu’il
rejoint correctement le Control Plane.

📋 Travail demandé

Depuis le Control Plane, générez une nouvelle commande
de jonction avec kubeadm.
Connectez-vous au second nœud et exécutez la commande
kubeadm join fournie.
Revenez sur le Control Plane et vérifiez la présence
du nouveau nœud.

Bonus
Créer un second noeud worker et ajouter le au cluster.

Exercice 4 : Sauvegarde de la base de données etcd

🎯 Objectif

Protéger l’état du cluster en réalisant une sauvegarde
de la base de données etcd.

📋 Travail demandé

Vérifiez que l’instance etcd est accessible sur son endpoint local.
Préparez les variables nécessaires à l’authentification TLS :
certificat client, clé privée et autorité de certification.
Utilisez etcdctl snapshot save pour créer
une sauvegarde de la base de données.

Exercice 5 : Mise à jour sécurisée du Control Plane

🎯 Objectif

Réaliser une opération de maintenance sur un Control Plane
en limitant les risques pour les workloads exécutés sur le nœud.

📋 Travail demandé

Isolez le nœud avec kubectl drain.
Prenez soin de gérer les Pods contrôlés par des DaemonSets.
Analysez le plan de mise à jour avec
kubeadm upgrade plan.
Appliquez ensuite la mise à jour avec
kubeadm upgrade apply.

💡 L’astuce du jour

Ne cherchez pas à tout retenir par cœur.

Pour la préparation au CKA, il est beaucoup plus intéressant
d’apprendre à retrouver rapidement une information dans
la documentation officielle Kubernetes.

Familiarisez-vous notamment avec
kubectl explain et les pages de référence.
La documentation sera votre meilleure alliée le jour de l’examen.
Mon retour d’expérience sur la préparation au CKA et les liens utiles.

🏁 À demain pour la suite

Cette première journée vous a permis de revoir les opérations
fondamentales nécessaires à l’administration d’un cluster :
déploiement d’une application, initialisation avec
kubeadm, ajout d’un nœud, sauvegarde d’etcd
et préparation d’une mise à jour.

À vous maintenant de passer à la pratique !

Les solutions détaillées des cinq exercices seront publiées demain.
Rendez-vous pour le Jour 2 🚀

Mon retour d’expérience CKA

by Nicolas DELAHAYE | Août 16, 2026 | Certifications CKA, CKAD, CKS

Aujourd’hui, j’ai décidé de te partager mon expérience de préparation à la CKA (Certified Kubernetes Administrator). Sache que je ne suis pas un administrateur Kubernetes de profession. Je suis Architecte Solution : mon quotidien, c’est de concevoir les clusters et la manière dont les applications s’y déploient. La gestion quotidienne (Ops) du cluster n’est donc clairement pas une activité que je réalise à la main tous les jours.

Tu te demandes alors : Pourquoi passer la CKA et pas la CKAD ? C’est simple, j’ai plutôt besoin des compétences de la CKS (Certified Kubernetes Security Specialist) dans mon univers professionnel qui nécessite une sécurité renforcée. Or, pour obtenir la CKS, le prérequis absolu est d’avoir la CKA. Bien sûr, je pourrais me contenter de suivre une formation sur la sécurité de Kubernetes, mais pourquoi m’arrêter là ? C’est un challenge personnel et professionnel. Les certifications (même si elles doivent être renouvelées tous les 2 ans) forcent à se maintenir à niveau. C’est aussi un excellent ticket pour maintenir un haut niveau d’employabilité.

Maintenant que le contexte est posé, voici mon plan d’attaque pour la préparation à la CKA.

Ma méthode d’apprentissage :

La documentation officielle : Incontournable. Leur site est très bien fait. Je retiens particulièrement la section sur les configurations d’objets Kubernetes et les cas d’usage.
Les blogs et vidéos YouTube : Pour la vulgarisation et les retours d’expérience.
La pratique acharnée : C’est le plus formateur. Quand on n’est pas SRE, c’est difficile de voir des problèmes variés au quotidien. Il faut donc s’imposer des exercices.

1. Les Ressources de Formation

Formations en ligne (Gratuites)

Les bases de Kubernetes : kubernetes.io/docs/tutorials/kubernetes-basics/
L’initiation à Kubernetes (edX) : LinuxFoundationX LFS158x
L’excellent blog de Stéphane Robert : blog.stephane-robert.info (Une mine d’or en français)

Formations en ligne (Payantes)

Les fondamentaux (Linux Foundation) : Kubernetes Fundamentals (LFS258)
KillerCoda (Scénarios interactifs) : killercoda.com/course/cka (Un excellent investissement)

Note : J’ai opté pour le pack d’apprentissage annuel de la Linux Foundation. Dans notre métier où tout évolue vite, se former est une discipline de vie. Je n’attends pas toujours que mon employeur ou le CPF finance ces formations.

2. Les Exercices de Préparation

Avec le voucher de l’examen, vous avez droit à deux passages sur le simulateur officiel (Killer.sh). Ne les prenez pas à la légère !

Le simulateur est souvent plus difficile que l’examen lui-même. Lors de mon premier passage, mon niveau de manipulation était trop juste.
Le temps est une composante cruciale : j’ai eu 9/74 dans les 2 premières heures, puis j’ai mis 11h au total pour boucler le reste (score final 68/74).
La correction fournie est géniale : elle montre souvent des chemins beaucoup plus courts (commandes impératives) pour arriver au même résultat.

> ⚠️ Attention à l’environnement :
Le passage sur l’environnement de l’examen m’a perturbé car les raccourcis clavier (notamment le copier/coller) diffèrent de ceux de mon Mac. Entraînez-vous dans les mêmes conditions !

3. Les Conditions de l’Examen

Un environnement strict : Navigateur vierge, bureau vide, pas de livres, pas de double écran, et pas de papier/crayon ! (Très dur quand on a l’habitude de dessiner des architectures pour débugger).
100% Pratique : Aucun QCM. Vous résolvez des problèmes sur des clusters live (mise en place HA, déploiements, sécurité, et surtout corriger des installations cassées).

4. Les Thèmes de l’Examen & Documentation Officielle

Domain 1 : Cluster Architecture, Installation & Configuration 25%

Mise en place et configuration avec kubeadm, gestion du RBAC, certificats TLS, HA du control plane, mise à jour du cluster et backup/restore d’etcd.

Outils : kubeadm, kubectl, etcdctl, kubelet, crictl, openssl.
Références officielles à bookmark :– Installation kubeadm– Backup / Restore etcd– RBAC

Domain 2 : Workloads & Scheduling 15%

Déploiements, rolling updates, rollbacks, ConfigMaps, Secrets, contraintes de planification (nodeSelector, taints/tolerations, affinity), ressources limits et HPA.

Outils : kubectl rollout, scale, autoscale.
Références officielles à bookmark :– Deployments– Taints & Tolerations– ConfigMaps

Domain 3 : Services & Networking 20%

Modèle réseau, Services, Ingress, NetworkPolicies. Résolution DNS (CoreDNS) et fonctionnement de kube-proxy.

Outils : CoreDNS, Ingress Controllers, netshoot, port-forward.
Références officielles à bookmark :– Services– Network Policies– Ingress

Domain 4 : Storage 10%

Volumes persistants (PV), Claims (PVC), StorageClasses et access modes (RWO, RWX).

Références officielles à bookmark :– Persistent Volumes– Storage Classes

Domain 5 : Troubleshooting 30%

Le gros morceau. Diagnostic de pods (CrashLoopBackOff, ImagePullBackOff), vérification des composants du control plane, analyse des logs système.

Outils : kubectl describe/logs/events, journalctl, crictl.
Références officielles à bookmark :– Troubleshoot Clusters– Debug Running Pods

5. Les 5 Erreurs Classiques à Éviter

Erreur 1 : Négliger la pratique. La CKA est 100% pratique, faire au minimum 100h de manipulation kubectl est indispensable.

Erreur 2 : Écrire tous les YAML from scratch. Utilisez toujours kubectl ... --dry-run=client -o yaml > file.yaml.

Erreur 3 : Mal gérer son temps. Sautez les questions difficiles et revenez-y plus tard. Priorisez celles avec un fort coefficient de points.

Erreur 4 : Oublier de changer de contexte. Exécutez toujours kubectl config use-context <nom> avant chaque question.

Erreur 5 : Ne pas tester sa solution. Vérifiez toujours avec un kubectl get ou describe que l’état attendu est atteint.

6. Mes Exercices Pratiques (Exemples)

Q1. Création rapide de Pod

Enoncé : Vous devez créer un pod nommé nginx-pod utilisant l’image nginx:1.25, dans le namespace production, avec une limite mémoire de 256Mi.

$ kubectl run nginx-pod –image=nginx:1.25 -n production –dry-run=client -o yaml > pod.yaml
# Editer le fichier pod.yaml pour ajouter la section resources.limits.memory

Explication : La commande imperative kubectl run est la plus rapide. Attention, l’ancienne syntaxe avec --limits a été dépréciée dans les versions récentes pour les pods simples. Générer le YAML avec --dry-run et l’éditer avec vi reste la méthode la plus fiable et rapide à l’examen.

Q2. Diagnostic de Planification (Scheduling)

Enoncé : Un pod reste en état ‘Pending’. kubectl describe pod indique FailedScheduling: 0/3 nodes are available: 3 node(s) had untolerated taint.

Solution attendue : Ajouter une toleration dans le manifeste du Pod (spec.tolerations) correspondant aux taints présents sur les nœuds cibles.

Explication : Les taints empêchent la planification des pods qui n’ont pas la tolération correspondante. Retirer les taints des nœuds fonctionnerait techniquement, mais c’est une mauvaise pratique qui casse la conception de l’architecture. Comprendre la différence entre taints/tolerations (répulsion) et nodeAffinity (attraction) est crucial.

Q3. Backup ETCD

Enoncé : Vous devez sauvegarder la base de données etcd avant une mise à jour majeure. Quelle est la procédure ?

$ ETCDCTL_API=3 etcdctl –endpoints=https://127.0.0.1:2379 \
–cacert=/etc/kubernetes/pki/etcd/ca.crt \
–cert=/etc/kubernetes/pki/etcd/server.crt \
–key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /tmp/etcd-backup.db

Explication : etcd nécessite l’API v3 et l’authentification mutuelle TLS. Oublier les certificats fera échouer la commande. Cette question tombe systématiquement à l’examen : mémorisez les chemins des certificats /etc/kubernetes/pki/etcd/ par cœur !

GitHub Actions : Pourquoi « needs » et « if » ne font pas la même chose ?

by Nicolas DELAHAYE | Jan 14, 2026 | CI/CD

> gh workflow --debug dependencies_

needs vs if : Maîtriser le flux GitHub Actions

Par Nicolas DELAHAYE | Coach DevSecOps

STATUS: PIPELINE_LOGIC_ANALYSIS

Introduction : Le syndrome du Pipeline "Domino"

Imaginez un chantier où le peintre commence à peindre les murs alors que les maçons n'ont pas encore fini de monter la brique. C'est exactement ce qui arrive dans vos pipelines GitHub Actions quand la logique de dépendance est floue.

Le problème est classique : on veut qu'un job ne s'exécute pas tant qu'un autre n'est pas terminé. Intuitivement, on cherche une condition. On hésite entre forcer un ordre (needs) ou vérifier une validation (if).

Pourtant, ces deux attributs ne jouent pas dans la même cour. L'un construit le squelette de votre CI/CD, l'autre en est le garde-fou. Si vous les confondez, vous créez des pipelines "magiques" ou instables où les données ne circulent pas et où les échecs ne sont pas correctement interceptés.

1. Le Modèle Mental : Structure vs Logique

Avant de toucher au YAML, retenez cette distinction fondamentale :

needs = Dépendance Structurelle : Définit l'ordonnancement du graphe (le "Quand").
if = Condition Logique : Définit l'autorisation d'exécuter (le "Si").

"Needs définit l'ordre, If décide du droit de passage."

2. needs : La Dépendance Forte

needs agit au niveau du scheduler de GitHub Actions. C'est lui qui dessine les boîtes et les flèches dans votre interface visuelle.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Compilation terminée"

  test:
    needs: build # Dépendance explicite
    runs-on: ubuntu-latest
    steps:
      - run: echo "Exécution des tests"

Pourquoi l'utiliser ?

Chaînage : Pour accéder aux outputs du job précédent (impossible sans needs !).
Sécurité : Si le job build échoue, le job test est automatiquement annulé (skippé).

3. if : Le Garde-Fou

if intervient au moment de l'exécution. Le job est planifié, mais avant de démarrer, l'exécuteur vérifie la condition.

jobs:
  deploy:
    runs-on: ubuntu-latest
    # Condition basée sur le contexte, pas sur un autre job
    if: github.ref == 'refs/heads/main'
    steps:
      - run: echo "Déploiement en Prod"

Exemple de contexte métier :

Utilisez if: failure() pour envoyer une notification Slack uniquement si le pipeline plante.

4. Comparatif Stratégique

Critère	needs	if
Niveau	Structure du pipeline	Logique d'exécution
Ordonnancement	Oui (Graphe)	Non
Accès aux outputs	Oui	Non
Usage principal	Étapes logiques	Règles métier / Branches

5. La Règle d'Or du Pipeline Mature

⚡ LE MANTRA À GRAVER DANS LE MARBRE :

👉 Si un job dépend d’un autre (ordre) → utilisez needs
👉 Si un job dépend d’un contexte (branche, tag, event) → utilisez if

Dans un environnement industriel, on ne choisit pas l'un contre l'autre. On les combine :

  deploy-prod:
    needs: [test, security-scan]        # ORDRE : J'attends que les tests soient verts
    if: github.ref == 'refs/heads/main' # CONTEXTE : Je ne déploie que si je suis sur Main
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

C'est le modèle recommandé : needs garantit l'intégrité structurelle (le "quand"), et if garantit la conformité logique (le "pourquoi").

6. Regard de Coach : Le pipeline est un produit

Au-delà de la syntaxe YAML, comprendre cette différence relève de la culture Craftsmanship.

🛡️ Lisibilité : Un pipeline avec des needs bien placés est auto-documenté.
🛡️ Intention : Ne cachez pas une dépendance derrière un if complexe. Rendez-la explicite.
🛡️ Robustesse : Un pipeline "plat" (sans needs) est un risque de sécurité : vos jobs pourraient s'exécuter en parallèle et déployer un code non testé.

Kubernetes Gateway API : Le Guide Complet de Migration depuis Ingress

by Nicolas DELAHAYE | Jan 9, 2026 | Kubernetes

> kubectl convert --from=ingress --to=gateway-api --dry-run_

Dossier : Migration de Ingress vers Gateway API

Par Nicolas DELAHAYE | v.1974 | Architecte Solution STATUS: NETWORK_ARCHITECTURE_UPGRADE

1. Le Constat : Pourquoi tuer l'Ingress ?

Pendant des années, l'objet Ingress a été le standard de facto. Couplé à des contrôleurs comme NGINX, Traefik ou HAProxy, il a fait le travail. Mais soyons honnêtes, à l'échelle, c'est devenu un cauchemar de maintenance. Les limites sont structurelles :

L'enfer des Annotations : Pour faire du rate-limiting ou du rewrite, vous injectez des annotations spécifiques au contrôleur (vendor lock-in).
Tout ou rien : L'objet Ingress mélange la configuration de l'infrastructure (TLS, IP) et le routage applicatif (Paths). Difficile de séparer les rôles Ops et Dev.
HTTP Only : Pas de support natif propre pour TCP, UDP ou gRPC sans "hacks".

2. Gateway API : Une Révolution Architecturale

La Gateway API n'est pas une v2 de l'Ingress. C'est une refonte complète basée sur une architecture orientée Rôles. Elle introduit plusieurs ressources (CRDs) pour découpler les responsabilités.

👥 Qui gère quoi ?

GatewayClass (Infra Provider) : Définit le moteur sous-jacent (NGINX, Istio, Cilium).
Gateway (Ops / Platform Team) : Définit les points d'entrée, les ports, le TLS et les IP. C'est le "Load Balancer".
HTTPRoute / TCPRoute (Dev Team) : Définit les règles de routage vers les services. Les devs ne touchent plus à l'infra !

3. Comparatif Technique : Avant vs Après

Regardons concrètement comment la configuration évolue d'un modèle monolithique à un modèle distribué.

L'Ancien Monde (Ingress)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-legacy
  annotations:
    # Dépendance forte à l'implémentation NGINX
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /old
        backend:
          service:
            name: app-svc
            port:
              number: 80

Le Nouveau Monde (Gateway API)

Ici, l'Ops configure le Gateway une fois pour toutes :

# Géré par l'équipe PLATEFORME
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: gateway-system
spec:
  gatewayClassName: nginx-gateway
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-cert
      allowedRoutes:
        namespaces:
          from: All # Autorise les apps des autres namespaces à s'attacher

Et le développeur déclare simplement sa route, sans se soucier du certificat SSL ou de l'IP :

# Géré par l'équipe APP (Namespace distinct)
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: my-app
spec:
  parentRefs:
    - name: shared-gateway
      namespace: gateway-system
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /new
      backendRefs:
        - name: app-svc
          port: 80

4. Les "Killer Features" impossibles avec Ingress

🚀 Traffic Splitting (Canary natif)

Plus besoin de Service Mesh lourd (Linkerd/Istio) juste pour faire du Canary. C'est natif :

  rules:
    - backendRefs:
        - name: app-v1
          port: 80
          weight: 90  # 90% du trafic
        - name: app-v2
          port: 80
          weight: 10  # 10% du trafic (Canary)

🛡️ Multi-Protocoles

L'API ne s'arrête pas au HTTP. Vous avez besoin d'exposer une base de données ou un flux vidéo ?

kind: TCPRoute → Pour vos bases de données.
kind: UDPRoute → Pour le streaming ou le gaming.
kind: GRPCRoute → Pour vos microservices modernes.

5. Stratégie de Migration : Le plan "Zero Downtime"

Ne faites pas de "Big Bang". La Gateway API permet la coexistence. Voici la stratégie que je recommande pour les clusters en production :

Phase	Action	Impact
1. Préparation	Installer les CRDs Gateway API et configurer la `GatewayClass`.	Aucun (Infrastructure only).
2. Double Stack	Déployer les `HTTPRoute` en parallèle des Ingress existants.	Double exposition. Permet de tester les nouvelles routes via `curl --resolve`.
3. Switch DNS	Mise à jour du DNS pour pointer vers l'IP du Gateway LoadBalancer.	Le trafic bascule. Rollback possible par simple DNS.
4. Cleanup	Suppression des anciens objets Ingress.	Migration terminée.

6. Intégration Helm & GitOps (ArgoCD)

Pour industrialiser cela, modifiez vos Chartes Helm pour supporter conditionnellement les deux modes via le fichier values.yaml :

# values.yaml pattern
gateway:
  enabled: true
  className: nginx-gateway
  host: app.example.com

# template/httproute.yaml
{{- if .Values.gateway.enabled }}
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: {{ include "app.fullname" . }}
spec:
  parentRefs:
    - name: {{ .Values.gateway.className }}
  hostnames:
    - {{ .Values.gateway.host }}
  rules:
    ...
{{- end }}

Cette approche permet de migrer application par application dans ArgoCD en changeant simplement un flag booléen.

📚 Ressources Officielles & Documentation

Sujet	Source	Lien
Spec & Concepts	Kubernetes.io Docs	Docs Officielles
Migration Guide	Gateway API SIG	Guide Migration
GKE Implementation	Google Cloud	GKE Guide

Choisir son Git Workflow : Pourquoi ce n’est pas un choix technique, mais une stratégie produit

by Nicolas DELAHAYE | Jan 9, 2026 | DevSecOps

> git logic --analyze-team-culture --verbose_

Choisir son Flow : Le miroir de votre organisation

Par Nicolas DELAHAYE | Article Pilier | Stratégie & DevOps

STATUS: ARCHITECTURAL_ANALYSIS_IN_PROGRESS

L'Erreur Originelle : Le Flow comme simple outil

Dans l'univers du développement logiciel, une conversation revient inlassablement lors du lancement d'un projet : "Quel workflow Git allons-nous utiliser ?". Trop souvent, la réponse est technique : "On va faire du GitFlow parce que c'est robuste" ou "GitHub Flow, c'est ce que font les start-ups, c'est plus moderne".

C'est une erreur fondamentale de jugement. Choisir son flux de gestion de branches n'est pas une décision technique comparable au choix d'une base de données ou d'un framework JavaScript. Votre Git Flow est le reflet direct de votre gestion de produit, de la confiance interne de votre équipe et de votre tolérance au risque.

Si votre workflow Git frotte, c'est souvent parce qu'il est en désaccord avec votre réalité organisationnelle. Un workflow complexe comme GitFlow peut paralyser une équipe agile cherchant le déploiement continu, tandis qu'un flux trop simple comme GitHub Flow peut mettre en danger une équipe soumise à des régulations strictes.

1. L'impact du Cycle de Développement et du Cadre (Frameworks)

La première contrainte qui doit guider votre choix est le rythme cardiaque de votre projet. Comment planifiez-vous la valeur que vous livrez ?

Le Mode Cascade / Cycle en V (Prince 2, PMI)

Dans des environnements régulés ou des projets au forfait classique, le cycle de développement est souvent prédictif. On spécifie, on développe, on teste, on livre. Les versions majeures sortent tous les 3 ou 6 mois.

Ici, le flow doit supporter la notion de "Release" figée. Vous avez besoin de stabiliser une version tout en continuant à développer la suivante. GitFlow est structurellement adapté à ce besoin. Il permet de maintenir plusieurs versions en parallèle et de gérer rigoureusement les correctifs.

Le Mode Agile Itératif (Scrum)

En Scrum, le rythme est dicté par le Sprint (souvent 2 semaines). À la fin du Sprint, vous devez avoir un incrément potentiellement livrable.

Le flow doit ici supporter une branche d'intégration (souvent Develop) qui accumule les fonctionnalités validées pendant le sprint. Cependant, la lourdeur de GitFlow peut commencer à peser si l'équipe souhaite livrer pendant le sprint.

Le Mode Flux Tendu (Kanban / Lean)

En Kanban, il n'y a plus de notion de "lot" ou de "version" au sens classique. Une fonctionnalité est prête ? Elle part en production.

Dans ce contexte, toute branche de "longue durée" (comme une branche Develop qui ne serait mergée que tous les mois) devient un stock, donc un déchet. Ici, un flow comme GitHub Flow, basé sur une branche principale unique et des déploiements fréquents, est impératif[.

2. Les Normes de l'Équipe : Solo, Pair ou Mercenaire ?

La sociologie de votre équipe influence la manière dont le code doit transiter. Le workflow est aussi un outil de contrôle qualité et de communication.

Le cas du "Mercenaire" ou de l'équipe distribuée

Si vous travaillez avec des freelances, des contributeurs Open Source ou des équipes hétérogènes avec un turnover élevé, la confiance "par défaut" n'est pas toujours possible. Votre flow doit agir comme un sas de sécurité.

La branche Main (ou Master) devient un sanctuaire. Personne ne push dessus. Le workflow doit imposer des Feature Branches strictes et le passage obligatoire par des Merge Requests (MR) ou Pull Requests. C'est le "Gatekeeper" (Tech Lead) qui valide l'entrée.

Le cas du "Pair Programming" et du "Mob Programming"

À l'inverse, si votre équipe pratique le Pair Programming intensif, la revue de code est effectuée en temps réel, pendant l'écriture.

Imposer une Pull Request formelle et attendre 4h qu'un collègue la valide est un gaspillage pur. Ces équipes s'orientent souvent vers du Trunk-Based Development ou un GitHub Flow très accéléré, car la qualité est injectée à la source, pas au contrôle final.

3. Le conflit de pouvoir : Qui tient le manche du déploiement ? (Dev vs Ops)

C'est souvent l'angle mort des choix de workflow. Qui a la responsabilité de la mise en production ? Cette question définit la direction du flux : Push ou Pull ?

Scénario A : Le modèle "Push" (Pression sur l'Ops)
L'équipe de développement considère que son travail est fini quand la fonctionnalité est mergée sur Main. Elle "pousse" le code.
Impact sur le Flow : Cela implique souvent l'utilisation de GitHub Flow ou de CI/CD automatisé[. L'Ops (ou la plateforme) subit le rythme des développeurs. Si le pipeline est vert, ça part en prod. C'est le modèle des équipes "You build it, you run it".

Scénario B : Le modèle "Pull" (Responsabilité Ops)
Ici, l'équipe Ops (ou SRE) est garante de la stabilité. Elle refuse que chaque merge parte en prod automatiquement.
Impact sur le Flow : L'équipe Dev livre un package (un Tag) ou met à jour une branche de Release. L'Ops décide quand il "tire" (pull) ce tag pour le déployer.
C'est là que GitLab Flow brille particulièrement. Il permet de réconcilier ces deux mondes en introduisant des branches d'environnement (ex: production, pre-production). Les devs mergent sur Main, mais le déploiement effectif ne se fait que lorsque l'on merge (ou cherry-pick) vers la branche de production.

4. Anatomie des options : De la théorie à la pratique Git

Maintenant que le contexte humain est posé, regardons comment cela se traduit techniquement. Comme vous l'avez mentionné, la gestion des branches est la clé de voûte du système.

Les Branches Canoniques

Peu importe le flow, vous manipulerez ces concepts :

Master/Main Branch : Représente l'état "prêt pour la production" du code. C'est la vérité terrain.
Develop Branch : Le point d'intégration pour les nouvelles fonctionnalités. C'est le "brouillon propre" de la prochaine version.
Feature Branches : Créées depuis develop (ou main selon le flow) pour implémenter une nouveauté. Elles isolent le travail en cours.
Release Branches : Branchées depuis develop pour préparer une livraison (gel du code, tests finaux, documentation).
Hotfix Branches : Créées depuis master pour corriger une urgence en prod. C'est le "pompier" du système.

Option 1 : GitFlow (Le "Structured Approach")

Conçu par Vincent Driessen, c'est le modèle le plus strict. Il utilise toutes les branches citées ci-dessus.

Fonctionnement : On développe sur feature, on merge sur develop. Quand on est prêt, on crée une release. Une fois validée, elle est mergée sur main ET sur develop.
Pour qui ? Les grandes équipes, les projets complexes, ceux qui ont des cycles de release planifiés.
Le piège : La complexité de gestion des merges et la lourdeur pour un simple fix.

Option 2 : GitHub Flow (Le "Agile Approach")

Une approche simplifiée, populaire pour le déploiement continu.

Fonctionnement : Il n'y a que main et des feature branches . Une feature terminée = une Pull Request = un Merge sur Main = un Déploiement .
Pour qui ? Les petites/moyennes équipes, les start-ups, ceux qui veulent itérer très vite.
Le piège : La branche main peut devenir instable si les tests (CI) ne sont pas bétons, car tout merge est potentiellement en prod.

Option 3 : GitLab Flow (Le "Middle Ground")

Une alternative qui tente de résoudre les manques de GitFlow (trop complexe) et de GitHub Flow (trop simpliste pour la prod complexe) .

Fonctionnement : Le développement se fait sur main (comme GitHub Flow), mais on ajoute des branches "d'environnement" ou de "release" en aval (ex: pre-production, production). On merge de l'une vers l'autre pour promouvoir le code.
Pour qui ? Les équipes qui font du CI/CD mais qui ont besoin de valider manuellement des environnements (UAT, Staging) avant la prod.

5. Checklist de Décision : Trouvez votre Flow

Avant de lancer git init, réunissez votre Tech Lead, votre Product Owner et votre Ops, et répondez à ces questions :

📋 La Matrice de Choix

□ Avez-vous besoin de maintenir plusieurs versions en production (v1.0, v2.0) ?
Oui → GitFlow (ou GitLab Flow avec branches release ). Non → GitHub Flow.
□ Quelle est la fréquence de vos déploiements ?
Plusieurs fois par jour → GitHub Flow. Une fois toutes les 2 semaines/mois → GitFlow.
□ Votre équipe est-elle Junior ou Senior ?
Junior → GitFlow peut structurer et rassurer. Senior/Autonome → GitHub Flow libère la vélocité.
□ Avez-vous des environnements de validation stricts (QA, UAT) avant la Prod ?
Oui → GitLab Flow est idéal pour mapper les branches aux environnements.
□ Qui déploie ?
C'est automatisé au merge → GitHub Flow. C'est l'Ops qui décide → GitLab Flow ou GitFlow.

📚 Sources & Documentation Officielle

// Liste des pointeurs mémoire utilisés pour cette analyse :

ID	Sujet	Source / Article	Lien
REF_01	GitFlow & GitLab Flow	GitLab Blog : Comparatif technique et usages	[ACCESS_LINK]
REF_02	GitHub Flow vs GitFlow	TheLinuxCode : Mastering Git Workflows	[ACCESS_LINK]
REF_03	Documentation	Atlassian Git Tutorials	[ACCESS_LINK]
REF_04	Git Flow & Github Flow	Git Flow vs Github Flow	[ACCESS_LINK]
REF_05	Github Flow	Github Flow	[ACCESS_LINK]

🚀 Jour 1 : Administration du Cluster et Déploiements Fondamentaux

🎯 Le thème du jour : les fondations de l’administration

🛠️ Aperçu des exercices du jour

💻 Les 5 défis pratiques

📚 Les réponses demain

🏁 À demain !

Exercice 1 : Déploiement d’une application simple

🎯 Objectif

📋 Travail demandé

Exercice 2 : Initialisation du cluster avec kubeadm

🎯 Objectif

📋 Travail demandé

BONUS

Exercice 3 : Agrandissement du cluster

🎯 Objectif

📋 Travail demandé

Bonus Créer un second noeud worker et ajouter le au cluster.

Exercice 4 : Sauvegarde de la base de données etcd

🎯 Objectif

📋 Travail demandé

Exercice 5 : Mise à jour sécurisée du Control Plane

🎯 Objectif

📋 Travail demandé

💡 L’astuce du jour

🏁 À demain pour la suite

Mon retour d’expérience CKA

> Mon retour d’expérience CKA

1. Les Ressources de Formation

Formations en ligne (Gratuites)

Formations en ligne (Payantes)

2. Les Exercices de Préparation

3. Les Conditions de l’Examen

4. Les Thèmes de l’Examen & Documentation Officielle

Domain 1 : Cluster Architecture, Installation & Configuration 25%

Domain 2 : Workloads & Scheduling 15%

Domain 3 : Services & Networking 20%

Domain 4 : Storage 10%

Domain 5 : Troubleshooting 30%

5. Les 5 Erreurs Classiques à Éviter

6. Mes Exercices Pratiques (Exemples)

Q1. Création rapide de Pod

Q2. Diagnostic de Planification (Scheduling)

Q3. Backup ETCD

GitHub Actions : Pourquoi « needs » et « if » ne font pas la même chose ?

Introduction : Le syndrome du Pipeline "Domino"

1. Le Modèle Mental : Structure vs Logique

2. needs : La Dépendance Forte

3. if : Le Garde-Fou

4. Comparatif Stratégique

5. La Règle d'Or du Pipeline Mature

⚡ LE MANTRA À GRAVER DANS LE MARBRE :

6. Regard de Coach : Le pipeline est un produit

Kubernetes Gateway API : Le Guide Complet de Migration depuis Ingress

1. Le Constat : Pourquoi tuer l'Ingress ?

2. Gateway API : Une Révolution Architecturale

👥 Qui gère quoi ?

3. Comparatif Technique : Avant vs Après

L'Ancien Monde (Ingress)

Le Nouveau Monde (Gateway API)

4. Les "Killer Features" impossibles avec Ingress

🚀 Traffic Splitting (Canary natif)

🛡️ Multi-Protocoles

5. Stratégie de Migration : Le plan "Zero Downtime"

6. Intégration Helm & GitOps (ArgoCD)

📚 Ressources Officielles & Documentation

Choisir son Git Workflow : Pourquoi ce n’est pas un choix technique, mais une stratégie produit

L'Erreur Originelle : Le Flow comme simple outil

1. L'impact du Cycle de Développement et du Cadre (Frameworks)

Le Mode Cascade / Cycle en V (Prince 2, PMI)

Le Mode Agile Itératif (Scrum)

Le Mode Flux Tendu (Kanban / Lean)

2. Les Normes de l'Équipe : Solo, Pair ou Mercenaire ?

Le cas du "Mercenaire" ou de l'équipe distribuée

Le cas du "Pair Programming" et du "Mob Programming"

3. Le conflit de pouvoir : Qui tient le manche du déploiement ? (Dev vs Ops)

4. Anatomie des options : De la théorie à la pratique Git

Les Branches Canoniques

Option 1 : GitFlow (Le "Structured Approach")

Option 2 : GitHub Flow (Le "Agile Approach")

Option 3 : GitLab Flow (Le "Middle Ground")

Bonus
Créer un second noeud worker et ajouter le au cluster.

Oh bonjour 👋
Ravi de vous rencontrer.