chore: update

deploy/chart-gestion/resource-quota/values.yaml

@@ -0,0 +1,34 @@
+# 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"