# Plafonds calculés à partir du pire cas d'une démo au complet, HPA au max
# (voir deploy/chart-gestion/{postgresql,redis,backend,frontend,lbtelegram}
# /values.yaml — postgres 1 replica, redis 1 replica, backend jusqu'à 5
# replicas, frontend jusqu'à 4, lbtelegram 1 replica si activé) :
#   requests cpu : 250m + 100m + 5×100m + 4×50m + 100m = 1150m -> arrondi 2
#   requests mem : 256 + 128 + 5×128 + 4×64 + 128 = 1408Mi -> arrondi 2Gi
#   limits cpu   : 1000m + 500m + 5×500m + 4×200m + 500m = 5300m -> arrondi 6
#   limits mem   : 1024 + 512 + 5×256 + 4×128 + 256 = 3584Mi -> arrondi 5Gi
# Marge volontaire au-dessus du calcul pour laisser de la place à des pods
# ponctuels (exec admin, job de migration) sans bloquer le provisioning.
quota:
  requestsCpu: "2"
  requestsMemory: "2Gi"
  limitsCpu: "6"
  limitsMemory: "5Gi"
  # Cap dur sur le nombre de pods/PVC du namespace — empêche un pod-spam ou
  # une boucle de CrashLoop mal configurée d'épuiser les IP/ressources du
  # nœud. 3 PVC utilisés aujourd'hui (postgres, redis, uploads) + marge.
  maxPods: "20"
  maxPVCs: "5"

# Défauts appliqués à tout container qui ne préciserait pas ses propres
# requests/limits — sans ça, le ResourceQuota ci-dessus rendrait la création
# de pod obligatoirement explicite (K8s rejette un pod sans requests/limits
# dans un namespace où un ResourceQuota les couvre).
limitRange:
  defaultRequestCpu: "100m"
  defaultRequestMemory: "128Mi"
  defaultLimitCpu: "500m"
  defaultLimitMemory: "256Mi"
  minCpu: "10m"
  minMemory: "16Mi"
  maxCpu: "2"
  maxMemory: "1Gi"