> ## Content Index
> Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt
> Use this file to discover other available public pages before exploring further.

# Caso: Aplicações travando diariamente em cluster AKS
- URL: https://www.azurebrasil.cloud/blog/caso-aplicacoes-travando-diariamente-em-cluster-aks/
- Published: 2025-10-29T12:49:33.000Z
- Updated: 2026-03-19T14:08:04.000Z
- Author: Bruno Brito
- Tags: case, AKS

**Contexto**

Fomos indicados por um parceiro para auxiliar uma grande empresa de e-commerce que estava enfrentando problemas em seu cluster AKS. Há pelo menos uma semana o ambiente "caia" e não conseguiam identificar o motivo. O suporte da Microsoft já estava envolvido e havia até engenheiros no caso. Ou seja, o problema estava movimentando toda equipe de TI.

O relato do cliente era que por volta das **15h** todos os dias o sistema apresentava falhas:

- Aplicações paravam de responder
- Partes da plataforma ficavam indisponíveis
- Uma aplicação .NET perdia conexão com o SignalR

Já havia uma *war room* investigando a parte de rede.

A primeira hipótese era que o problema estivesse relacionado ao **SignalR**, visto que diversos logs indicavam perda de conexão. Era uma aplicação monolítica, crítica para o negócio e servia como principal ponto de entrada do sistema, o que reforçou o direcionamento inicial da equipe para uma investigação de rede.

## **Investigação**

Ingressarmos no problema, mas foi criado outra *war room*. Buscamos primeiro entender o funcionamento do ambiente e as relações entre as aplicações.

Felizmente, o cluster já estava sendo monitorado via **Datadog** (A pedido da Microsoft), o que nos permitiu coletar insights e não precisamos configurar tudo do zero.

Durante nossa avaliação, os próprios desenvolvedores comentaram que os logs de desconexão do SignalR **não eram novos**. Ou seja, eram comuns, porém, como estavam num momento de turbulencia, qualquer alerta começava a ser interpretado como causa raiz (procurando pelo em ovo).

## **Primeira Pergunta**

Pedimos ao time um horário exato em que o problema ocorreu.  
A resposta: **15h**.

Solicitamos então a abertura da telemetria dos **Pods** nesse intervalo, comparando uma aplicação crítica com outra não crítica.

- Os **Pods** pareciam saudáveis: CPU e memória estáveis.
- Porém, o comportamento estava **visivelmente lento**.

## **Subindo o nível (Node)**

Se o POD está lento mas aparentemente saudável, então **quem está doente é o Node.**

Abrimos métricas do **Node** onde o POD estava alocado.

> **Resultado:** CPU do Node em **100%**.

Nesse momento encontramos o caminho da causa.

## **Eliminação de hipóteses**

Verificamos se o Node possuía:

- Antivírus instalado manualmente
- Agentes externos não gerenciados pelo cluster
- Workloads de monitoramento indevidos

Perguntas estranhas? Sim, mas é bem comum empresas grandes usarem Gold Images para o cluster. Para nossa sorte, tudo descartado.

Ou seja:

**Era algum workload do próprio cluster que estava consumindo toda a CPU.**

## **Descoberta**

Ao inspecionar os Deployments do cluster, identificamos:

- Deployments **sem limits de CPU**, ou
- Limites extremamente desbalanceados, como:
  - **limit = 16 vCPU**
  - **request = 0.5 vCPU**

Um dos serviços em especial realizava cálculos pesados e estava **com limit de CPU bem alto**, ele podia utilizar **todos os cores disponíveis do Node**.

## **Causa Raiz**

Durante picos de uso, esse POD consumia **100% da CPU** do Node.

Consequências:

- Os demais Pods recebiam **CPU throttling**
- Health checks começavam a falhar
- Aplicações eram reiniciadas
- O problema se espalhava, causando **efeito cascata** em todo o cluster

## **Resumo da ópera**

No fim, tratava-se de mais um caso clássico de **workloads sem governança de recursos**. E aqui entra um ponto importante: nosso time não olha o problema apenas pela ótica de infraestrutura ou somente pela ótica de desenvolvimento, nós transitamos pelos dois lados.

Enquanto a maior parte da *war room* estava presa ao log de desconexão do SignalR, nós voltamos alguns passos e buscamos entender **como as aplicações se relacionavam dentro do cluster**. Só assim foi possível determinar a causa raiz.

Essa é a diferença de um time que **não só faz DevOps**, mas que **também desenvolve, instrumenta, mede e depura** o ciclo inteiro! Do código ao node do cluster.