Azure Container Storage v2.1: Analisando o impacto do Elastic SAN na escalabilidade do AKS

A maturidade das cargas de trabalho stateful no Kubernetes é um dos maiores desafios de engenharia para empresas que buscam escalar microsserviços sem comprometer a performance ou a simplicidade operacional. A recente disponibilização (General Availability) do Azure Container Storage (ACStor) v2.1.0 traz uma mudança de patamar para usuários de AKS, especialmente ao integrar o Elastic SAN (ESAN) como backend de armazenamento.

Para times de infraestrutura e FinOps, esta atualização não é apenas mais uma feature de storage; é uma resposta estratégica às limitações de discos por VM. Ao centralizar o pool de IOPS e throughput, o desenho da arquitetura cloud ganha um novo nível de flexibilidade.

Por que o Elastic SAN altera o jogo no Kubernetes?

O grande gargalo no uso de persistent volumes tradicionais em nuvem sempre foi a restrição imposta pelo hypervisor ou pelo limite de attachment de discos por nó. Com o ESAN, o AKS utiliza iSCSI sobre TCP/IP para contornar esses limites rígidos (como o teto comum de 64 discos por VM).

• Escalabilidade Vertical e Horizontal: Ao desacoplar a capacidade do nó, você pode empacotar muito mais pods com volumes persistentes em um único worker node.
• Eficiência de Custos: Em vez de provisionar discos menores e superdimensionados para atingir IOPS específicos, você centraliza a capacidade em um único pool gerenciado. Isso reduz o desperdício de IOPS ociosos em volumes menores.
• Agilidade operacional: O estabelecimento de sessões iSCSI é otimizado, reduzindo drasticamente o tempo de attach/detach de volumes durante eventos de escala — um ponto crítico para sistemas com alta rotatividade de containers.

Cenários de aplicação prática para o mercado brasileiro

Identificamos três cenários onde esta atualização traz valor imediato para empresas que operam no Brasil:

1. Multi-tenancy DBaaS: Se você roda plataformas de banco de dados conteinerizado (PostgreSQL, MySQL, etc.) para diversos clientes, a consolidação via ESAN permite uma gestão de storage muito mais limpa, evitando a fragmentação de recursos por cliente.
2. Ambientes de Desenvolvimento em escala: Ambientes que criam e destroem instâncias (desktops virtuais ou dev-containers com persistência) frequentemente esbarram em limites de API de providers de storage. O ESAN mitiga esse 'thrashing' de provisionamento.
3. Workloads de alta densidade: Aplicações de processamento de dados que exigem centenas de PVs (Persistent Volumes) de pequeno porte agora podem rodar em clusters mais densos, reduzindo o custo total de infraestrutura compute (Node Pools).

Flexibilidade técnica: Instalação on-demand e Node Selectors

A maturidade da v2.1 se reflete também na experiência do engenheiro. O modelo de instalação modular permite que o cluster não carregue drivers de storage que não serão utilizados, otimizando o footprint do plano de controle e dos nós. Além disso, o suporte a node selectors permite direcionar o movimento de dados apenas para node pools com características específicas (como instâncias otimizadas para storage), separando claramente as cargas de computação pura das cargas dependentes de I/O pesado.

CopiarapiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-nvme
  annotations:
    storageoperator.acstor.io/nodeAffinity: |
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.azure.com/agentpool
            operator: In
            values: [mygpu,mygpu2]      
provisioner: localdisk.csi.acstor.io
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Pontos de atenção para a implementação

• Validação de I/O: Antes de migrar workloads críticos, realize testes de carga para verificar se o throughput do ESAN atende ao padrão de acesso da sua aplicação. O iSCSI introduz camadas adicionais na rede que podem exigir tuning de kernel ou rede no seu node pool.
• Estratégia de Pool: Utilize os node selectors para garantir que o tráfego de storage não compita por largura de banda de rede com microsserviços latência-sensíveis.

Para equipes que buscam estabilidade e escalabilidade, o Azure Container Storage v2.1 é uma evolução natural que remove um dos maiores entraves do Kubernetes em produção: a complexidade do estado.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.