Remplacement diagrammes PDF par PNG, ajout note Docker Swarm, traductions complètes
- Replace PDF diagrams with PNG images for inline display in docs - Add infrastructure diagram to Homelab actuel category page - Add network diagram to single-machine HA homelab page - Add Docker Swarm vs Kubernetes decision note in docker-compose page - Complete English translations for homepage tagline - Translate homepage tagline dynamically using Docusaurus i18n - Remove PDF diagram files from static assets (homelab-actuel-infra.pdf, homelab-futur-network.pdf) - Add new documentation pages: Docker Compose, Ansible playbooks, Traefik - Add Future Homelab pages: single-machine HA and 3-node Proxmox cluster - Remove example pages and notions category - Update sidebar configuration
This commit is contained in:
parent
cb1640c1cc
commit
ed2cca8c0e
27 changed files with 1482 additions and 636 deletions
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# 3-Node Proxmox Cluster: A True HA Homelab
|
||||
|
||||
Documentation coming soon...
|
||||
|
||||
## Target Architecture
|
||||
|
||||
This page will be completed with details of the final 3-node Proxmox cluster architecture.
|
||||
|
|
@ -1,153 +0,0 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Example
|
||||
|
||||
This is an example page in the Future Homelab category.
|
||||
|
||||
## Description
|
||||
|
||||
This page demonstrates how to document Kubernetes configurations and deployments for the future homelab.
|
||||
|
||||
## Kubernetes Deployment
|
||||
|
||||
Example deployment manifest:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: production
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: example
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: example
|
||||
spec:
|
||||
containers:
|
||||
- name: app
|
||||
image: nginx:latest
|
||||
ports:
|
||||
- containerPort: 80
|
||||
resources:
|
||||
limits:
|
||||
cpu: 100m
|
||||
memory: 128Mi
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 64Mi
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: example-service
|
||||
namespace: production
|
||||
spec:
|
||||
selector:
|
||||
app: example
|
||||
ports:
|
||||
- port: 80
|
||||
targetPort: 80
|
||||
type: ClusterIP
|
||||
```
|
||||
|
||||
## OpenTofu Configuration
|
||||
|
||||
Example infrastructure resource:
|
||||
|
||||
```hcl
|
||||
resource "kubernetes_namespace" "production" {
|
||||
metadata {
|
||||
name = "production"
|
||||
labels = {
|
||||
environment = "production"
|
||||
managed-by = "opentofu"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
resource "kubernetes_deployment" "example" {
|
||||
metadata {
|
||||
name = "example-app"
|
||||
namespace = kubernetes_namespace.production.metadata[0].name
|
||||
}
|
||||
|
||||
spec {
|
||||
replicas = 3
|
||||
|
||||
selector {
|
||||
match_labels = {
|
||||
app = "example"
|
||||
}
|
||||
}
|
||||
|
||||
template {
|
||||
metadata {
|
||||
labels = {
|
||||
app = "example"
|
||||
}
|
||||
}
|
||||
|
||||
spec {
|
||||
container {
|
||||
image = "nginx:latest"
|
||||
name = "app"
|
||||
|
||||
resources {
|
||||
limits = {
|
||||
cpu = "100m"
|
||||
memory = "128Mi"
|
||||
}
|
||||
requests = {
|
||||
cpu = "50m"
|
||||
memory = "64Mi"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## GitOps with ArgoCD
|
||||
|
||||
ArgoCD Application configuration:
|
||||
|
||||
```yaml
|
||||
apiVersion: argoproj.io/v1alpha1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: argocd
|
||||
spec:
|
||||
project: default
|
||||
source:
|
||||
repoURL: https://forgejo.tellserv.fr/Tellsanguis/k8s-manifests.git
|
||||
targetRevision: HEAD
|
||||
path: apps/example
|
||||
destination:
|
||||
server: https://kubernetes.default.svc
|
||||
namespace: production
|
||||
syncPolicy:
|
||||
automated:
|
||||
prune: true
|
||||
selfHeal: true
|
||||
syncOptions:
|
||||
- CreateNamespace=true
|
||||
```
|
||||
|
||||
## Observability
|
||||
|
||||
Monitoring points for this service:
|
||||
|
||||
- Prometheus metrics exposed on `/metrics`
|
||||
- Logs aggregated in Loki
|
||||
- Distributed traces with Tempo
|
||||
- Alerts configured in Prometheus AlertManager
|
||||
|
|
@ -70,9 +70,3 @@ This migration represents:
|
|||
- **Practical learning**: Experimentation in real conditions
|
||||
- **Technical evolution**: Moving to modern and scalable solutions
|
||||
- **Portfolio**: Demonstration of advanced DevOps skills
|
||||
|
||||
## Articles
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
|
||||
<DocCardList />
|
||||
|
|
|
|||
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# First Version: Single-Machine "HA" Homelab (Initial Project)
|
||||
|
||||
:::info
|
||||
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)).
|
||||
|
||||
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.
|
||||
|
||||
## Objectives
|
||||
|
||||
### Practical Learning
|
||||
|
||||
This single-machine infrastructure allows acquiring hands-on experience with:
|
||||
- **Kubernetes (K3S)**: Installation, configuration, and management
|
||||
- **Infrastructure as Code**: OpenTofu/Terraform for declarative infrastructure
|
||||
- **GitOps and CI/CD**: Automated deployments with Forgejo Actions
|
||||
- **Observability**: Prometheus, Grafana, Loki stack
|
||||
|
||||
## Network Architecture
|
||||
|
||||
|
||||
|
||||
## What Can Be Learned
|
||||
|
||||
This single-machine infrastructure allows acquiring essential skills:
|
||||
- Kubernetes deployments and management
|
||||
- DevOps practices (IaC, GitOps, CI/CD)
|
||||
- Monitoring and logging
|
||||
- Automation with Ansible and OpenTofu
|
||||
|
||||
## Limitations of This Approach
|
||||
|
||||
### 1. No Real High Availability (HA)
|
||||
|
||||
**Main limitation**: With a single machine, there is **no redundancy**:
|
||||
- Single point of failure (SPOF)
|
||||
- Maintenance requires downtime
|
||||
- No automatic failover
|
||||
|
||||
### 2. Distributed Storage Impossible to Test
|
||||
|
||||
**Critical limitation**: Distributed storage (Ceph, Linstor DRBD, Longhorn with replication) requires **at least 3 nodes**:
|
||||
- **Ceph**: Requires 3 nodes minimum (ideally 5+) for quorum and replication
|
||||
- **Linstor DRBD**: Needs multiple nodes for synchronous data replication
|
||||
- **Longhorn** (replication): Cannot replicate data to other nodes
|
||||
|
||||
### 3. Limited Scalability
|
||||
|
||||
- Cannot add worker nodes to increase capacity
|
||||
- Hardware limitations of single machine
|
||||
- No experience with horizontal auto-scaling
|
||||
|
||||
### 4. Simplified Network
|
||||
|
||||
- All pods on the same physical machine
|
||||
- Negligible network latency
|
||||
- No multi-node CNI complexity
|
||||
|
||||
### 5. No Realistic Failure Simulation
|
||||
|
||||
- Cannot simulate node failure
|
||||
- No automatic failover testing
|
||||
- No disaster recovery validation
|
||||
|
||||
## Why Start with Single Machine?
|
||||
|
||||
Despite limitations, this approach has **significant advantages**:
|
||||
|
||||
### 1. Cost and Simplicity
|
||||
|
||||
- Reduced investment (no need to buy 3-5 servers immediately)
|
||||
- Lower power consumption
|
||||
- Simplified maintenance
|
||||
|
||||
### 2. Progressive Learning Curve
|
||||
|
||||
- Manageable complexity
|
||||
- Simplified debugging
|
||||
- Less costly mistakes
|
||||
|
||||
### 3. Architecture Validation
|
||||
|
||||
- Test which services work well on K8S
|
||||
- Optimize resource configurations
|
||||
- Identify incompatibilities before scaling
|
||||
|
||||
### 4. Preparation for Evolution
|
||||
|
||||
This version serves as a **foundation** for the complete cluster:
|
||||
- Reusable IaC code
|
||||
- Tested and validated Kubernetes manifests
|
||||
- Operational CI/CD pipelines
|
||||
|
||||
## Evolution Toward Real Cluster
|
||||
|
||||
Once stabilized, evolution toward multi-node cluster becomes 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**:
|
||||
1. Add second node to existing cluster
|
||||
2. Test pod distribution between nodes
|
||||
3. Add third node to enable HA
|
||||
4. Deploy Ceph or Linstor for distributed storage
|
||||
5. Migrate critical workloads with replication
|
||||
|
||||
## Conclusion
|
||||
|
||||
This single-machine "HA" version is an **essential pedagogical step** before deploying a real Kubernetes cluster:
|
||||
|
||||
**Positive points**:
|
||||
- Learn Kubernetes without multi-node complexity
|
||||
- Validate architecture and configurations
|
||||
- Reduced cost and simplified maintenance
|
||||
- Solid foundation to evolve toward complete cluster
|
||||
|
||||
**Assumed limitations**:
|
||||
- No real high availability
|
||||
- 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.
|
||||
|
||||
:::note
|
||||
Detailed English translation of this page is in progress.
|
||||
:::
|
||||
Loading…
Add table
Add a link
Reference in a new issue