TL;DR: Implementando OpenSearch no AKS
Este artigo apresenta um guia técnico para a implementação do OpenSearch no Azure Kubernetes Service (AKS), focando em uma fundação robusta com Azure Verified Modules (AVM) e Helm. A estratégia prioriza a separação de tiers (manager e data) como StatefulSets para garantir resiliência e persistência. A conclusão principal é que operacionar cargas de trabalho com estado no Kubernetes exige ir além das configurações padrão, demandando automação de infraestrutura e controle de acesso via Workload Identity.
O OpenSearch é uma solução poderosa para analytics e busca, mas sua operação em ambientes conteinerizados demanda uma mudança de mentalidade em comparação ao que observamos em microserviços stateless. Enquanto um microserviço comum pode ser facilmente reiniciado em qualquer nó, o OpenSearch, por manter o estado persistente, exige atenção rigorosa a recursos como latência de disco, configurações de memória JVM e afinidade de pods.
Como a arquitetura do OpenSearch difere de microserviços tradicionais?
Em um cenário de microserviços, o Deployment gerencia pods efêmeros. O OpenSearch exige que os tiers (Manager e Data) sejam implantados como StatefulSets.
Fonte: Documentação oficial do OpenSearch.
Fonte: Documentação oficial do OpenSearch.
Os pontos de atenção cruciais são:
- Persistência: Cada pod requer seu próprio PersistentVolumeClaim (PVC). Se o disco não estiver disponível ou não estiver bound, o pod não será iniciado, impactando diretamente o seu SLA.
- Isolamento: A separação física ou lógica dos nós de gerenciamento e de dados é essencial para evitar que I/O intenso de busca impacte a estabilidade do cluster.
Estratégia de Deploy com Azure Verified Modules (AVM)
A adoção de módulos verificados pela Microsoft (AVM) para o baseline do AKS é, hoje, a recomendação padrão para times de plataforma que busca reprodutibilidade. Ao invés de comandos az aks create ad hoc que geram desvio de configuração (drift), utilizamos uma infraestrutura declarativa (Terraform ou Bicep) que garante que o pool de nós, a identidade gerenciada e as configurações de rede sigam padrões de governança.
Considerações sobre Segurança e Operações
Um ponto negligenciado em muitos projetos é a gestão de snapshots. O uso de Workload Identity é a alternativa madura aos shared keys (chave de acesso da conta de armazenamento). Isso reforça o endurecimento (hardening) da infraestrutura, removendo segredos estáticos dos arquivos de configuração.
Ao desenhar o acesso, priorize sempre o uso de Internal Load Balancers para o acesso aos Dashboards. A exposição pública do cluster de busca é um risco desnecessário para ambientes de negócio brasileiros que operam sob regulações rígidas de proteção de dados.
O Caminho para a Produção
Essa implementação é o alicerce. A jornada de Day 2 Operations exigirá, posteriormente, foco em:
- Observabilidade: Monitorar métricas customizadas de JVM e latência de busca via Azure Monitor.
- Resiliência: Testes de falha em nível de multizona.
- Capacidade: Benchmarking contínuo para evitar disk pressure e garantir throughput.
Consulte o repositório de referência (github.com/prwani/oss-data-on-aks) para explorar os manifests e scripts de automação. A automação é a chave para a estabilidade — trate sua plataforma OpenSearch como um produto, não como uma VM reempacotada em containers.
Perguntas Frequentes
-
Por que utilizar Helm charts separados para os tiers de Manager e Data no OpenSearch?
A separação permite isolar os requisitos de recursos, como JVM heap e performance de I/O de disco (Premium SSD), garantindo a estabilidade exigida para o cluster e a resiliência das eleições de master. -
É possível utilizar Managed Identities para snapshots em vez de chaves de acesso fixas?
Sim. Recomenda-se utilizar o AKS OIDC issuer e Workload Identity para autenticar o snapshot service ao Azure Blob Storage de maneira segura, eliminando a dependência de chaves de conta expostas. -
O acesso ao OpenSearch Dashboards deve ser público?
Não. É uma boa prática de segurança configurar o Dashboards e a API por meio de serviços internos (ClusterIP ou Load Balancer interno), reduzindo a exposição direta do serviço na internet.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
