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 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 dessas funcionalidades operacionais, que são movidas para a camada de infraestrutura. Em termos arquitetônicos, 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 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.
- 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 itens 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 junto com cada serviço, que é conhecido como o padrão Sidecar. Cada proxy é configurado para controlar o tráfego de rede dentro e fora do pod que contém seu serviço. Essa configuração permite que cada proxy seja configurado para:
- Proteger o tráfego por meio do mTLS.
- Rotear dinamicamente o tráfego.
- 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 kubernetes incluem Linkerd, Istio e Consul. Este módulo se concentra 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 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 novas maneiras. Um exemplo é tentar novamente de forma a adicionar um máximo de 20% de carga adicional ao serviço de destino. A exibiçã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 Polly, você:
- É necessário 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 aplicativo. Considere as centenas ou milhares de solicitações que estão sendo processadas simultaneamente. Até mesmo uma nova tentativa com recuo exponencial (contagem de vezes a solicitação) pode inundar um serviço.
Por outro lado, abordagens baseadas em infraestrutura, como o Linkerd, não têm conhecimento dos detalhes internos do aplicativo. Por exemplo, transações complexas de banco de dados são invisíveis para o Linkerd. Essas transações podem ser protegidas contra falhas com Polly.
Nas próximas unidades, você implementará mecanismos de resiliência para o serviço de cupom usando Polly e Linkerd.