Unité 5.3 : GitOps et opérations de déploiement

Introduction

Vous avez un déploiement TaskBoard fonctionnel sur Managed Kubernetes, un pipeline CI/CD qui construit et pousse des images, et Terraform qui met en place le Cluster. Le problème est la dérive. Quelqu'un exécute kubectl edit pour corriger un déploiement de production, l'état en direct diverge de ce qui est dans Git, et la prochaine exécution du pipeline le rétablit silencieusement ou, pire, échoue. GitOps résout ce problème en faisant d'un référentiel Git la source unique de vérité et en exécutant un contrôleur à l'intérieur du Cluster qui tire continuellement l'état souhaité et réconcilie l'état en direct pour qu'il corresponde.

Dans cette unité, vous configurez ArgoCD sur votre MKS Cluster, le connectez au référentiel de manifeste de TaskBoard, et le voyez s'auto-réparer les modifications manuelles. Vous séparez le référentiel que Terraform possède (le Cluster, le réseau, les bases de données) du référentiel que ArgoCD possède (les manifestes Kubernetes), afin que les deux contrôleurs ne s'écrasent jamais l'un l'autre. Enfin, vous automatiserez la suppression de l'environnement de branche, de sorte qu'une branche de fonctionnalité fasse démarrer son propre espace de noms et le détruise lors de la fusion ou de la fermeture.

1. Principes GitOps et la boucle de réconciliation basée sur le pull

GitOps inverse la direction de déploiement habituelle. Au lieu d'un exécuteur CI qui pousse kubectl apply dans le Cluster de l'extérieur (modèle push), un contrôleur s'exécutant à l'intérieur du Cluster extrait l'état souhaité de Git et l'applique (modèle pull). L'engagement Git est le déclencheur de déploiement, le journal d'audit et le mécanisme de restauration en un seul. Pour restaurer, vous rétablissez l'engagement et le contrôleur rétablit l'état précédent.

Trois propriétés définissent un système GitOps : l'état souhaité entier est déclaratif et stocké dans Git, le contrôleur compare en permanence l'état souhaité à l'état réel, et toute divergence (dérive) est soit signalée, soit corrigée automatiquement. Sur IONOS MKS, cela est important car le Cluster exécute déjà des boucles de réconciliation de son propre chef pendant la fenêtre de maintenance hebdomadaire, donc la réconciliation de votre application doit coexister avec les modifications déclenchées par la plateforme.

1.1 État déclaratif dans Git

Tout ce qu'ArgoCD gère est un fichier Kubernetes YAML plain commité dans un référentiel. Il n'y a pas de code kubectl run impératif dans un flux de travail GitOps. Un manifeste de déploiement minimal TaskBoard ressemble à ceci :

# apps/taskboard/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: taskboard-api
  namespace: taskboard
spec:
  replicas: 2
  selector:
    matchLabels:
      app: taskboard-api
  template:
    metadata:
      labels:
        app: taskboard-api
    spec:
      imagePullSecrets:
        - name: cr-pull-secret
      containers:
        - name: api
          image: my-registry.cr.de-fra.ionos.com/taskboard-api:GIT_SHA
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5

La balise image porte un SHA Git plutôt qu'un latest. C'est le levier de promotion : modifier la balise dans Git est ce qui déclenche un nouveau déploiement, et la balise vous indique exactement quel engagement est en cours d'exécution.

1.2 Détection de dérive et auto-réparation

Lorsqu'une personne exécute kubectl scale deployment/taskboard-api --replicas=5 directement contre le Cluster, l'état réel ne correspond plus à Git, qui indique toujours replicas: 2. Un contrôleur GitOps en mode auto-réparation détecte cette différence lors de son prochain cycle de synchronisation et réduit à nouveau à 2. La leçon pour votre équipe est opérationnelle : le Cluster est en lecture seule pour les humains. Tous les changements passent par une demande de tirage.

# This manual change will be reverted by ArgoCD self-heal
kubectl -n taskboard scale deployment/taskboard-api --replicas=5

