Projete um Service Mesh

Requisitos

• •Injetar automaticamente proxies sidecar em cada pod de serviço sem mudanças na aplicação
• •Aplicar TLS mútuo para toda a comunicação intra-mesh com rotação automática de certificados
• •Implementar service discovery: sidecars descobrem endpoints upstream dinamicamente via plano de controle
• •Fornecer traffic shaping: deployments canary (roteamento baseado em peso), retries e timeouts configuráveis por rota
• •Expor observabilidade por serviço: latência de requisição, taxa de erros e throughput do plano de dados

Requisitos Não-Funcionais

• •Overhead do sidecar: < 1ms de latência adicionada por chamada serviço-a-serviço
• •Rotação de certificados mTLS: sem downtime, a cada 24 horas
• •Plano de controle serve 1.000 proxies sidecar com propagação de configuração < 5 segundos
• •Plano de dados lida com 1 milhão de requisições/segundo em todos os serviços

Restrições

• •Ambiente alvo: cluster Kubernetes com 500+ microsserviços
• •Todo o tráfego leste-oeste (serviço para serviço) deve ser criptografado via mTLS
• •Aplicações não devem exigir mudanças de código para adotar o mesh

Critérios de Avaliação