Infrastructure GitOps pour K3s sur Proxmox

Ce projet met en œuvre une infrastructure entièrement déclarative pour le déploiement et la gestion d'un cluster Kubernetes (K3s) sur un environnement Proxmox. L'ensemble du système est piloté par une approche GitOps, où Git sert de source unique de vérité pour l'infrastructure et les applications.

Principes d'Architecture

L'architecture repose sur plusieurs concepts fondamentaux conçus pour maximiser l'automatisation, la résilience et la maintenabilité.

1. Infrastructure as Code (IaC): L'infrastructure physique (les machines virtuelles sur Proxmox) est définie et gérée de manière déclarative à l'aide d'OpenTofu. Cela garantit des déploiements reproductibles et cohérents.

2. Approche GitOps multi-niveaux: Le système utilise un modèle de "pull" à plusieurs niveaux pour synchroniser l'état souhaité (défini dans Git) avec l'état réel. Ce modèle réduit les dépendances et améliore la sécurité en limitant les permissions nécessaires.

   • Niveau 1 (Infrastructure): Un pipeline CI/CD sur Forgejo est le seul composant autorisé à "pousser" des changements. Il exécute OpenTofu pour créer ou mettre à jour les machines virtuelles via l'API Proxmox.

   • Niveau 2 (Configuration OS): Chaque machine virtuelle est responsable de sa propre configuration. Via un cronjob, elle exécute ansible-pull pour récupérer sa configuration depuis le dépôt Git et l'appliquer localement. Cela inclut l'installation de K3s et la configuration du système d'exploitation.

   • Niveau 3 (Applications): FluxCD, s'exécutant dans le cluster K3s, se synchronise en continu avec le dépôt Git pour déployer et maintenir les applications et les configurations Kubernetes.

3. Haute Disponibilité et Résilience: Le cluster K3s est conçu pour être résilient avec deux nœuds serveurs et un témoin etcd externe pour le quorum. Le pipeline de déploiement est lui-même résilient aux pannes d'un nœud Proxmox, permettant des mises à jour partielles de l'infrastructure.

4. Automatisation Complète: De la validation du code à la mise à jour des applications, en passant par les mises à jour de sécurité du système d'exploitation (unattended-upgrades), chaque étape est automatisée pour minimiser les interventions manuelles.

Architecture Cible

Le diagramme suivant illustre le flux de déploiement, de la modification du code à son application sur l'infrastructure.

+-----------------------------------------------------------------+
| Développeur -> git push -> Dépôt Git sur Forgejo                 |
+-----------------------------------------------------------------+
    |
    | 1. Déclenche le pipeline CI/CD
    v
+------------------------+      +---------------------------------+
| VM Forgejo Runner      |----->| API Proxmox                     |
| (exécute OpenTofu)     |  2.  | (sur pve1, pve2, pve3)          |
+------------------------+      | Crée/Met à jour les VMs         |
                              +---------------------------------+
                                  |
                                  | 3. Les VMs démarrent et exécutent cloud-init
                                  v
+-----------------------------------------------------------------+
| Cluster K3s (VMs sur Proxmox)                                   |
|                                                                 |
| 4. ansible-pull (cron) tire sa configuration depuis Forgejo     |
|                                                                 |
| 5. FluxCD (dans K3s) tire les manifestes d'apps depuis Forgejo  |
+-----------------------------------------------------------------+

Spécifications des Machines Virtuelles

Rôle	Nom de la VM	Nœud Proxmox	CPU	RAM	Disque	Adresse IP
Serveur K3s	k3s-server-1	pve1	6	12GB	100GB	10.100.20.10
Serveur K3s	k3s-server-2	pve2	6	12GB	100GB	10.100.20.20
Témoin etcd	etcd-witness	pve3	2	2GB	20GB	10.100.20.30
Runner CI/CD	forgejo-runner	(au choix)	2	2GB	20GB	192.168.100.50

Structure du Dépôt

Le projet est organisé de la manière suivante pour séparer les préoccupations :

.
├── .forgejo/              # Workflows CI/CD pour Forgejo Actions.
├── ansible/                # Playbooks et rôles pour la configuration des VMs (via ansible-pull).
├── kubernetes/             # Manifestes Kubernetes gérés par FluxCD.
│   ├── flux-system/       # Configuration de FluxCD lui-même.
│   ├── apps/              # Applications à déployer sur le cluster.
│   └── infrastructure/    # Ressources Kubernetes de base (ex: Ingress, SealedSecrets).
└── terraform/              # Code OpenTofu pour la gestion de l'infrastructure sur Proxmox.
    ├── pve1/              # Ressources pour le nœud pve1.
    ├── pve2/              # Ressources pour le nœud pve2.
    └── pve3/              # Ressources pour le nœud pve3. 

Pipeline CI/CD

Le cœur de l'automatisation est le pipeline CI/CD configuré dans .forgejo/workflows/.

Intégration Continue (CI)

Déclenché à chaque push, le pipeline de CI valide l'intégrité et la qualité du code sur plusieurs axes :

• Validation OpenTofu: Assure que la syntaxe du code d'infrastructure est correcte (fmt, validate).
• Validation Ansible: Vérifie la syntaxe des playbooks (ansible-playbook --syntax-check) et leur conformité aux bonnes pratiques (ansible-lint).
• Validation Kubernetes: Valide les manifestes avec kubeconform pour garantir leur respect du schéma de l'API Kubernetes.
• Analyse de Sécurité: Trivy scanne le code d'infrastructure pour détecter des configurations potentiellement vulnérables.

Déploiement Continu (CD)

Déclenché par un push sur la branche main, le pipeline de CD orchestre le déploiement à travers le modèle multi-niveaux décrit précédemment.

1. Déploiement de l'infrastructure: Les jobs deploy-pve1, deploy-pve2, et deploy-pve3 s'exécutent en parallèle. Chacun utilise OpenTofu pour appliquer la configuration de son nœud respectif. Un échec sur un nœud n'interrompt pas les autres.

2. Configuration et déploiement applicatif: Une fois les VMs actives, les mécanismes de pull (ansible-pull et FluxCD) prennent le relais pour finaliser la configuration et déployer les applications de manière autonome.