À medida que a adoção do Kubernetes cresce nas empresas, as equipes de plataforma frequentemente enfrentam um desafio crítico: o aumento exponencial nos custos e na complexidade da observabilidade. Quando o objetivo é oferecer visibilidade isolada para múltiplas equipes de desenvolvimento dentro de um Service Mesh, a prática comum de criar instâncias isoladas de ferramentas como Prometheus, Jaeger e Grafana para cada tenant pode rapidamente se tornar insustentável.
O Problema da Fragmentação de Telemetria
A abordagem de "hard tenancy" — onde cada equipe possui sua própria stack completa de monitoramento — garante isolamento robusto, mas gera um custo operacional e de infraestrutura proibitivo. O desperdício de recursos de computação e armazenamento, somado ao esforço de manter dezenas de instâncias idênticas, desvia o foco dos engenheiros de tarefas de valor agregado para a simples manutenção de infraestrutura.
A Abordagem de Soft Tenancy com OpenTelemetry
Uma alternativa mais eficiente é a utilização do OpenTelemetry (OTel) Collector como um motor de roteamento centralizado. Em vez de implantar silos de observabilidade, o Collector atua como uma camada intermediária entre o Service Mesh e o armazenamento final. Isso permite que a coleta seja centralizada, enquanto o processamento e o roteamento dos dados são feitos de forma inteligente.
Os principais benefícios desta arquitetura incluem:
- Roteamento Inteligente: O Collector inspeciona metadados de traces e métricas. Com base no namespace de origem, é possível aplicar regras de processamento específicas para cada tenant.
- Desacoplamento de Armazenamento: É possível enviar dados de diferentes equipes para destinos distintos. Por exemplo, dados de desenvolvimento podem ser direcionados para um armazenamento local de baixo custo, enquanto métricas críticas de produção são enviadas para soluções gerenciadas de alta performance.
- Redução de Overhead: Mantém-se um único Service Mesh e uma camada de coleta flexível, reduzindo drasticamente a carga de gerenciamento sobre a equipe de operações.
Implementação com Kiali
O Kiali, como console de gerenciamento para o Istio Service Mesh, desempenha um papel fundamental ao oferecer uma interface intuitiva para os desenvolvedores. Para implementar um modelo de multi-tenancy eficiente, a configuração do Kiali deve ser adaptada:
- Discovery Selectors: Essencial para garantir que os usuários visualizem apenas os namespaces aos quais possuem permissão via RBAC.
- Configuração de Instância: Cada instância do Kiali deve ser configurada para atuar individualmente, utilizando parâmetros de
instance_namee URIs específicas para cada tenant. - Autenticação e Parâmetros: Ao utilizar a estratégia de "soft tenancy", a separação é feita através de autenticação e parâmetros de configuração, mantendo a experiência do usuário final fluida enquanto a infraestrutura permanece otimizada.
Considerações Técnicas e Cuidados
Para implementar este modelo, é necessário garantir que o ambiente base esteja corretamente configurado. Isso inclui a instalação dos operadores necessários para o Service Mesh, o coletor de telemetria e as stacks de armazenamento (como Loki para logs e Tempo para traces).
A transição para um modelo de observabilidade centralizada exige um planejamento rigoroso de RBAC (Role-Based Access Control) e uma definição clara das políticas de retenção de dados. Ao centralizar a ingestão, a segurança torna-se um ponto único de atenção: garanta que o OpenTelemetry Collector esteja devidamente protegido e que as políticas de roteamento de dados respeitem as normas de conformidade da sua organização.
Adotar essa arquitetura não apenas reduz o consumo de recursos de nuvem, mas também simplifica a rotina das equipes de plataforma, permitindo que a observabilidade acompanhe a escala do negócio sem comprometer o orçamento ou a estabilidade do cluster.