Construindo um Controlador de Ingress Apache APISIX Mais Robusto com Litmus Chaos

Visão Geral

A Engenharia do Caos desempenha um papel crucial na avaliação e melhoria da resiliência e confiabilidade de sistemas de software. Ao simular eventos disruptivos, as organizações podem identificar vulnerabilidades e aprimorar o design e a arquitetura do sistema. Neste artigo, discutiremos a importância da Engenharia do Caos e sua aplicação específica no design de experimentos de Caos para Ingress Controllers.

Por que Precisamos da Engenharia do Caos?

A Engenharia do Caos é o processo de avaliar sistemas de software simulando eventos destrutivos, como interrupções de rede de servidores ou limitação de API. Ao introduzir caos ou falhas no sistema, podemos testar a resiliência e confiabilidade do sistema em condições instáveis e inesperadas.

A Engenharia do Caos ajuda as equipes a identificar riscos ocultos, monitorar vulnerabilidades e identificar gargalos de desempenho em sistemas distribuídos, simulando cenários do mundo real em um ambiente de controle seguro. Essa abordagem previne efetivamente interrupções no sistema ou paradas na produção.

A abordagem da Netflix para lidar com sistemas nos inspirou a adotar uma abordagem mais científica, o que impulsionou o nascimento e desenvolvimento da Engenharia do Caos.

1. Introdução de Eventos Disruptivos

A Engenharia do Caos envolve a introdução de eventos disruptivos, como partições de rede, degradação de serviço e restrições de recursos, para simular cenários do mundo real e testar a capacidade do sistema de lidar com condições inesperadas. O objetivo é identificar vulnerabilidades ou fraquezas e melhorar o design e a arquitetura do sistema para torná-lo mais robusto e resiliente.

2. Testando a Resiliência do Sistema

No cenário tecnológico em constante evolução e acelerado de hoje, testar a resiliência do sistema é crucial para garantir que os sistemas sejam robustos, escaláveis e capazes de lidar com desafios e condições inesperadas. A Engenharia do Caos é uma maneira eficaz de alcançar isso, introduzindo eventos disruptivos para observar a resposta do sistema e medir sua capacidade de lidar com condições inesperadas.

As organizações podem monitorar logs do sistema, métricas de desempenho e experiência do usuário para medir o impacto de eventos disruptivos na resiliência do sistema. Acompanhar essas métricas fornece uma melhor compreensão do comportamento do sistema, permitindo que as organizações identifiquem áreas para melhoria.

3. Descobrindo Problemas Ocultos

Sistemas distribuídos são propensos a problemas ocultos, como perda de dados, gargalos de desempenho e erros de comunicação, que podem ser difíceis de detectar, pois podem se tornar visíveis apenas quando o sistema está sob pressão. A Engenharia do Caos pode ajudar a revelar esses problemas ocultos, introduzindo eventos disruptivos. Essas informações podem então ser usadas para melhorar o design e a arquitetura do sistema, tornando-o mais resiliente e confiável.

Identificar e resolver esses problemas proativamente aumenta a confiabilidade e o desempenho dos sistemas, prevenindo tempo de inatividade, reduzindo o risco de perda de dados e garantindo que o sistema funcione sem problemas.

4. O que Vale e Por que Precisamos Disso?

Sistemas distribuídos são complexos e inerentemente caóticos, o que pode levar a falhas. O uso de arquitetura em nuvem e microservices oferece muitas vantagens, mas também traz complexidade e caos. Os engenheiros são responsáveis por tornar o sistema o mais confiável possível.

Sem testes, não há confiança para usar o projeto em um ambiente de produção. Além dos testes unitários convencionais e testes de ponta a ponta, a introdução de testes de caos torna o sistema mais robusto.

Quando ocorre um erro, repará-lo leva tempo e pode causar perdas imensuráveis, com efeitos de longo prazo no futuro. Durante o processo de reparo, vários fatores precisam ser considerados, incluindo a complexidade do sistema, o tipo de erro e possíveis novos problemas, para garantir um reparo final eficaz.

