Implementar resiliência de infraestrutura com o Kubernetes
Para implementar a resiliência baseada em infraestrutura, você pode usar uma malha de serviço. Além de proporcionar 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. O aplicativo é separado desses recursos operacionais, que são movidos para a camada de infraestrutura. Em termos da arquitetura, uma malha de serviço é composta por dois componentes: um painel de controle e um plano de dados.
O componente do painel de controle conta com vários componentes que dão suporte ao 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.
- Definições de regras e 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 maneira transparente com cada serviço, conhecidos como padrão Sidecar. Cada proxy é configurado para controlar o tráfego de rede de entrada e de saída do pod que contém o serviço. Essa configuração permite que cada proxy seja configurado para:
- Proteger o tráfego via mTLS.
- Rotear o tráfego dinamicamente.
- Aplicar políticas ao tráfego.
- Coletar métricas e informações de rastreamento.
Algumas opções populares de malha de serviço para clusters do Kubernetes incluem o Linkerd, o Istio e o Consul. Este módulo se concentra no Linkerd. O diagrama a seguir mostra as interações entre os componentes dentro do painel de controle e do plano de dados:
Comparação com as abordagens baseadas em código
A estratégia principal de tratamento de falhas do Linkerd consiste em usar repetições e tempos limite. Como o Linkerd tem uma visão sistêmica de todo o cluster, ele pode empregar estratégias de resiliência de maneiras inovadoras. Um exemplo é aplicar as repetições de maneira a adicionar no máximo 20% de carga adicional ao 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ê:
- Precisa adivinhar quais parâmetros de repetição e de tempo limite são apropriados.
- Concentra-se em uma solicitação HTTP específica.
Não há uma forma razoável de responder a uma falha de infraestrutura no código do aplicativo. Considere as centenas ou milhares de solicitações que estão sendo processadas simultaneamente. Até mesmo uma repetição com retirada (contagem de solicitações de tempo) exponencial pode inundar um serviço.
Por outro lado, abordagens baseadas em infraestrutura, como o Linkerd, desconhecem os elementos internos do aplicativo. Por exemplo, transações de banco de dados complexas são invisíveis para o Linkerd. Tais transações podem ser protegidas contra falhas usando o Polly.
Nas próximas unidades, você implementará a resiliência para o serviço de cupom com o Polly e o Linkerd.