Recursos, capacidade e operação do mobiis-iam-admin — o Keycloak que autentica o WMS em produção. Retrato colhido do cluster em 19/08/2026, 17:53 UTC, logo após a triplicação dos limites.
A barra é o consumo real do pod. As marcas fixas são o request (o que o agendador reserva) e o limit (onde o kernel mata o processo). A escala vai de zero até o limite.
O pico de CPU medido foi 652 m, durante os ~8 s de augmentation do Quarkus no start. Em regime, o Keycloak fica em 15–18 m. O request de 1500 m reserva 100× o consumo ocioso.
Quatro valores triplicados, mais uma troca de estratégia de rollout para que a subida não derrubasse o login. Cada par mostra o valor antigo em tom claro e o novo em tom escuro.
| Campo | Antes | Agora | Fator | Efeito |
|---|---|---|---|---|
| requests.cpu | 500m | 1500m | 3,0× | Reserva no agendador |
| limits.cpu | 600m | 1800m | 3,0× | Teto antes do throttling |
| requests.memory | 768Mi | 2304Mi | 3,0× | Reserva no agendador |
| limits.memory | 1024Mi | 3072Mi | 3,0× | Teto antes do OOMKill |
| maxUnavailable | 1 | 0 | — | Rollout sem derrubar o login |
| maxSurge | 25% (implícito) | 1 | — | Pod novo sobe antes do antigo sair |
O efeito colateral menos óbvio de triplicar o request: ele restringe onde o agendador pode colocar o pod. As barras mostram a CPU livre de cada node contra os 1500 m que o pod agora exige.
Com o request antigo de 500 m o pod cabia em todos os nodes. Hoje ele só cabe no .230 e nos virtual nodes — e os virtual nodes não têm taint, então nada garante que ele fique lá. Se o .230 encher e os virtual nodes ficarem indisponíveis, o pod entra em Pending.
Ajuste os quatro valores e o painel recalcula a folga sobre o consumo medido, checa em quais nodes o pod caberia e escreve o comando exato. Nada aqui toca o cluster — o comando é gerado para você conferir e rodar.
Rode o patch com --dry-run=server antes do apply de verdade: o API server valida o objeto inteiro e devolve o resultado sem gravar nada.
Os comandos que resolvem 90% do que se faz nesse deployment. Todos já vêm com o contexto e o namespace corretos — o cluster de produção não é o contexto padrão da sua máquina.
Pod, recursos configurados e consumo real numa passada só.
kubectl --context=context-csyhqbid7pq -n iam get pod,deploy,hpa -o wide && kubectl --context=context-csyhqbid7pq -n iam top podCom maxUnavailable: 0, o pod novo precisa ficar Ready antes do antigo morrer. Se travar aqui, é o pod novo que não subiu.
kubectl --context=context-csyhqbid7pq -n iam rollout status deploy/mobiis-iam-admin --timeout=180sO start completo leva ~8 s de augmentation do Quarkus e mais ~8 s de boot.
kubectl --context=context-csyhqbid7pq -n iam logs -f deploy/mobiis-iam-admin --tail=100Vale mais que o status do pod: confirma que Caddy, DNS e Keycloak estão respondendo de ponta a ponta.
curl -s -o /dev/null -w "HTTP %{http_code} em %{time_total}s\n" https://iam.mobiis.com.br/realms/master/.well-known/openid-configurationSeguro por causa do maxSurge: 1 / maxUnavailable: 0. As sessões em memória do Infinispan se perdem de qualquer forma — quem estiver logado segue logado pelo token, mas o cache de sessão zera.
kubectl --context=context-csyhqbid7pq -n iam rollout restart deploy/mobiis-iam-adminDesfaz o último rollout. Como o ArgoCD do iam está parado, ninguém vai sobrescrever a reversão.
kubectl --context=context-csyhqbid7pq -n iam rollout undo deploy/mobiis-iam-adminEnquanto o sync não voltar a Synced, commit no repositório não altera nada neste namespace.
kubectl --context=context-csyhqbid7pq -n shared-services get application iam -o custom-columns='SYNC:.status.sync.status,HEALTH:.status.health.status,REPO:.spec.source.repoURL'Tudo abaixo foi observado no cluster em 19/08. Nenhum item é consequência da mudança de recursos — são condições que já existiam e continuam valendo.
O log de boot diz literalmente Profile dev activated e Running the server in development mode. DO NOT use this configuration in production. O container sobe com start-dev.
Em dev mode o Keycloak relaxa exigências de HTTPS, não habilita cache distribuído e usa configuração pensada para desenvolvimento local — num IdP que autentica o WMS inteiro.
O configmap.yaml carrega senha do Postgres, senha do admin do Keycloak e senha do Redis commitadas — contra a regra escrita no próprio CLAUDE.md do gitops, que manda usar Secrets via secretRef.
Os valores não estão reproduzidos neste painel de propósito. São 22 chaves no ConfigMap, 4 delas sensíveis.
O Application iam ainda aponta para git@bitbucket.org por SSH e falha com error creating SSH agent: SSH_AUTH_SOCK not-specified desde 13/05/2026. Os apps wms e base-de-precos já migraram para o remote do Azure DevOps.
Consequência prática: commit no gitops não aplica nada no iam. Religar exige janela controlada — o sync está com prune: true depois de três meses sem convergir. Em 19/08 não havia drift entre o cluster e o git, o que torna a religada mais previsível.
O container não declara nenhuma das duas. Sem readinessProbe, "Ready" significa apenas que o processo iniciou — o maxUnavailable: 0 protege menos do que aparenta, porque o Kubernetes considera o pod novo pronto antes do Keycloak terminar de subir.
O Keycloak 26 expõe /health/ready e /health/live quando KC_HEALTH_ENABLED=true.
minReplicas: 1 e maxReplicas: 1 — o autoscaler existe mas não pode escalar. Qualquer perda do pod é indisponibilidade total do SSO até ele voltar, e o ganho de CPU não vira capacidade de atender mais login concorrente.
O aumento de memória resolveu um problema real: o pod vivia a 86% do limite. Já o request de CPU foi de 500 m para 1500 m enquanto o consumo em regime é de 15 m e o pico de start foi de 652 m.
O custo disso é concreto: o pod deixou de caber em dois dos três nodes VM, e em virtual node a OCI cobra pelo request. Manter o limit alto dá folga para picos sem esse custo — é o que o cenário "Sugerido" do planejador modela.
O boot avisa: Hostname v1 options [hostname-admin-url, hostname-url, proxy, hostname-strict-https] are still in use. São opções da v1 depreciadas no Keycloak 26 — funcionam hoje, quebram numa atualização maior. Há também um JDBC resources leaked: 3 ResultSet(s) no start.