Implemente a resiliência da infraestrutura com o Kubernetes
Para implementar a resiliência baseada em infraestrutura, você pode usar uma malha de serviço . Além da resiliência sem alterar o código, uma malha de serviço fornece gerenciamento de tráfego, política, segurança, identidade forte e observabilidade. Seu aplicativo é dissociado desses recursos operacionais, que são movidos para a camada de infraestrutura. Arquitetonicamente falando, uma malha de serviço é composta por dois componentes: um plano de controle e um plano de dados.
O componente do plano de controle tem muitos componentes que suportam o gerenciamento da malha de serviço. O inventário de componentes normalmente inclui:
- Uma interface de gerenciamento, que pode ser uma interface do usuário ou uma API.
- Regras e definições de política que definem como a malha de serviço deve implementar recursos específicos.
- Gerenciamento de segurança para coisas como identidade forte e certificados para mTLS.
- Métricas ou observabilidade para coletar e agregar métricas e telemetria dos aplicativos.
O componente do plano de dados consiste em proxies que são injetados de forma transparente ao lado de cada serviço, o que é conhecido como o padrão Sidecar. Cada proxy é configurado para controlar o tráfego de rede de entrada e saída do pod que contém o serviço. Essa configuração permite que cada proxy seja configurado para:
- Tráfego seguro via mTLS.
- Encaminhe dinamicamente o tráfego.
- Aplique políticas ao tráfego.
- Colete métricas e informações de rastreamento.
Algumas opções populares de malha de serviço para clusters Kubernetes incluem Linkerd, Istio e Consul. Este módulo foca-se no Linkerd. O diagrama a seguir mostra interações entre componentes dentro dos planos de dados e controle:
Comparação com abordagens baseadas em código
A principal estratégia de tratamento de falhas do Linkerd inclui novas tentativas e tempos de espera. Como o Linkerd tem uma visão sistêmica de todo o cluster, ele pode empregar estratégias de resiliência de novas maneiras. Um exemplo é tentar novamente de forma a adicionar um máximo de 20% de carga adicional no serviço de destino. A visão baseada em métricas do Linkerd permite que ele se adapte dinamicamente às condições do cluster em tempo real. Essa abordagem adiciona outra dimensão ao gerenciamento do cluster, mas não adiciona nenhum código.
Com uma abordagem baseada em código, como com o Polly, você:
- São necessários para adivinhar quais parâmetros de repetição e tempo limite são apropriados.
- Concentre-se em uma solicitação HTTP específica.
Não há uma maneira razoável de responder a uma falha de infraestrutura no código do seu aplicativo. Considere as centenas ou milhares de solicitações que estão sendo processadas simultaneamente. Mesmo uma nova tentativa com back-off exponencial (contagem de solicitações de tempos) pode inundar um serviço.
Em contrapartida, abordagens baseadas em infraestrutura, como o Linkerd, desconhecem os detalhes internos da aplicação. Por exemplo, transações complexas de banco de dados são invisíveis para o Linkerd. Tais transações podem ser protegidas contra falhas com Polly.
Nas próximas unidades, você implementará resiliência para o serviço de cupons usando Polly e Linkerd.