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>
- runtime-core dos quatro antigos ganha ATM_KC_ADMIN_URL e ATM_KC_REALM do
Keycloak compartilhado (o padrao apontava para o Keycloak proprio, parado)
- molde e os quatro nascidos dele: client cadastro-keycloak criado no realm,
segredo selado em 05-sealed-kc-admin-secret.yaml, variaveis no runtime-core
(secretKeyRef optional) e o Secret na Role de leitura do provisionamento
- plataforma: o captacao pode anotar o ApplicationSet para varrer na hora
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
internationalizationEnabled vem FALSE por padrao no Keycloak, e ai ele cai no
en — o e-mail sairia em ingles mesmo com o emailTheme certo. defaultLocale
pt-BR e supportedLocales so pt-BR: uma opcao so nao mostra seletor de idioma na
tela de login.
Minha insercao anterior casou por substring e caiu no objeto do cliente spa,
onde loginTheme e emailTheme nao querem dizer nada — entao um tenant novo
continuava nascendo com a tela de fabrica, e o commit anterior dizia o
contrario.
Refeito carregando o JSON, tirando as chaves de onde nao pertenciam e provando
que o resto do documento e identico antes de gravar.
O nginx roteia /bff e /api com proxy_pass de variavel, e ai resolve por
requisicao usando a diretiva resolver. O resolver do nginx nao le os dominios
de busca do /etc/resolv.conf: pergunta o nome cru ao CoreDNS, que responde
NXDOMAIN para servico-bff.
O sintoma engana: 502 com could not be resolved no log do nginx, enquanto
getent hosts servico-bff dentro do MESMO pod resolve — porque o getent usa o
search e o nginx nao. E por isso que o escolinha sempre usou FQDN aqui.
deploy