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.
This commit is contained in:
deploy
@@ -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"
|
||||
---
|
||||
# =============================================================================
|
||||
|
||||
@@ -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"
|
||||
---
|
||||
# =============================================================================
|
||||
|
||||
@@ -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"
|
||||
---
|
||||
# =============================================================================
|
||||
|
||||
Reference in New Issue
Block a user