From f7d12591feb646bd33841b443aa711b11fcd1fbc Mon Sep 17 00:00:00 2001 From: deploy Date: Fri, 25 Sep 2026 11:52:56 +0000 Subject: [PATCH] fix(cota): a cota cabia o repouso, mas nao a troca -- faltava por 128Mi Os dois tenants pagos estavam presos em `1.1-demo` desde 24/09 23:43, sem conseguir ir para `1.2-auditoria`. O ArgoCD dizia Synced: o Deployment batia com o git. O que nao acontecia era o rollout. Em repouso os cinco Deployments somam 2944Mi. O maxSurge de 25% sobre uma replica arredonda para cima e pede um pod inteiro a mais: 768Mi, quando o que troca e um runtime. 2944 + 768 = 3712, contra 3584. O cabecalho do arquivo ja tinha essa licao escrita -- para `pods`, que derrubou o provisionamento do plataforma em 17/09. A memoria nao ganhou o mesmo tratamento. Agora a regra esta escrita uma vez, para todos os tetos, e o paragrafo velho que ainda dizia `pods: 8` saiu. So limits.memory travava: medido hoje, requests.memory tinha 560Mi livres (a troca pede 400), requests.cpu 1100m (pede 100), limits.cpu 1300m (pede 1000) e pods 5 de 10. --- .../00-namespace-quota-netpol.yaml | 39 +++++++++++++++---- .../00-namespace-quota-netpol.yaml | 39 +++++++++++++++---- .../00-namespace-quota-netpol.yaml | 39 +++++++++++++++---- 3 files changed, 93 insertions(+), 24 deletions(-) diff --git a/moldes/consolidado/00-namespace-quota-netpol.yaml b/moldes/consolidado/00-namespace-quota-netpol.yaml index 88cffd2..45e3be3 100644 --- a/moldes/consolidado/00-namespace-quota-netpol.yaml +++ b/moldes/consolidado/00-namespace-quota-netpol.yaml @@ -24,14 +24,21 @@ # ---------------------------- # soma 1.177 MiB # -# `requests.memory: 1.5Gi` cobre a soma com ~300 MiB de folga. -# `limits.memory: 2.5Gi` da a cada runtime espaco para picos sem que a soma dos -# limites vire uma promessa que o no nao pode cumprir. +# OS NUMEROS DA TABELA ACIMA SAO DE QUANDO ERAM QUATRO DEPLOYMENTS. Hoje sao +# cinco (o `servico-bff` entrou em 2026-09-24), e os tetos ja viveram duas +# correcoes: requests.memory 1.5Gi -> 2Gi, limits.memory 2.5Gi -> 3.5Gi -> +# 4352Mi, pods 8 -> 10. A razao de cada valor esta ao lado dele, la embaixo. +# +# A REGRA QUE VALE PARA TODOS: a cota tem de caber o REPOUSO MAIS UMA TROCA. +# Um Deployment sobe o pod novo ANTES de derrubar o velho, entao no pico existe +# um pod a mais do que o desenho sugere -- e o `maxSurge: 25%` sobre uma unica +# replica arredonda para cima, ou seja, sempre um inteiro. +# +# Ja custou duas vezes, pela mesma causa em dimensoes diferentes: derrubou o +# provisionamento do `plataforma` em 2026-09-17 (faltou `pods`), e prendeu os +# dois tenants pagos por 12h em 2026-09-24 (faltou `limits.memory`), com o +# ArgoCD dizendo "Synced" enquanto o pod novo era recusado pela cota. # -# `pods: 8` — sao 4 Deployments; os outros 4 sao para o pod novo conviver com o -# velho durante um rollout, sem travar o deploy por cota. Foi exatamente isso que -# derrubou o provisionamento do `plataforma` em 2026-09-17: a cota do molde nao -# cabia e keycloak, bff e captacao nao conseguiam criar pod. # # NAO ha Postgres nem Keycloak aqui: os dois passam a viver em `plataforma-prod` # (P4.7 e P4.8). @@ -63,7 +70,23 @@ spec: requests.cpu: "1.5" requests.memory: 2Gi limits.cpu: "5" - limits.memory: 3.5Gi + # SUBIU de 3.5Gi em 2026-09-25: faltava por 128Mi na hora da troca. + # + # A conta que o comentario acima comecou, agora terminada. Em repouso os + # cinco Deployments somam 2944Mi (128 + 768*3 + 512). O `maxSurge: 25%` sobre + # UMA replica arredonda para cima e pede um pod inteiro a mais: 768Mi, se o + # que esta trocando e um runtime. 2944 + 768 = 3712, contra um teto de 3584. + # + # Nao foi hipotese: os dois tenants pagos ficaram 12h presos em `1.1-demo` + # sem conseguir ir para `1.2-auditoria`, com o ArgoCD dizendo "Synced" e o + # pod novo recusado pela cota a cada ~17min. + # + # 4352Mi = 2944 de repouso + 768 da troca + 640 de sobra. + # + # So `limits.memory` travava. Medido em 2026-09-25: requests.memory tinha + # 560Mi livres (a troca pede 400), requests.cpu 1100m (pede 100), limits.cpu + # 1300m (pede 1000) e pods 5 de 10. Subir a memoria basta. + limits.memory: 4352Mi pods: "10" --- # ============================================================================= diff --git a/tenants/escolinha-de-teste-2/00-namespace-quota-netpol.yaml b/tenants/escolinha-de-teste-2/00-namespace-quota-netpol.yaml index d07cb7c..7edd620 100644 --- a/tenants/escolinha-de-teste-2/00-namespace-quota-netpol.yaml +++ b/tenants/escolinha-de-teste-2/00-namespace-quota-netpol.yaml @@ -24,14 +24,21 @@ # ---------------------------- # soma 1.177 MiB # -# `requests.memory: 1.5Gi` cobre a soma com ~300 MiB de folga. -# `limits.memory: 2.5Gi` da a cada runtime espaco para picos sem que a soma dos -# limites vire uma promessa que o no nao pode cumprir. +# OS NUMEROS DA TABELA ACIMA SAO DE QUANDO ERAM QUATRO DEPLOYMENTS. Hoje sao +# cinco (o `servico-bff` entrou em 2026-09-24), e os tetos ja viveram duas +# correcoes: requests.memory 1.5Gi -> 2Gi, limits.memory 2.5Gi -> 3.5Gi -> +# 4352Mi, pods 8 -> 10. A razao de cada valor esta ao lado dele, la embaixo. +# +# A REGRA QUE VALE PARA TODOS: a cota tem de caber o REPOUSO MAIS UMA TROCA. +# Um Deployment sobe o pod novo ANTES de derrubar o velho, entao no pico existe +# um pod a mais do que o desenho sugere -- e o `maxSurge: 25%` sobre uma unica +# replica arredonda para cima, ou seja, sempre um inteiro. +# +# Ja custou duas vezes, pela mesma causa em dimensoes diferentes: derrubou o +# provisionamento do `plataforma` em 2026-09-17 (faltou `pods`), e prendeu os +# dois tenants pagos por 12h em 2026-09-24 (faltou `limits.memory`), com o +# ArgoCD dizendo "Synced" enquanto o pod novo era recusado pela cota. # -# `pods: 8` — sao 4 Deployments; os outros 4 sao para o pod novo conviver com o -# velho durante um rollout, sem travar o deploy por cota. Foi exatamente isso que -# derrubou o provisionamento do `plataforma` em 2026-09-17: a cota do molde nao -# cabia e keycloak, bff e captacao nao conseguiam criar pod. # # NAO ha Postgres nem Keycloak aqui: os dois passam a viver em `plataforma-prod` # (P4.7 e P4.8). @@ -63,7 +70,23 @@ spec: requests.cpu: "1.5" requests.memory: 2Gi limits.cpu: "5" - limits.memory: 3.5Gi + # SUBIU de 3.5Gi em 2026-09-25: faltava por 128Mi na hora da troca. + # + # A conta que o comentario acima comecou, agora terminada. Em repouso os + # cinco Deployments somam 2944Mi (128 + 768*3 + 512). O `maxSurge: 25%` sobre + # UMA replica arredonda para cima e pede um pod inteiro a mais: 768Mi, se o + # que esta trocando e um runtime. 2944 + 768 = 3712, contra um teto de 3584. + # + # Nao foi hipotese: os dois tenants pagos ficaram 12h presos em `1.1-demo` + # sem conseguir ir para `1.2-auditoria`, com o ArgoCD dizendo "Synced" e o + # pod novo recusado pela cota a cada ~17min. + # + # 4352Mi = 2944 de repouso + 768 da troca + 640 de sobra. + # + # So `limits.memory` travava. Medido em 2026-09-25: requests.memory tinha + # 560Mi livres (a troca pede 400), requests.cpu 1100m (pede 100), limits.cpu + # 1300m (pede 1000) e pods 5 de 10. Subir a memoria basta. + limits.memory: 4352Mi pods: "10" --- # ============================================================================= diff --git a/tenants/escolinha-de-teste/00-namespace-quota-netpol.yaml b/tenants/escolinha-de-teste/00-namespace-quota-netpol.yaml index ee0fb4c..b629544 100644 --- a/tenants/escolinha-de-teste/00-namespace-quota-netpol.yaml +++ b/tenants/escolinha-de-teste/00-namespace-quota-netpol.yaml @@ -24,14 +24,21 @@ # ---------------------------- # soma 1.177 MiB # -# `requests.memory: 1.5Gi` cobre a soma com ~300 MiB de folga. -# `limits.memory: 2.5Gi` da a cada runtime espaco para picos sem que a soma dos -# limites vire uma promessa que o no nao pode cumprir. +# OS NUMEROS DA TABELA ACIMA SAO DE QUANDO ERAM QUATRO DEPLOYMENTS. Hoje sao +# cinco (o `servico-bff` entrou em 2026-09-24), e os tetos ja viveram duas +# correcoes: requests.memory 1.5Gi -> 2Gi, limits.memory 2.5Gi -> 3.5Gi -> +# 4352Mi, pods 8 -> 10. A razao de cada valor esta ao lado dele, la embaixo. +# +# A REGRA QUE VALE PARA TODOS: a cota tem de caber o REPOUSO MAIS UMA TROCA. +# Um Deployment sobe o pod novo ANTES de derrubar o velho, entao no pico existe +# um pod a mais do que o desenho sugere -- e o `maxSurge: 25%` sobre uma unica +# replica arredonda para cima, ou seja, sempre um inteiro. +# +# Ja custou duas vezes, pela mesma causa em dimensoes diferentes: derrubou o +# provisionamento do `plataforma` em 2026-09-17 (faltou `pods`), e prendeu os +# dois tenants pagos por 12h em 2026-09-24 (faltou `limits.memory`), com o +# ArgoCD dizendo "Synced" enquanto o pod novo era recusado pela cota. # -# `pods: 8` — sao 4 Deployments; os outros 4 sao para o pod novo conviver com o -# velho durante um rollout, sem travar o deploy por cota. Foi exatamente isso que -# derrubou o provisionamento do `plataforma` em 2026-09-17: a cota do molde nao -# cabia e keycloak, bff e captacao nao conseguiam criar pod. # # NAO ha Postgres nem Keycloak aqui: os dois passam a viver em `plataforma-prod` # (P4.7 e P4.8). @@ -63,7 +70,23 @@ spec: requests.cpu: "1.5" requests.memory: 2Gi limits.cpu: "5" - limits.memory: 3.5Gi + # SUBIU de 3.5Gi em 2026-09-25: faltava por 128Mi na hora da troca. + # + # A conta que o comentario acima comecou, agora terminada. Em repouso os + # cinco Deployments somam 2944Mi (128 + 768*3 + 512). O `maxSurge: 25%` sobre + # UMA replica arredonda para cima e pede um pod inteiro a mais: 768Mi, se o + # que esta trocando e um runtime. 2944 + 768 = 3712, contra um teto de 3584. + # + # Nao foi hipotese: os dois tenants pagos ficaram 12h presos em `1.1-demo` + # sem conseguir ir para `1.2-auditoria`, com o ArgoCD dizendo "Synced" e o + # pod novo recusado pela cota a cada ~17min. + # + # 4352Mi = 2944 de repouso + 768 da troca + 640 de sobra. + # + # So `limits.memory` travava. Medido em 2026-09-25: requests.memory tinha + # 560Mi livres (a troca pede 400), requests.cpu 1100m (pede 100), limits.cpu + # 1300m (pede 1000) e pods 5 de 10. Subir a memoria basta. + limits.memory: 4352Mi pods: "10" --- # =============================================================================