# Within the sync interval, ArgoCD reports OutOfSync, then heals back to 2
argocd app get taskboard --refresh

2. Installation et configuration d'ArgoCD sur MKS

ArgoCD est un projet CNCF, et non un produit IONOS, il s'installe donc sur MKS de la même manière qu'il s'installe sur n'importe quel Kubernetes Cluster conforme. Les parties spécifiques à IONOS sont la façon dont vous obtenez le kubeconfig, la façon dont le serveur ArgoCD est exposé (ce qui dépend du modèle LoadBalancer MKS couvert à la section 4), et la façon dont les images sont authentifiées contre le registre de conteneurs IONOS.

2.1 Récupération du kubeconfig et installation d'ArgoCD

Vous provisionnez le Cluster avec Terraform et récupérez le kubeconfig avant d'installer quoi que ce soit. IONOS documente trois chemins de gestion de configuration pour récupérer le fichier kubeconfig : l'interface de ligne de commande ionosctl, Ansible, et Terraform. Avec Terraform, la source de données ionoscloud_k8s_cluster expose le kubeconfig comme un attribut que vous pouvez écrire dans un fichier.

data "ionoscloud_k8s_cluster" "taskboard" {
  id = ionoscloud_k8s_cluster.taskboard.id
}

resource "local_file" "kubeconfig" {
  content         = data.ionoscloud_k8s_cluster.taskboard.kube_config
  filename        = "${path.module}/kubeconfig.yaml"
  file_permission = "0600"
}

Avec le kubeconfig en place, installez ArgoCD dans son propre espace de noms :

export KUBECONFIG=./kubeconfig.yaml

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Wait for the API server to come up on the worker nodes
kubectl -n argocd rollout status deployment/argocd-server

L'ArgoCD Pods planifie sur votre MKS Worker Nodes. Les composants du plan de contrôle gérés par IONOS (le serveur K8s API, CSI, CCM, Calico et CoreDNS) sont mis à jour par IONOS pendant la maintenance et ne sont pas quelque chose que ArgoCD modifie.

2.2 Définition de l'Application CRD

L'objet principal d'ArgoCD est la Application ressource personnalisée. Elle pointe vers un référentiel Git, un chemin à l'intérieur de celui-ci, et une destination Cluster ainsi qu'un espace de noms. automated synchronise avec prune et selfHeal, ce qui le transforme en une véritable boucle GitOps : prune supprime les ressources supprimées de Git, et selfHeal annule les modifications manuelles de Cluster.

# argocd/taskboard-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: taskboard
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/taskboard-manifests.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: taskboard
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Appliquez-le avec kubectl apply -n argocd -f argocd/taskboard-app.yaml. À partir de ce point, chaque validation dans le chemin overlays/prod déclenche une réconciliation.

3. Topologie du référentiel : séparation de l'infrastructure des applications

L'erreur GitOps la plus courante sur IONOS est de mélanger l'infrastructure gérée par Terraform et les applications gérées par ArgoCD dans un même endroit, puis de les regarder se battre. Le modèle propre est celui de deux référentiels avec une limite de propriété claire.

Le référentiel d'infrastructure contient Terraform : ionoscloud_k8s_cluster, ionoscloud_k8s_node_pool, le réseau, les bases de données et le Container Registry. Il s'applique lors de la fusion à main via votre pipeline CI. Le référentiel d'application contient les manifests Kubernetes et les surcharges Kustomize, et ArgoCD les surveille.

3.1 Limite de propriété

La règle est simple : si une ressource est créée par terraform apply, ArgoCD ne doit jamais la gérer, et si une ressource est créée par la synchronisation ArgoCD, Terraform ne doit jamais la gérer. La passation se fait via les sorties. Terraform produit le Cluster et le secret de tirage du registre ; ArgoCD consomme le Cluster et le déploie.

# infrastructure repo: outputs that the app layer consumes
output "k8s_cluster_id" {
  value = ionoscloud_k8s_cluster.taskboard.id
}

