@oondemand/oon-core-back 0.7.23 → 0.7.28

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oondemand/oon-core-back",
-  "version": "0.7.23",
+  "version": "0.7.28",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/oondemand/oon-platform.git",

package/src/delivery/runtime.js

@@ -55,12 +55,16 @@ function memoryMi(value) {
 
 /**
  * Cota do namespace calculada pelas réplicas e pelo perfil de recursos, com
- * espaço para o pod extra do rolling update (maxSurge 1). Nunca fica abaixo
- * do piso anterior, então Apps de 1 réplica mantêm a cota de sempre.
+ * espaço para o pior momento do rolling update: as réplicas antigas ainda em
+ * encerramento (preStop + encerramento gracioso, até 40 s; Pod em
+ * encerramento continua contando na cota), as novas e o pod extra (maxSurge 1)
+ * = 2 × réplicas + 1. Com só réplicas + 1, a criação da réplica nova era
+ * recusada (exceeded quota) até a antiga sair. A cota é um teto, não reserva
+ * CPU nem memória no cluster. Nunca fica abaixo do piso anterior.
  */
 function namespaceQuota({ replicas = 1, profile = "small" } = {}) {
   const resources = RESOURCE_PROFILES[profile] || RESOURCE_PROFILES.small;
-  const pods = replicas + 1;
+  const pods = 2 * replicas + 1;
   return {
     requestsCpu: `${Math.max(QUOTA_FLOOR.requestsCpuMilli, pods * cpuMilli(resources.cpuRequest))}m`,
     requestsMemory: `${Math.max(QUOTA_FLOOR.requestsMemoryMi, pods * memoryMi(resources.memoryRequest))}Mi`,
@@ -209,15 +213,15 @@ spec:
     spec:
       serviceAccountName: oon-runtime
       terminationGracePeriodSeconds: ${TERMINATION_GRACE_SECONDS}
-      # DoNotSchedule: com ScheduleAnyway as 2 réplicas de Apps globais ficaram
-      # no mesmo nó. Com maxSkew 1 o pod extra do rolling update ainda cabe e,
-      # com um único nó, o desvio é zero e nada fica pendente.
+      # Distribuição preferencial por nó, contando só os pods da mesma revisão
+      # (matchLabelKeys): era a contagem dos pods da revisão anterior que deixava
+      # as réplicas novas juntas. ScheduleAnyway, e não a regra obrigatória: com o
+      # cluster cheio, a regra obrigatória deixava a réplica Pending ("Insufficient
+      # cpu" num nó, spread no outro) e o rollout estourava o prazo.
       topologySpreadConstraints:
         - maxSkew: 1
           topologyKey: kubernetes.io/hostname
-          whenUnsatisfiable: DoNotSchedule
-          # Só os pods da mesma revisão: sem isso, ao fim do rolling update os
-          # pods novos podem ficar todos no mesmo nó.
+          whenUnsatisfiable: ScheduleAnyway
           matchLabelKeys: [pod-template-hash]
           labelSelector:
             matchLabels: { app.kubernetes.io/name: ${context.appCode} }