Corrections et clarifications article Homelab HA mono-machine

docs/homelab-futur/premiere-version-ha-monomachine.md

@@ -6,7 +6,9 @@ sidebar_position: 2
 
 ## Introduction
 
-**Note importante** : Cette page décrit le **projet initial** que j'avais envisagé pour expérimenter avec Kubernetes. Ce projet a **évolué** vers une décision finale différente : un cluster Proxmox 3 nœuds (voir [Cluster 3 noeuds Proxmox](./cluster-3-noeuds-proxmox.md)).
+:::note[Projet initial non réalisé]
+Cette page décrit le **projet initial** que j'avais envisagé pour expérimenter avec Kubernetes. Ce projet a **évolué** vers une décision finale différente : un cluster Proxmox 3 nœuds (voir [Cluster 3 noeuds Proxmox](./cluster-3-noeuds-proxmox.md)).
+:::
 
 L'idée initiale était de créer une **étape transitoire** vers une infrastructure distribuée complète, en expérimentant avec Kubernetes (K3S), l'Infrastructure as Code (OpenTofu/Terraform), Git et les pipelines CI/CD, tout en restant sur une seule machine physique.
 
@@ -47,7 +49,7 @@ L'objectif était de valider les concepts suivants avant d'investir dans du mat
 - Affiner les processus de déploiement
 - Identifier les services compatibles avec K8S
 
-**Évolution du projet** : Après réflexion, j'ai décidé d'utiliser des **VMs multiples** pour simuler un vrai cluster et apprendre les aspects distribués dès le début. Cette approche m'a permis d'expérimenter avec la répartition de charge, la tolérance aux pannes et les politiques d'affinité, ce qui n'aurait pas été possible sur un nœud unique.
+**Évolution du projet** : Bien que le serveur devait rester une machine physique unique, l'idée était d'utiliser plusieurs VMs pour simuler un vrai cluster et apprendre les aspects distribués dès le début. Cette approche aurait permis d'expérimenter avec la répartition de charge, la tolérance aux pannes et les politiques d'affinité.
 
 ## Architecture réseau
 
@@ -220,9 +222,9 @@ Cette version sert de **fondation** pour le cluster complet :
 - Pipelines CI/CD opérationnels
 - Documentation complète des processus
 
-## Évolution vers un vrai cluster
+## Évolution vers un vrai cluster (plan initial)
 
-Une fois cette version stabilisée, l'évolution vers un cluster multi-nœuds devient naturelle :
+Si cette version avait été réalisée et stabilisée, l'évolution vers un cluster multi-nœuds aurait été naturelle :
 
 ### Matériel supplémentaire nécessaire
 
@@ -238,10 +240,10 @@ Une fois cette version stabilisée, l'évolution vers un cluster multi-nœuds de
 
 ### Migration progressive
 
-**Stratégie de migration** :
+**Stratégie de migration prévue** :
-1. Ajouter un deuxième nœud au cluster existant
+1. Ajouter un deuxième nœud pour former un cluster
 2. Tester la répartition des pods entre nœuds
-3. Ajouter un troisième nœud pour activer HA
+3. Ajouter un troisième nœud pour le quorum et activer HA (ou utiliser un Qdevice)
 4. Déployer Ceph ou Linstor pour le stockage distribué
 5. Migrer les workloads critiques avec réplication
 6. Configurer les Network Policies avancées
@@ -273,9 +275,9 @@ Ce projet initial de homelab "HA" monomachine a été une **réflexion important
 Après avoir analysé les limitations, notamment l'impossibilité de tester les aspects distribués (haute disponibilité, stockage Ceph, répartition de charge), j'ai décidé d'opter directement pour un **cluster Proxmox 3 nœuds**.
 
 Cette décision permet :
-- D'expérimenter avec de vraies VMs multiples simulant un cluster distribué
+- D'expérimenter avec de vraies VMs K3S réparties sur les nœuds physiques de production
 - De tester la haute disponibilité et le stockage distribué (Ceph)
 - D'apprendre les aspects réseau complexes d'un cluster réel
