Implemente a resiliência da infraestrutura com o Kubernetes
Para implementar resiliência baseada na infraestrutura, pode utilizar uma malha de serviços. Além de proporcionar resiliência sem alterar o código, uma malha de serviços fornece gestão de tráfego, políticas, segurança, identidade forte e observabilidade. A sua aplicação é desassociada destas capacidades operacionais, que serão movidas para a camada da infraestrutura. Em termos da arquitetura, uma malha de serviços é composta por dois componentes: um plano de controlo e um plano de dados.
O componente do plano de controle tem muitos componentes que suportam o gerenciamento da malha de serviço. Por norma, o inventário de componentes inclui:
- Uma interface de gestão, que pode ser uma IU ou API.
- Definições de políticas e regras que definem a forma como a malha de serviços deve implementar capacidades específicas.
- Gestão de segurança para aspetos como uma identidade forte e certificados para mTLS.
- Métricas ou observabilidade para recolher e agregar métricas e telemetria das aplicações.
O componente de plano de dados consiste em proxies que são injetados de forma transparente ao lado de cada serviço, isso é conhecido como 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. Esta configuração permite que cada proxy seja configurado para:
- Proteger o tráfego através de mTLS.
- Encaminhar o tráfego de modo dinâmico.
- Aplicar políticas ao tráfego.
- Recolher informações de métricas e rastreio.
Algumas opções populares de malha de serviços para clusters do Kubernetes incluem o Linkerd, o Istio e o Consul. Este módulo foca-se no Linkerd. O seguinte diagrama mostra interações entre componentes dentro dos planos de controlo e de dados:
Comparação com as abordagens baseadas no código
A principal estratégia de tratamento de falhas do Linkerd inclui novas tentativas e tempos limites. 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 é efetuar as repetições de forma a adicionar um máximo de 20 por cento de carga adicional ao serviço de destino. A vista baseada em métricas do Linkerd permite-lhe adaptar-se dinamicamente às condições do cluster em tempo real. Esta abordagem adiciona uma nova dimensão à gestão do cluster, mas não adiciona código.
Com uma abordagem baseada no código, como a do Polly:
- Tem de adivinhar quais são os parâmetros adequados de repetição e tempo limite.
- Foca-se num pedido HTTP específico.
Não existe uma forma razoável de responder a uma falha de infraestrutura no código da sua aplicação. Considere as centenas ou milhares de pedidos que estão a ser processados em simultâneo. Uma simples repetição com término exponencial (vezes o número de pedidos) pode inundar um serviço.
Por outro lado, abordagens baseadas em infraestrutura, como o Linkerd, desconhecem os internos do aplicativo. Por exemplo, as transações de base de dados complexas são invisíveis para o Linkerd. Essas transações podem ser protegidas contra falhas através do Polly.
Nas próximas unidades, você implementará resiliência para o serviço de cupons usando Polly e Linkerd.