Infrastructure — vue d'ensemble
Responsabilités
| Couche | Technologie | Source de vérité | Administration |
|---|---|---|---|
| VPS | 4 VPS OVH : 3 control-plane/etcd et 1 worker, répartis entre Gravelines, Strasbourg et os-uk2 |
Configuration système de chaque VPS | SSH et console OVH |
| Réseau privé | WireGuard 10.50.0.0/24 |
Fichiers système des VPS | SSH, wg, systemctl |
| Orchestration | K3s HA avec etcd embarqué sur 3 control-plane + 1 worker | Configuration K3s + état etcd | kubectl, SSH en dernier recours |
| Infrastructure K8s | cert-manager, KEDA | infrastructure/ovh-primary |
Flux GitOps |
| Applications | Workloads et Ingress | apps/ovh-primary |
Flux GitOps |
| DNS public | Cloudflare Free | Zones Cloudflare | Dashboard Cloudflare |
| TLS public | Let's Encrypt | ClusterIssuer + Ingress GitOps | cert-manager |
| Authentification web | GitHub OAuth + OAuth2 Proxy | Manifeste GitOps + Secret hors Git | GitHub et Kubernetes |
| Supervision | Prometheus, Grafana, Gatus | GitOps | Interfaces web et kubectl |
Topologie K3s actuelle
| Nœud | Région | Rôle |
|---|---|---|
vps-a2cbe513 |
GRA | control-plane, etcd |
vps-7a702a91 |
SBG | control-plane, etcd |
vps-b49e4e6f |
GRA | control-plane, etcd |
vps-f0621bb1 |
os-uk2 |
worker |
Le quorum etcd repose uniquement sur les trois control-plane. Le worker vps-f0621bb1 apporte de la capacité applicative et héberge notamment plusieurs workloads explicitement épinglés sur os-uk2.
Chemin d'une requête
flowchart LR
C[Client] --> D[DNS Cloudflare]
D --> T[Traefik sur le cluster]
T --> M[Middlewares TLS / SSO]
M --> S[Service Kubernetes]
S --> P[Pod applicatif]Règle de gestion
Toute modification Kubernetes durable passe par Git. Les exceptions sont les lectures, la demande de réconciliation Flux, certaines actions temporaires d'exploitation et la création/rotation de secrets qui ne doivent jamais être stockés en clair.
La configuration système des VPS n'est pas encore entièrement déclarative. Un changement système doit être appliqué aux nœuds concernés selon leur rôle, vérifié puis documenté. Les règles communes de réseau, DNS, temps, accès et sécurité doivent rester cohérentes sur les quatre machines.
Ordre de diagnostic
- Vérifier Gatus et Grafana.
- Vérifier les quatre nœuds et les événements Kubernetes.
- Vérifier Flux, ses dépendances et la révision Git appliquée.
- Isoler la couche : DNS, TLS/Ingress, Service, Pod, stockage, base de données, réseau privé ou VPS.
- Corriger la source de vérité appropriée, puis vérifier la convergence.
Pour les commandes opérateur courantes, utiliser le runbook d'exploitation quotidienne.