Kubernetes Patterns: Deployment, Resource Management & Multi-Tenancy

Kubernetes fournit les briques ; les patterns fournissent l'architecture. Cet article couvre les stratégies de déploiement, les patterns structurels et les modèles de tenancy qui séparent les clusters de production des demos.

Comparaison des Stratégies de Déploiement

Stratégie	Zero downtime	Vitesse rollback	Coût ressources	Risque	Idéal pour
Rolling update	Oui	Lent (re-déploiement)	1x + surge	Faible par pod	Services stateless, choix par défaut
Blue-green	Oui	Instantané (bascule)	2x	Tout-ou-rien	Services critiques
Canary	Oui	Rapide (routage)	1x + % canary	Rayon d'explosion contrôlé	Services user-facing
Recreate	Non (coupure)	Lent	1x	Coupure totale	Services stateful, migrations BDD
Shadow	Oui	N/A	2x	Aucun (trafic miroir)	Validation de performance

Patterns Sidecar / Ambassador / Adapter

┌─────────────────────────────────────────────────┐
│                     POD                          │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐   │
│  │    App    │  │  Sidecar  │  │  Sidecar  │   │
│  │ Container │  │  (proxy)  │  │  (logging)│   │
│  └─────┬─────┘  └─────┬─────┘  └─────┬─────┘   │
│        └──────── réseau partage ─────┘           │
│                 volumes partages                 │
└─────────────────────────────────────────────────┘

Pattern	Rôle	Exemple	Quand l'utiliser
Sidecar	Étendre l'app avec des préoccupations transverses	Proxy Envoy, collecteur de logs	Service mesh, observabilité
Ambassador	Proxy les connexions sortantes	Injection token OAuth, rate limiter	Simplifier la communication externe
Adapter	Normaliser la sortie de l'app	Exporteur Prometheus, convertisseur de format	Monitoring hétérogène
Init container	Exécution avant démarrage de l'app	Migration BDD, injection de secrets	Initialisation unique

Taxonomie de Gestion des Ressources

Gestion des Ressources
├── Requests & Limits
│   ├── CPU requests (garantie de scheduling)
│   ├── CPU limits (plafond de throttling)
│   ├── Memory requests (garantie de scheduling)
│   └── Memory limits (seuil OOM-kill)
├── Qualité de Service (QoS)
│   ├── Guaranteed (requests = limits)
│   ├── Burstable (requests < limits)
│   └── BestEffort (aucun request/limit)
├── Contrôles au Niveau Cluster
│   ├── ResourceQuotas (plafonds par namespace)
│   ├── LimitRanges (défauts et bornes par pod)
│   └── PriorityClasses (ordre d'éviction)
└── Autoscaling
    ├── HPA — Horizontal Pod Autoscaler
    ├── VPA — Vertical Pod Autoscaler
    ├── KEDA — Scaling event-driven
    └── Cluster Autoscaler / Karpenter

Matrice de Stratégie de Namespaces

Stratégie	Structure	Avantages	Inconvénients	Idéal pour
Par environnement	dev / staging / prod	Simple, séparation claire	Faible isolation intra-env	Petites équipes
Par équipe	team-a / team-b	Autonomie équipe, RBAC	Découverte inter-équipes plus difficile	Orgs moyennes
Par service	api-gateway / billing	Isolation maximale	Prolifération de namespaces	Sécurité stricte
Hybride	prod-team-a / staging-team-a	Meilleur compromis	Conventions de nommage critiques	Grandes organisations

Comparaison Multi-Tenancy

Dimension	Isolation namespace	Clusters virtuels (vCluster)	Clusters séparés
Niveau d'isolation	Souple (RBAC + NetworkPolicy)	Moyen (control plane virtuel)	Fort (séparation physique)
Efficacité coût	Élevée	Moyenne	Faible
Rayon d'explosion	Namespace	Cluster virtuel	Cluster entier
Complexité	Faible	Moyenne	Élevée
Conformité	Basique	Bonne	Meilleure (air-gapped)
Idéal pour	Équipes internes	ISVs, platform engineering	Industries réglementées

Ressources

:::