tadata
← Retour à l'accueil

Patterns Kubernetes : Déploiement, Gestion des Ressources & Multi-Tenancy

#kubernetes#devops#cloud#architecture#containers

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égieZero downtimeVitesse rollbackCoût ressourcesRisqueIdéal pour
Rolling updateOuiLent (re-déploiement)1x + surgeFaible par podServices stateless, choix par défaut
Blue-greenOuiInstantané (bascule)2xTout-ou-rienServices critiques
CanaryOuiRapide (routage)1x + % canaryRayon d'explosion contrôléServices user-facing
RecreateNon (coupure)Lent1xCoupure totaleServices stateful, migrations BDD
ShadowOuiN/A2xAucun (trafic miroir)Validation de performance
tadata
Blue-green deployment Users ALB listener weightedtarget groups / Route53 switch all traffic at once Blue (v1) kept for rollback idle Green (v2) new ASG / ECS task set 100% switch weights back in seconds
Blue-green deployment Users ALB listener weightedtarget groups / Route53 switch all traffic at once Blue (v1) kept for rollback idle Green (v2) new ASG / ECS task set 100% switch weights back in seconds
Blue/green : deux environnements complets, le trafic est basculé au niveau du load balancer ou du DNS

Extrait de la fiche « SOA-C03 Domain 3: Deployment, Provisioning, Automation » · Demander la fiche complète

Patterns Sidecar / Ambassador / Adapter

tadata
Pod (réseau partagé, volumes partagés) Conteneur applicatif Sidecar (proxy) Sidecar (journalisation)
Pod (réseau partagé, volumes partagés) Conteneur applicatif Sidecar (proxy) Sidecar (journalisation)
PatternRôleExempleQuand l'utiliser
SidecarÉtendre l'app avec des préoccupations transversesProxy Envoy, collecteur de logsService mesh, observabilité
AmbassadorProxy les connexions sortantesInjection token OAuth, rate limiterSimplifier la communication externe
AdapterNormaliser la sortie de l'appExporteur Prometheus, convertisseur de formatMonitoring hétérogène
Init containerExécution avant démarrage de l'appMigration BDD, injection de secretsInitialisation unique

Taxonomie de Gestion des Ressources

tadata
  • Requests & limits
    • Requests CPU (garantie de scheduling)
    • Limits CPU (plafond de throttling)
    • Requests mémoire (garantie de scheduling)
    • Limits mémoire (seuil d'OOM-kill)
  • Qualité de service (QoS)
    • Guaranteed (requests = limits)
    • Burstable (requests < limits)
    • BestEffort (aucun request/limit)
  • Contrôles au niveau du cluster
    • ResourceQuotas (plafonds par namespace)
    • LimitRanges (valeurs par défaut et bornes par pod)
    • PriorityClasses (ordre d'éviction)
  • Autoscaling
    • HPA : Horizontal Pod Autoscaler (nombre de réplicas)
    • VPA : Vertical Pod Autoscaler (dimensionnement des ressources)
    • KEDA : scaling piloté par les événements (profondeur de file, métriques personnalisées)
    • Cluster Autoscaler / Karpenter (provisionnement de nœuds)
tadata
PEAK DEMAND 1,650 → 20 instances INSTANCE-STEPS (COST) 134 UNDER-PROVISIONED 0 steps OVER-PROVISIONED 1 step 0 1,080 2,160 1 2 3 4 5 6 7 8 9 10 11 12 10 min Instances 5 5 8 13 20 20 20 13 13 6 6 5 Utilisation % 60 68 65 69 70 82 75 69 46 70 63 70 demand capacity = instances × capacity target × capacity under-provisioned held by cooldown Wanted instances = ⌈demand ÷ (capacity per instance × target)⌉ = ⌈demand ÷ (100 × 0.7)⌉, kept between min 3 and max 20;utilisation = demand ÷ (instances × capacity). Scale-out happens at once, scale-in waits 2 steps after the last change.
PEAK DEMAND 1,650 → 20 instances INSTANCE-STEPS (COST) 134 UNDER-PROVISIONED 0 steps OVER-PROVISIONED 1 step 0 1,080 2,160 1 2 3 4 5 6 7 8 9 10 11 12 10 min Instances 5 5 8 13 20 20 20 13 13 6 6 5 Utilisation % 60 68 65 69 70 82 75 69 46 70 63 70 demand capacity = instances × capacity target × capacity under-provisioned held by cooldown Wanted instances = ⌈demand ÷ (capacity per instance × target)⌉ = ⌈demand ÷ (100 × 0.7)⌉, kept between min 3 and max 20;utilisation = demand ÷ (instances × capacity). Scale-out happens at once, scale-in waits 2 steps after the last change.
HPA sur une API : 100 req/s par pod à 100 % de CPU, cible 70 %, min 3, max 20, scale-in retenu 2 pas (fenêtre de stabilisation)

Extrait de la fiche « AKS Scaling, Upgrades and Operations » · Demander la fiche complète

Matrice de Stratégie de Namespaces

StratégieStructureAvantagesInconvénientsIdéal pour
Par environnementdev / staging / prodSimple, séparation claireFaible isolation intra-envPetites équipes
Par équipeteam-a / team-bAutonomie équipe, RBACDécouverte inter-équipes plus difficileOrgs moyennes
Par serviceapi-gateway / billingIsolation maximaleProlifération de namespacesSécurité stricte
Hybrideprod-team-a / staging-team-aMeilleur compromisConventions de nommage critiquesGrandes organisations

Comparaison Multi-Tenancy

DimensionIsolation namespaceClusters virtuels (vCluster)Clusters séparés
Niveau d'isolationSouple (RBAC + NetworkPolicy)Moyen (control plane virtuel)Fort (séparation physique)
Efficacité coûtÉlevéeMoyenneFaible
Rayon d'explosionNamespaceCluster virtuelCluster entier
ComplexitéFaibleMoyenneÉlevée
ConformitéBasiqueBonneMeilleure (air-gapped)
Idéal pourÉquipes internesISVs, platform engineeringIndustries réglementées
tadata
Rolling update Users node pool upgrade(cordon, drain,reimage) replace instances one byone nodes on 1.32 67% nodes on 1.33 (surge) 33% roll back Ramp 33% 67% 100%
Rolling update Users node pool upgrade(cordon, drain,reimage) replace instances one byone nodes on 1.32 67% nodes on 1.33 (surge) 33% roll back Ramp 33% 67% 100%
Max surge de 33 % sur un node pool de 9 nœuds : 3 nouveaux nœuds à la fois, PDB respectés pendant le drain

Extrait de la fiche « AKS Scaling, Upgrades and Operations » · Demander la fiche complète

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.