Além disso, quando um projeto de código aberto traz falhas graves para os usuários no ambiente de produção, muitos usuários podem migrar para outros produtos.

Como Projetar Experimentos de Caos para um Ingress Controller?

1. O que é Ingress?

Ingress é um objeto de recurso do Kubernetes que contém regras sobre como clientes externos podem acessar serviços dentro do cluster. Essas regras determinam quais clientes podem acessar quais serviços, como as solicitações dos clientes são roteadas para os serviços apropriados e como as solicitações dos clientes são tratadas.

2. O que é um Ingress Controller?

Um recurso Ingress requer um Ingress Controller para processá-lo. O controlador traduz as regras do Ingress em configurações em um proxy, permitindo que clientes externos acessem serviços dentro do cluster. Em um ambiente de produção, os Ingress Controllers precisam ter capacidades complexas, como limitar fontes de acesso e métodos de solicitação, autenticação e autorização. A maioria dos Ingress Controllers estende a semântica do Ingress por meio de anotações no recurso Ingress.

3. O que é o Apache APISIX Ingress Controller?

O Apache APISIX Ingress Controller é um tipo especializado de balanceador de carga que ajuda os administradores a gerenciar e controlar o tráfego de Ingress. Ele usa o APISIX como um plano de dados para fornecer aos usuários roteamento dinâmico, balanceamento de carga, escalabilidade elástica, políticas de segurança e outros recursos para melhorar o controle de rede e garantir maior disponibilidade e segurança para seus negócios. O APISIX Ingress Controller suporta três modos de configuração: Kubernetes Ingress, recursos personalizados e Gateway API.

4. O que é o Litmus Chaos?

Litmus Chaos é um framework de Engenharia do Caos de código aberto que fornece uma infraestrutura experimental para validar a estabilidade de controladores e arquiteturas de microservices. Ele pode simular vários ambientes, como ambientes de nível de contêiner e de aplicação, desastres naturais, falhas e atualizações, para entender como o sistema responde a essas mudanças. O framework também pode explorar as mudanças de comportamento entre controladores e aplicações, e como os controladores respondem a desafios em estados específicos. O Litmus Chaos oferece capacidades convenientes de integração de observabilidade e é altamente extensível.

5. Como Projetar Experimentos de Caos?

Aqui está um procedimento geral para projetar experimentos de caos em qualquer cenário:

• Defina o sistema em teste: Identifique os componentes específicos do sistema que você deseja experimentar e desenvolva objetivos claros e mensuráveis para o experimento. Isso inclui criar uma lista abrangente dos componentes, como hardware e software, que serão testados, bem como definir o escopo do experimento e os resultados esperados.

kube-apiserver: se ocorrer uma exceção, a escrita do recurso Ingress falhará. Ingress-controller: Interrupção de rede, Crash, Podfaults, I/O data-plane: Interrupção de rede, Crash, Podfaults, I/O

• Escolha o experimento certo: Selecione um experimento que esteja alinhado com os objetivos que você definiu e que imite de perto um cenário do mundo real. Isso ajudará a garantir que o experimento produza resultados significativos e reflita com precisão o comportamento do sistema.
• Estabeleça uma hipótese: Estabeleça uma hipótese sobre como o sistema se comportará durante o experimento e quais resultados você espera. Isso deve ser baseado em experiência ou pesquisa, e deve ser razoável e testável.
• Execute o experimento: Execute o experimento em um ambiente controlado, como um ambiente de staging, para limitar o potencial de dano ao sistema de produção. Colete todos os dados relevantes durante o experimento e armazene-os com segurança. Pode haver opiniões divergentes sobre se o experimento deve ocorrer diretamente no ambiente de produção. No entanto, para a maioria dos cenários, precisamos garantir que o Objetivo de Nível de Serviço (SLO) do sistema seja atendido.
• Avalie os resultados: Avalie os resultados do experimento e compare-os com sua hipótese. Analise os dados coletados e documente quaisquer observações ou descobertas. Isso inclui identificar quaisquer resultados inesperados ou discrepâncias e determinar como eles podem afetar o sistema. Além disso, considere como os resultados do experimento podem ser usados para melhorar o sistema.