output "registry_hostname" {
  value     = ionoscloud_container_registry.taskboard.hostname
  sensitive = false
}

Le tableau suivant définit explicitement la limite pour TaskBoard.

Comme le montre le tableau ci-dessus, les contrôleurs ne partagent jamais un type de ressource, donc l'un ne rétablit pas l'autre.

3.2 La passation du secret d'extraction d'image

Le Container Registry sur IONOS utilise uniquement l'authentification basée sur jeton docker login ; il n'y a pas de RBAC et pas de référentiels par équipe. Le secret de tirage est l'unique information d'identification qui franchit la limite infrastructure-application. Créez-le une fois à partir du jeton de registre, puis référencez-le dans les manifests que ArgoCD synchronise.

kubectl create secret docker-registry cr-pull-secret \
  --docker-server=my-registry.cr.de-fra.ionos.com \
  --docker-username='<token-name>' \
  --docker-password='<registry-token>' \
  --namespace=taskboard

Puisque ce secret contient une information d'identification, ne le commitez pas en texte brut. Créez-le de manière impérative comme ci-dessus (une seule fois, en dehors de Git) ou utilisez un opérateur sealed-secrets ou external-secrets afin qu'ArgoCD puisse gérer une forme chiffrée.

4. Risques de réconciliation spécifiques à IONOS

GitOps suppose que le Cluster se comporte de manière prévisible. Deux comportements de MKS rompent cette hypothèse si vous ne les prenez pas en compte : les nœuds sont immuables et reconstruits plutôt que corrigés, et un service LoadBalancer ne provisionne pas un véritable Load Balancer externe.

4.1 Nœuds immuables et fenêtre de maintenance

Les nœuds de MKS sont immuables. Toute mise à niveau du pool de Node reconstruit chaque Node appartenant au pool plutôt que de le corriger sur place, et les mises à niveau se produisent généralement automatiquement pendant la fenêtre de maintenance hebdomadaire. Cette fenêtre de maintenance est limitée à un maximum de 4 heures. Pendant cette fenêtre, IONOS met à jour tous les composants internes à Cluster, y compris le plan de contrôle, CSI, CCM, Calico et CoreDNS.

L'implication GitOps est que les Pods sont expulsés et rescheduled sur des nœuds fraîchement construits selon un calendrier que vous ne contrôlez pas. Vos manifestes doivent tolérer cela. Définissez des sondes de prêt pour que ArgoCD et les services routent le trafic uniquement vers les Pods prêts, et utilisez un PodDisruptionBudget pour que la reconstruction ne fasse pas disparaître toutes les répliques en même temps.

# Survive node rebuilds during the maintenance window
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: taskboard-api
  namespace: taskboard
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: taskboard-api

Une reconstruction nécessite également une marge de quota de serveur : une reconstruction de Node provisionne un nouveau Node avant de supprimer l'ancien, donc si vous avez épuisé votre quota de serveur contractuel, la reconstruction ne peut pas se terminer. Gardez une marge de quota égale à au moins un Node par pool.

4.2 Le piège du service LoadBalancer

C'est le risque qui surprend la plupart des équipes qui exposent ArgoCD ou TaskBoard. Sur MKS, un Service de type: LoadBalancer n'est pas un véritable Load Balancer externe. IONOS Cloud réserve une adresse IP publique statique et l'attribue en tant qu'adresse IP secondaire à un nœud de travail Node, qui agit comme nœud d'entrée, et kube-proxy NAT le trafic vers le pod cible. L'adresse IP source est perdue à moins que vous ne définissiez externalTrafficPolicy: Local, et le débit est limité à 2 Gbit/s public pour ce seul nœud d'entrée Node.

apiVersion: v1
kind: Service
metadata:
  name: taskboard-api-lb
  namespace: taskboard
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local   # preserve client source IP
  selector:
    app: taskboard-api
  ports:
    - port: 443
      targetPort: 8080

