Aller au contenu
Pierre Urtado

En production

Cluster Kubernetes installé avec kubeadm et géré en GitOps

J'ai installé ce cluster avec kubeadm, sans distribution prête à l'emploi, pour comprendre chaque composant. Les applications sont décrites dans un dépôt Git, et ArgoCD signale les écarts entre le dépôt et le cluster.

Contexte
Projet personnel (NetSynk)
Période
Depuis 2024
Rôle
Installation, exploitation, migration GitOps
Outils
kubeadm · ArgoCD · Cilium · MetalLB · cert-manager · Falco

Composants

  • Cilium pour le réseau des pods et les règles réseau (eBPF).
  • MetalLB en mode L2 avec deux pools d'adresses, un par VLAN. Deux contrôleurs d'entrée : un pour l'interne, un pour les applications publiques.
  • cert-manager avec validation DNS-01. Les certificats se renouvellent automatiquement.
  • Falco pour détecter les comportements anormaux dans les conteneurs.
  • Un provisionnement NFS dynamique pour les volumes, et cinq CronJobs (sauvegarde des bases, synchronisation des secrets).

Passage en GitOps

Au début, j'appliquais les manifestes à la main. Quand j'ai dû reconstruire un nœud, je ne savais plus ce qui avait été déployé volontairement.

J'ai mis en place ArgoCD avec le modèle « app of apps » : une application racine déclare les autres. ArgoCD lit le dépôt privé avec une clé de déploiement en lecture seule.

Seule l'application racine se synchronise automatiquement. Je synchronise les autres à la main, parce qu'une synchronisation de Cilium redémarre le réseau des pods.

Dépôt Gitétat attenduArgoCDcompare en continuCluster68 pods · 19 espaceslitapplique, sur mon accordétat observéune modification manuelle sur le cluster apparaît comme un écart17 applicationsune racine déclare les autres
ArgoCD compare en continu le dépôt Git et le cluster, et affiche les écarts. Seule l'application racine est synchronisée automatiquement.

Incident : sauvegarde vide pendant 25 jours

J'ai déplacé PostgreSQL du cluster vers un conteneur dédié. Le CronJob qui sauvegardait la base de Vaultwarden pointait encore vers l'ancienne adresse.

Le job ne tombait pas en erreur. Pendant 25 jours, il a écrit chaque nuit une archive de 20 octets.

J'ai corrigé l'adresse et ajouté un contrôle de taille : le job échoue maintenant si l'archive fait moins de 10 Ko.

État actuel

4nœuds Debian, v1.32
68pods sur 19 espaces de noms
17applications décrites, 9 synchronisées
5CronJobs de sauvegarde et de synchronisation

Reste à faire : 8 applications sont en écart avec le dépôt. 5 ont reçu des correctifs appliqués directement sur le cluster, 3 décrivent des composants que j'ai supprimés. La version 1.32 n'est plus maintenue, la mise à jour est le prochain chantier.