-- De construire une base solide pour une infrastructure production-ready
+- De construire une base solide pour une infrastructure prête pour la production
 
 Pour plus de détails sur l'architecture finale retenue, voir la page [Cluster 3 noeuds Proxmox](./cluster-3-noeuds-proxmox.md).

i18n/en/docusaurus-plugin-content-docs/current/homelab-futur/premiere-version-ha-monomachine.md

@@ -10,7 +10,9 @@ Full English translation coming soon.
 
 ## Introduction
 
-**Important note**: This page describes the **initial project** I had planned to experiment with Kubernetes. This project **evolved** into a different final decision: a 3-node Proxmox cluster (see [3-Node Proxmox Cluster](./cluster-3-noeuds-proxmox.md)).
+:::note[Initial Project Not Implemented]
+This page describes the **initial project** I had planned to experiment with Kubernetes. This project **evolved** into a different final decision: a 3-node Proxmox cluster (see [3-Node Proxmox Cluster](./cluster-3-noeuds-proxmox.md)).
+:::
 
 The initial idea was to create a **transitional step** toward a complete distributed infrastructure, experimenting with Kubernetes (K3S), Infrastructure as Code (OpenTofu/Terraform), Git, and CI/CD pipelines, while remaining on a single physical machine.
 
@@ -101,39 +103,41 @@ This version serves as a **foundation** for the complete cluster:
 - Tested and validated Kubernetes manifests
 - Operational CI/CD pipelines
 
-## Evolution Toward Real Cluster
+## Evolution Toward Real Cluster (Initial Plan)
 
-Once stabilized, evolution toward multi-node cluster becomes natural:
+If this version had been implemented and stabilized, evolution toward multi-node cluster would have been natural:
 
 **Minimum for functional HA cluster**:
 - 3 nodes (1 control plane + 2 workers, or 3 mixed nodes)
 - Gigabit network switch
 - Distributed storage (Ceph ideally requires 5 nodes)
 
-**Migration strategy**:
+**Planned migration strategy**:
-1. Add second node to existing cluster
+1. Add second node to form a cluster
 2. Test pod distribution between nodes
-3. Add third node to enable HA
+3. Add third node for quorum and enable HA (or use a Qdevice)
 4. Deploy Ceph or Linstor for distributed storage
 5. Migrate critical workloads with replication
 
-## Conclusion
+## Conclusion and Evolution to 3-Node Cluster
 
-This single-machine "HA" version is an **essential pedagogical step** before deploying a real Kubernetes cluster:
+This initial single-machine "HA" homelab project was an **important reflection** in the evolution of my infrastructure:
 
-**Positive points**:
+**Positive points of initial reflection**:
-- Learn Kubernetes without multi-node complexity
+- Clear identification of Kubernetes learning objectives
-- Validate architecture and configurations
+- Architecture and target configuration validation
-- Reduced cost and simplified maintenance
+- Understanding of single-machine approach limitations
-- Solid foundation to evolve toward complete cluster
 
-**Assumed limitations**:
+**Final decision**:
-- No real high availability
+After analyzing the limitations, particularly the impossibility to test distributed aspects (high availability, Ceph storage, load distribution), I decided to opt directly for a **3-node Proxmox cluster**.
-- Distributed storage impossible to test (Ceph, Linstor)
-- Limited scalability
-- No realistic failure simulation
 
-This approach allows **methodical progression** toward a complete cloud-native infrastructure while mastering each step of the process.
+This decision allows:
+- Experimenting with real K3S VMs distributed across physical production nodes
+- Testing high availability and distributed storage (Ceph)
+- Learning complex networking aspects of a real cluster
+- Building a solid foundation for production-ready infrastructure
+
+For more details on the final architecture, see the [3-Node Proxmox Cluster](./cluster-3-noeuds-proxmox.md) page.
 
 :::note
 Detailed English translation of this page is in progress.