Uso real ~5m por container; a reserva de 100m travava o no em 13 tenants.
Com 50m o teto passa a ser a memoria: 16. Limites continuam 1 vCPU.
Ver docs/capacidade-kvm8.md no repositorio de codigo.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
O tenant provisionado subia com a tela de login de fabrica e o sistema vazio.
Quatro mudancas, medidas contra o escolinha que e o que funciona:
- 90-servico-bff.yaml: o quinto Deployment. A SPA chama o BFF para quase tudo;
sem ele /bff devolve 502. As URLs apontam para os RUNTIMES, e nao para os
treze servicos — e a diferenca deste molde para o do escolinha.
- a cota sobe para 10 pods e 2Gi: com quatro Deployments o tenant ja usava
1232Mi de 1536Mi, e o BFF pede 256Mi. Caberia em repouso e estouraria no
primeiro rollout.
- loginTheme athleticmap-v2 no realm, com o tema montado no Keycloak
compartilhado.
- imagens alinhadas: frontend 2.67-csp-script e os runtimes 1.2-auditoria.
O que NAO mudou, e por que: ATM_API_URL continua no runtime-operacao e o
Ingress continua com uma rota. Os dois estao certos — o nginx da SPA roteia
/bff e /api por conta propria, e ATM_API_URL e o destino do que nao pertence a
grupo nenhum, hoje o webhook em /api/public. O cabecalho do molde ja dizia.
Ate aqui ele vivia SO no monorepo, e o provisionamento roda DENTRO do cluster —
o pod do servico-captacao nao tinha como enxerga-lo. A etapa MANIFESTOS_GERADOS
falhava por configuracao vazia, e falhar fechado era o comportamento certo; o
que faltava era o molde chegar.
Pondo-o aqui, o pod precisa de UM volume em vez de dois: o mesmo clone do GitOps
serve de molde (moldes/consolidado) e de copia de trabalho (tenants/<nome>).
Os tres marcadores — TENANT, REALM e PLANO — batem com o RenderizadorDeMolde. Os
arquivos NAO sao YAML valido antes de renderizados, e isso e de proposito: um
`{{PLANO}}` literal aplicaria sem reclamar e criaria um tenant cujo plano se
chama "{{PLANO}}", com a barreira negando tudo depois.
deploy