Principais Cenários de Uso do Ingress Controller

A capacidade mais importante de um Ingress Controller é o proxy de tráfego, e todas as outras funções são baseadas nessa função central. Portanto, ao realizar Engenharia do Caos, o proxy de tráfego normal é a métrica chave.

Para definir o sistema em teste para o APISIX Ingress Controller, os usuários precisam criar configurações de rota, como Ingress, Gateway API ou CRD, e aplicá-las ao cluster Kubernetes via Kubectl. Esse processo passa pelo kube-apiserver para autenticação, autorização, admissão e outros procedimentos relacionados, e é então armazenado no etcd.

O APISIX Ingress Controller monitora continuamente as mudanças nos recursos do Kubernetes. Essas configurações são então convertidas em configurações no plano de dados. Quando um cliente solicita o plano de dados, ele acessa o serviço upstream de acordo com as regras de roteamento.

Se o kube-apiserver tiver uma exceção, isso impedirá que a configuração seja criada ou que o Ingress Controller obtenha a configuração correta. Da mesma forma, se houver uma exceção no plano de dados, como uma interrupção de rede ou um Pod eliminado, ele também não poderá fazer o proxy de tráfego normal.

O escopo do nosso experimento é principalmente o impacto na disponibilidade do sistema se o Ingress Controller tiver uma exceção.

1. Passos Operacionais Detalhados

• Escolha o experimento certo: Podemos cobrir muitos cenários de configuração incorreta por meio de testes de ponta a ponta. Principalmente por meio da Engenharia do Caos, podemos verificar se o plano de dados ainda pode fazer o proxy de tráfego normalmente quando o Ingress Controller encontra uma exceção, como erros de DNS, interrupções de rede ou Pod eliminado.
• Estabeleça uma hipótese: Para cada cenário, podemos criar uma hipótese como "Quando o Pod do Ingress-controller recebe X?, a solicitação do cliente ainda pode obter uma resposta normal."
• Execute o experimento: O experimento e as variáveis já foram determinados, então tudo o que resta é experimentar.
  O Litmus Chaos fornece várias maneiras de conduzir experimentos. Podemos fazer isso através do Litmus Portal. Para isso, precisamos criar um cenário de Caos, selecionar a aplicação a ser experimentada, e esses passos são relativamente simples. No entanto, devemos prestar atenção ao fato de que o Litmus Chaos inclui um recurso Probes.

Probes são verificações plugáveis que podem ser definidas dentro do ChaosEngine para qualquer Experimento de Caos. Os pods do experimento executam essas verificações com base no modo em que são definidos e consideram seu sucesso como condições necessárias para determinar o veredito do experimento, além das verificações padrão integradas. Ao mesmo tempo, também podemos agendar experimentos, o que é uma função muito valiosa.

Além disso, o Litmus Chaos também suporta a execução de experimentos por meio da submissão de manifestos YAML.

• Avalie os resultados: O Litmus Chaos possui relatórios estatísticos integrados e pode ser integrado com Prometheus e Grafana para fornecer um painel unificado para integração.

2. Benefícios e Futuro

Através de testes rigorosos de ponta a ponta e o poder da Engenharia do Caos, estamos confiantes na estabilidade e confiabilidade do APISIX Ingress Controller entregue. A Engenharia do Caos também nos ajudou a identificar e corrigir bugs. Estamos constantemente trabalhando para melhorar e evoluir este projeto incrível, e convidamos você a se juntar à nossa comunidade.