Pour dépasser le plafond d'un seul Node, mettez à l'échelle horizontalement sur plusieurs adresses IP LoadBalancer et nœuds d'entrée en utilisant l'équilibrage de charge DNS, ou placez le service derrière un ALB géré séparément (provisionné dans le référentiel d'infrastructure via Terraform, et non créé automatiquement à partir d'un manifeste). Pour le trafic de production TaskBoard, le chemin ALB est la bonne réponse et garde la préoccupation d'entrée dans la couche possédée par Terraform.

5. Promotion d'environnement et démantèlement éphémère

La promotion entre environnements est une opération Git, et non un script de déploiement. Avec Kustomize, une base partagée contient les manifests et chaque environnement est une superposition qui modifie les comptes de répliques, les limites de ressources et le tag d'image.

5.1 Superpositions Kustomize

La base définit TaskBoard une seule fois ; les superpositions diffèrent par environnement. La promotion d'une version de staging à production est un changement d'un seul tag d'image dans la superposition de production, validé via une demande d'extraction.

# overlays/prod/kustomization.yaml
resources:
  - ../../base
namespace: taskboard
images:
  - name: my-registry.cr.de-fra.ionos.com/taskboard-api
    newTag: 1a2b3c4   # promoted git SHA
patches:
  - path: replicas-patch.yaml

Chaque ArgoCD Application pointe vers un chemin de superposition différent (overlays/dev, overlays/staging, overlays/prod), donc le même référentiel alimente les trois environnements et la différence entre eux est auditable dans Git.

5.2 Environnements de branches éphémères et démontage

Pour les branches de fonctionnalités, vous créez un environnement jetable et le démontez lors de la fusion ou de la fermeture de la branche. Les ressources mises à disposition par Terraform entraînent des frais dès l'application, donc le démontage automatisé est une gouvernance des coûts, et non un luxe. Le travail CI appelle terraform destroy pour la pile de la branche.

# .github/workflows/teardown.yml (triggered on PR close)
name: teardown-branch-env
on:
  pull_request:
    types: [closed]
jobs:
  destroy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Terraform destroy branch stack
        env:
          IONOS_TOKEN: ${{ secrets.IONOS_TOKEN }}
        run: |
          terraform init -backend-config="key=env/pr-${{ github.event.number }}.tfstate"
          terraform destroy -auto-approve -var="env_name=pr-${{ github.event.number }}"

Une chose à considérer lors du nettoyage est spécifique au stockage MKS : les volumes IONOS sont représentés comme des ressources PersistentVolume dans Kubernetes, et la politique de réclamation PV détermine ce qui arrive au Volume sous-jacent lorsque la revendication est supprimée. Si la politique de réclamation est Retain, la suppression de l'espace de noms ou l'exécution de terraform destroy sur le Cluster laisse des volumes IONOS orphelins dans votre VDC qui continuent à facturer. Soit définissez la politique de réclamation sur Delete pour les environnements éphémères, soit nettoyez explicitement les volumes restants après démontage.

API Référence Quick Card

Points de terminaison clés API pour les opérations GitOps et de déploiement sur MKS :

URL de base : https://api.ionos.com/cloudapi/v6 Authentification : Authorization: Bearer <token>

Laboratoire de code

Objectif : Configurer l'auto-synchronisation ArgoCD pour les manifestes TaskBoard sur MKS, pousser un changement de manifeste et observer la réconciliation qui le répare, puis détruire un environnement de branche.

Prérequis :

• Compte IONOS Cloud avec jeton API
• Un MKS Cluster en cours d'exécution provisionné via Terraform (à partir de l'unité 3.2)
• kubectl, argocd CLI, et Terraform installés localement
• Un référentiel Git contenant des manifestes TaskBoard

Étape 1 : Récupérer le kubeconfig à partir de Terraform

terraform output -raw kubeconfig > kubeconfig.yaml
export KUBECONFIG=./kubeconfig.yaml
kubectl get nodes

Sortie attendue :

NAME                STATUS   ROLES    AGE   VERSION
taskboard-pool-1    Ready    <none>   12m   v1.34.x
taskboard-pool-2    Ready    <none>   12m   v1.34.x

Étape 2 : Installer ArgoCD

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd rollout status deployment/argocd-server

Sortie attendue :

deployment "argocd-server" successfully rolled out

Étape 3 : Créer l'Application CRD pointant vers les manifestes TaskBoard

kubectl apply -n argocd -f argocd/taskboard-app.yaml
argocd app get taskboard

Sortie attendue :

Name:               argocd/taskboard
Sync Status:        Synced to main (1a2b3c4)
Health Status:      Healthy

Étape 4 : Introduire manuellement une dérive

kubectl -n taskboard scale deployment/taskboard-api --replicas=5
kubectl -n taskboard get deploy taskboard-api

Sortie attendue :

NAME            READY   UP-TO-DATE   AVAILABLE
taskboard-api   5/5     5            5

Étape 5 : Observer ArgoCD qui se rétablit automatiquement à l'état déclaré par Git

argocd app get taskboard --refresh
sleep 30
kubectl -n taskboard get deploy taskboard-api

Sortie attendue :

NAME            READY   UP-TO-DATE   AVAILABLE
taskboard-api   2/2     2            2

Étape 6 : Promouvoir une nouvelle image via un commit Git

# In the manifests repo, update overlays/prod/kustomization.yaml newTag
git commit -am "promote taskboard-api to 9f8e7d6"
git push origin main
argocd app wait taskboard --sync

Sortie attendue :

taskboard   Synced   Healthy

Étape 7 : Détruire un environnement de branche

terraform init -backend-config="key=env/pr-42.tfstate"
terraform destroy -auto-approve -var="env_name=pr-42"

Sortie attendue :

Destroy complete! Resources: 7 destroyed.

Étape 8 : Vérifier qu'aucun volume orphelin ne reste

ionosctl volume list --datacenter-id $DC_ID

Sortie attendue :

No volumes found  (or: only volumes belonging to retained environments)

Liste de validation :

• [ ] ArgoCD signale Synced et Healthy pour TaskBoard
• [ ] Le changement d'échelle manuel est annulé par l'auto-réparation dans l'intervalle de synchronisation
• [ ] Le commit de l'étiquette d'image déclenche un déploiement sans aucun kubectl apply
• [ ] terraform destroy supprime la pile de branche et ne laisse aucun volume de facturation

Nettoyage :

kubectl delete -n argocd -f argocd/taskboard-app.yaml
kubectl delete namespace argocd
terraform destroy -auto-approve

Pièges courants

Erreurs de développeur à éviter avec GitOps et les opérations de déploiement sur IONOS :

1. Terraform et ArgoCD se disputant la même ressource

   • Problème : Terraform gère un service Kubernetes tandis qu'ArgoCD le synchronise également à partir de Git. Chaque apply et chaque synchronisation annulent l'autre, produisant une boucle de combat infinie et des ressources qui fluctuent.
   • Pourquoi cela se produit : Il n'y a pas de limite de propriété claire entre le référentiel d'infrastructure et le référentiel d'application.
   • Correction : Faites en sorte que Terraform ne possède que l'infrastructure IONOS (Cluster, Node Pools, registre, bases de données) et qu'ArgoCD ne possède que les manifestes in-Cluster. Transmettez le Cluster et le registre entre eux via les sorties de Terraform, et non en faisant en sorte que les deux gèrent le même objet.

2. Exposer ArgoCD ou TaskBoard avec type: LoadBalancer et s'attendre à un équilibreur de charge réel

   • Problème : Toute la charge atterrit sur un worker Node, la source du client IP est perdue, et le débit atteint un plateau autour de 2 Gbit/s sans cause évidente.
   • Pourquoi cela se produit : Un service MKS LoadBalancer ne provisionne pas un Load Balancer externe. IONOS attribue une adresse IP publique statique IP comme adresse IP secondaire à un seul point d'entrée Node et kube-proxy NAT vers le pod.
   • Correction : Définissez externalTrafficPolicy: Local pour conserver l'adresse IP source IP, et pour la production, placez le service devant un ALB géré de la couche Terraform, plutôt que de compter sur le service Node unique.

3. Volumes IONOS orphelins après démantèlement d'un environnement de branche

   • Problème : Vous terraform destroy un environnement de branche, mais vous continuez à être facturé, et des volumes errants persistent dans le VDC.
   • Pourquoi cela se produit : Les volumes IONOS font office de supports pour les PersistentVolumes dont la politique de récupération est Retain, donc la suppression de la revendication ou de l'espace de noms laisse le Volume sous-jacent derrière.
   • Correction : Utilisez une classe de stockage avec une politique de récupération Delete pour les environnements éphémères, ou ajoutez une étape de démantèlement qui répertorie et supprime les volumes restants avec ionosctl volume list et ionosctl volume delete.

Résumé

Vous pouvez maintenant exécuter un flux de travail GitOps basé sur le tirage sur IONOS Managed Kubernetes. ArgoCD réconcilie l'état déclaré de TaskBoard à partir de Git, auto-répare les dérives manuelles, et promeut les constructions à travers les environnements avec un seul commit de balise d'image. Vous gardez Terraform et ArgoCD dans des référentiels séparés avec une limite de propriété propre, de sorte que les deux contrôleurs ne s'écrasent jamais l'un l'autre. Vous connaissez également les deux comportements MKS qui cassent les hypothèses GitOps naïves et comment concevoir autour d'eux.

Le résultat opérationnel est que la production est maintenant en lecture seule pour les humains, chaque modification est un commit examinable, et le retour en arrière est un git revert. Les environnements de branche sont jetables et se détruisent eux-mêmes, et vous évitez le piège de facturation des Volume orphelins en définissant la bonne politique de réclamation.

Points clés :

• GitOps utilise un modèle de tirage : un contrôleur à l'intérieur du Cluster réconcilie l'état désiré de Git, ce qui rend les commits le déclencheur de déploiement et le mécanisme de retour en arrière
• Séparez le référentiel d'infrastructure Terraform-possédé du référentiel d'application ArgoCD-possédé pour éviter les boucles de lutte de réconciliation
• Les nœuds MKS sont immuables et reconstruits pendant la fenêtre de maintenance hebdomadaire (max 4 heures) ; utilisez PodDisruptionBudgets et des sondes de prêt pour que les déploiements survivent aux reconstructions
• Un service MKS LoadBalancer n'est pas un véritable équilibreur de charge externe : une seule entrée Node, perte de source IP à moins que externalTrafficPolicy: Local, et un plafond de 2 Gbit/s ; utilisez un ALB géré pour la production
• Automatisez terraform destroy pour les environnements de branche et définissez la politique de réclamation PV sur Delete pour éviter les volumes orphelins et toujours facturés

Terminologie importante :

• GitOps : Un modèle d'exploitation où Git est la seule source de vérité et un contrôleur à l'intérieur du Cluster réconcilie continuellement l'état vivant pour correspondre à l'état déclaratif commis
• Dérive : Divergence entre l'état vivant du Cluster et l'état désiré déclaré dans Git, causée par des modifications manuelles ou des processus externes
• Auto-réparation : Un mode de synchronisation ArgoCD qui rétablit automatiquement les modifications vivantes à l'état déclaré dans Git
• Politique de réclamation : Le paramètre de volume persistant Kubernetes (Retain ou Delete) qui détermine si le support IONOS Volume est supprimé lorsque sa revendication est supprimée
• Entrée Node : L'entrée unique du travailleur MKS Node qui reçoit une adresse IP publique réservée du service LoadBalancer comme adresse IP secondaire et NAT le trafic vers la cible Pods

Prochaines étapes

Continuer l'apprentissage : Unité 5.4 : Vérification des connaissances - Opérations de production

Sujets connexes :

• Unité 3.3 : Pipelines CI/CD pour IONOS
• Unité 5.2 : Automatisation de la sécurité