Como aumentar a resiliência no Kubernetes com gerenciamento avançado de tráfego

Jenn GileDiretor de Marketing de Produto, NGINX

Editor – Este post faz parte de uma série de 10 partes:

1. Reduza a complexidade com Kubernetes pronto para produção
2. Como melhorar a resiliência no Kubernetes com o gerenciamento avançado de tráfego (este artigo)
3. Como melhorar a visibilidade no Kubernetes
4. Seis maneiras de proteger o Kubernetes usando ferramentas de gerenciamento de tráfego
5. Guia para escolher um controlador de Ingress, Parte 1: identifique seus requisitos
6. Guia para escolher um controlador de Ingress, Parte 2: riscos e preparação para o futuro
7. Guia para escolher um controlador de Ingress, parte 3: código aberto vs. padrão vs. comercial
8. Um guia para escolher um controlador de Ingress, parte 4: opções de controladores de Ingress da NGINX
9. Como escolher uma malha de serviços
10. Teste de desempenho de controladores de Ingress NGINX em um ambiente de nuvem Kubernetes dinâmico

Você também pode baixar a coleção completa de artigos como um e-book gratuito – Levando o Kubernetes do teste à produção.

Há uma maneira muito fácil de perceber que uma empresa não está usando com sucesso as tecnologias modernas de desenvolvimento de aplicativos: seus clientes logo reclamam nas redes sociais. Eles reclamam quando não conseguem assistir ao lançamento mais recente daquela série que todo mundo quer maratonar. Ou acessar o internet banking. Ou fazer uma compra porque o carrinho está expirando.

Mesmo que os clientes não reclamem publicamente, isso não significa que uma experiência ruim não tenha consequências. Um de nossos clientes – uma grande seguradora – nos contou que perde clientes quando sua página inicial não carrega em até 3 segundos.

Todas essas reclamações dos usuários sobre baixo desempenho ou indisponibilidade apontam para um culpado em comum: a resiliência... ou a falta dela. A grande vantagem das tecnologias de microsserviços — incluindo contêineres e Kubernetes — é que elas podem melhorar significativamente a experiência do cliente ao aumentar a resiliência dos seus aplicativos. Como? Tudo se resume à arquitetura.

Gosto de explicar a principal diferença entre as arquiteturas monolítica e de microsserviços usando a analogia de um cordão de luzes natalinas. Quando uma lâmpada queima em um cordão mais antigo, o cordão inteiro se apaga. Se não for possível substituir a lâmpada, o único lugar que vale a pena decorar com esse cordão é o interior da lata de lixo. Esse modelo antigo de luzes é como um aplicativo monolítico, que também tem componentes fortemente acoplados e deixa de funcionar quando um deles falha.

Mas a indústria de iluminação, assim como a de software, identificou esse problema. Quando uma lâmpada queima em um cordão de luzes moderno, as demais continuam brilhando intensamente, da mesma forma que um aplicativo de microsserviços bem projetado continua funcionando mesmo quando uma instância de serviço falha.

Gerenciamento de tráfego no Kubernetes

Contêineres são uma escolha popular em arquiteturas de microsserviços porque são ideais para criar aplicações usando componentes menores e independentes — eles são leves, portáteis e fáceis de escalar. Kubernetes é o padrão de fato para a orquestração de contêineres, mas há muitos desafios para preparar o Kubernetes para ambientes de produção. Um dos elementos que melhora tanto o controle sobre as aplicações do Kubernetes quanto a resiliência delas é uma estratégia madura de gerenciamento de tráfego, que permite controlar serviços em vez de pacotes e adaptar as regras de gerenciamento de tráfego dinamicamente ou por meio da API do Kubernetes. Embora o gerenciamento de tráfego seja importante em qualquer arquitetura, duas ferramentas são essenciais para aplicações de alto desempenho: controle de tráfego e divisão de tráfego.

Controle de tráfego

O controle de tráfego (às vezes chamado de roteamento de tráfego ou modelagem de tráfego) consiste em controlar para onde o tráfego vai e como chega até lá. Ele é essencial ao executar o Kubernetes em produção, pois permite proteger sua infraestrutura e seus aplicativos contra ataques e picos de tráfego. Duas técnicas que podem ser incorporadas ao ciclo de desenvolvimento dos seus aplicativos são limitação de taxa e interrupção de circuito.

• Caso de uso: Quero proteger os serviços contra um número excessivo de solicitações
  Solução: Limitação de taxaSeja mal-intencionado (por exemplo, tentativas de adivinhar senhas por força bruta e ataques DDoS) ou legítimo (como clientes aproveitando uma promoção), um grande volume de solicitações HTTP pode sobrecarregar seus serviços e fazer com que seus aplicativos parem de funcionar. A limitação de taxa restringe o número de solicitações que um usuário pode fazer em determinado período. As solicitações podem incluir algo tão simples quanto uma solicitação GET para a página inicial de um site ou uma solicitação POST em um formulário de login. Durante um ataque DDoS, por exemplo, você pode usar a limitação de taxa para restringir a taxa de solicitações recebidas a um valor típico de usuários reais.
• Caso de uso: Quero evitar falhas em cascata
  Solução: Circuit breakerQuando um serviço está indisponível ou apresenta alta latência, pode levar muito tempo para que as solicitações recebidas atinjam o tempo limite e os clientes recebam uma resposta de erro. Esses longos tempos limite podem causar uma falha em cascata, na qual a indisponibilidade de um serviço provoca tempos limite em outros serviços e, por fim, a falha da aplicação como um todo. Os circuit breakers evitam falhas em cascata monitorando falhas nos serviços. Quando o número de solicitações com falha para um serviço ultrapassa um limite predefinido, o circuit breaker é acionado e começa a retornar uma resposta de erro aos clientes assim que as solicitações chegam, desviando efetivamente o tráfego do serviço. O circuit breaker continua interceptando e rejeitando solicitações por um período definido antes de permitir que um número limitado delas seja processado como teste. Se essas solicitações forem bem-sucedidas, o circuit breaker deixará de restringir o tráfego. Caso contrário, o período é reiniciado e o circuit breaker volta a rejeitar solicitações durante o tempo definido.

Divisão de tráfego

A divisão de tráfego (às vezes chamada de teste de tráfego) é uma subcategoria do controle de tráfego e consiste em controlar a proporção do tráfego de entrada direcionada a diferentes versões de uma aplicação de backend executadas simultaneamente em um ambiente (geralmente, a versão atual em produção e uma versão atualizada). Ela é uma parte essencial do ciclo de desenvolvimento de aplicações, pois permite que as equipes testem a funcionalidade e a estabilidade de novos recursos e versões sem afetar negativamente os clientes. Alguns cenários de implantação úteis incluem roteamento para depuração, implantações canário, testes A/B e implantações azul-verde. (Há bastante inconsistência no uso desses quatro termos no setor. Aqui, nós os usamos de acordo com o que entendemos de suas definições.)

• Caso de uso: Estou pronto para testar uma nova versão em produção
  Solução: Roteamento de depuraçãoDigamos que você tenha um aplicativo bancário e pretenda adicionar um recurso de pontuação de crédito. Antes de testá-lo com os clientes, provavelmente você vai querer ver como ele se comporta em produção. O roteamento de depuração permite implantá-lo publicamente e, ao mesmo tempo, “ocultá-lo” dos usuários reais, permitindo que apenas determinados usuários o acessem com base em atributos da Camada 7, como um cookie de sessão, ID de sessão ou ID de grupo. Por exemplo, você pode permitir o acesso apenas a usuários que tenham um cookie de sessão de administrador – as solicitações deles são encaminhadas para a nova versão com o recurso de pontuação de crédito, enquanto todos os demais continuam usando a versão estável.
  
• Caso de uso: Preciso garantir que minha nova versão seja estável
  Solução: Implantação canárioO conceito de implantação canário vem de uma antiga prática de mineração, na qual os mineiros levavam um canário engaiolado para dentro das minas de carvão como um alerta precoce da presença de gases tóxicos. O gás matava o canário antes de matar os mineiros, permitindo que eles escapassem rapidamente do perigo. No mundo dos aplicativos, nenhuma ave é ferida! As implantações canário oferecem uma maneira segura e ágil de testar a estabilidade de um novo recurso ou de uma nova versão. Uma implantação canário típica começa com uma grande parcela (digamos, 99%) dos usuários na versão estável e transfere um pequeno grupo (o 1% restante) para a nova versão. Se a nova versão falhar, por exemplo, travando ou retornando erros aos clientes, você poderá transferir imediatamente o grupo de teste de volta para a versão estável. Se ela for bem-sucedida, você poderá migrar os usuários da versão estável para a nova, seja todos de uma só vez ou (como é mais comum) por meio de uma migração gradual e controlada.
  
• Caso de uso: Preciso descobrir se os clientes preferem uma nova versão à versão atual
  Solução: Teste A/BAgora que você confirmou que o novo recurso funciona em produção, talvez queira obter o feedback dos clientes sobre o sucesso dele com base em indicadores-chave de desempenho (KPIs), como número de cliques, usuários recorrentes ou avaliações explícitas. O teste A/B é um processo usado em diversos setores para medir e comparar o comportamento dos usuários a fim de determinar o sucesso relativo de diferentes versões de um produto ou aplicativo entre a base de clientes. Em um teste A/B típico, 50% dos usuários recebem a Versão A (a versão atual do aplicativo), enquanto os outros 50% recebem a Versão B (a versão com o recurso novo, mas estável). A vencedora é aquela que apresenta o melhor conjunto geral de KPIs.
  
• Caso de uso: Quero migrar meus usuários para uma nova versão sem tempo de inatividade
  Solução: Implantação azul-verdeAgora, digamos que seu aplicativo bancário esteja prestes a passar por uma grande mudança de versão… parabéns! No passado, atualizar versões geralmente significava tempo de inatividade para os usuários, pois era necessário desativar a versão antiga antes de colocar a nova versão em produção. Porém, no ambiente competitivo atual, o tempo de inatividade para atualizações é inaceitável para a maioria dos usuários. As implantações azul-verde reduzem significativamente, ou até eliminam, o tempo de inatividade durante as atualizações. Basta manter a versão antiga (azul) em produção enquanto implanta simultaneamente a nova versão (verde) no mesmo ambiente de produção. A maioria das organizações não quer migrar 100% dos usuários da versão azul para a verde de uma só vez — afinal, e se a versão verde falhar?! A solução é usar uma implantação canário para migrar os usuários nos incrementos que melhor atendam à sua estratégia de mitigação de riscos. Se a nova versão for um desastre, você poderá facilmente reverter todos os usuários para a versão estável com apenas algumas teclas.
  

Como o NGINX pode ajudar

Você pode realizar o controle e a divisão avançados do tráfego com a maioria dos controladores de Ingress e das malhas de serviço. A tecnologia a ser usada depende da arquitetura e dos casos de uso da sua aplicação. Por exemplo, usar um controlador de Ingress faz sentido nestes três cenários:

• Seus aplicativos têm apenas um endpoint, como ocorre com aplicativos simples ou monolíticos que você migrou para o Kubernetes usando a abordagem “lift and shift”.
• Não há comunicação entre serviços no seu cluster.
• Há comunicação entre serviços, mas você ainda não está usando uma malha de serviços.

Se a sua implantação for complexa o suficiente para exigir uma malha de serviços, um caso de uso comum é dividir o tráfego entre os serviços para testar ou atualizar microsserviços individuais. Por exemplo, talvez você queira fazer uma implantação canário por trás do front-end móvel, entre duas versões diferentes da API do seu microsserviço de geolocalização.

No entanto, configurar a divisão de tráfego com alguns controladores Ingress e malhas de serviço pode ser demorado e propenso a erros por vários motivos:

• Controladores de Ingress e malhas de serviço de diferentes fornecedores implementam os recursos do Kubernetes de maneiras distintas.
• O Kubernetes não foi realmente projetado para gerenciar e compreender o tráfego da camada 7.
• Alguns controladores de Ingress e malhas de serviço não oferecem suporte ao gerenciamento avançado de tráfego.

Com o NGINX Ingress Controller e o NGINX Service Mesh, você pode configurar facilmente políticas robustas de roteamento e divisão de tráfego em segundos. Confira esta demonstração ao vivo com nossos especialistas e continue lendo para saber como ajudamos você a economizar tempo com configurações mais simples, personalizações avançadas e maior visibilidade.

Configuração mais fácil com recursos do NGINX Ingress e a especificação SMI

Estes recursos do NGINX facilitam a configuração:

• Recursos NGINX Ingress para o NGINX Ingress Controller – Embora o recurso Ingress padrão do Kubernetes facilite a configuração do encerramento SSL/TLS, do balanceamento de carga HTTP e do roteamento de camada 7, ele não inclui os recursos de personalização necessários para interrupção de circuitos, testes A/B e implantação azul-verde. Em vez disso, os usuários que não utilizam o NGINX precisam recorrer a anotações, ConfigMaps e modelos personalizados, que não oferecem controle granular, são inseguros, propensos a erros e difíceis de usar. O NGINX Ingress Controller inclui recursos NGINX Ingress como alternativa ao recurso Ingress padrão (que também é compatível). Eles oferecem um estilo de configuração nativo, com tipagem segura e indentação, que simplifica a implementação do balanceamento de carga do Ingress. Os recursos NGINX Ingress oferecem um benefício adicional aos usuários atuais do NGINX: facilitam o reaproveitamento de configurações de balanceamento de carga de ambientes que não usam Kubernetes, permitindo que todos os seus balanceadores de carga NGINX utilizem as mesmas configurações.
• NGINX Service Mesh com SMI – O NGINX Service Mesh implementa a Service Mesh Interface (SMI), uma especificação que define uma interface padrão para malhas de serviço no Kubernetes, com recursos tipados como TrafficSplit, TrafficTarget e HTTPRouteGroup. Usando métodos padrão de configuração do Kubernetes, o NGINX Service Mesh e as extensões SMI do NGINX facilitam a implantação de políticas de divisão de tráfego, como implantações canário, com interrupção mínima do tráfego de produção. Por exemplo, veja como definir uma implantação canário com o NGINX Service Mesh:

apiVersion: split.smi-spec.io/v1alpha2kind: TrafficSplit
metadata:
name: target-ts
spec:
service: target-svc
backends:
- service: target-v1-0
    weight: 90
- service: target-v2-0
    weight: 10

• Nosso tutorial, Implantações usando divisão de tráfego, apresenta exemplos de padrões de implantação que utilizam a divisão de tráfego, incluindo implantações canário e azul-verde.

Controle e divisão de tráfego mais sofisticados com personalizações avançadas

Estes recursos do NGINX facilitam o controle e a divisão do tráfego de maneiras sofisticadas:

• O armazenamento de chave-valor para implantações canário – Ao realizar testes A/B ou implantações azul-verde, talvez você queira direcionar o tráfego para a nova versão em incrementos específicos, por exemplo, 0%, 5%, 10%, 25%, 50% e 100%. Com a maioria das ferramentas, esse é um processo bastante manual, pois é necessário editar a porcentagem e recarregar o arquivo de configuração a cada incremento. Devido a todo esse trabalho adicional, você pode decidir correr o risco de passar diretamente de 5% para 100%. No entanto, com a versão do NGINX Ingress Controller baseada no NGINX Plus, você pode usar o armazenamento de chave-valor para alterar as porcentagens sem precisar recarregar a configuração.
• Circuit breaking com o NGINX Ingress Controller – Circuit breakers sofisticados economizam tempo e aumentam a resiliência ao detectar falhas e realizar o failover mais rapidamente, além de ativar páginas de erro personalizadas e formatadas para upstreams que não estejam íntegros. Por exemplo, um circuit breaker para um serviço de pesquisa pode ser configurado para retornar um conjunto de resultados de pesquisa vazio, mas formatado corretamente. Para alcançar esse nível de sofisticação, a versão do NGINX Ingress Controller baseada no NGINX Plus usa verificações ativas de integridade que monitoram proativamente a integridade dos seus servidores upstream TCP e UDP. Como o monitoramento ocorre em tempo real, é menos provável que seus clientes se deparem com aplicativos que retornam erros.
• Interrupção de circuito com o NGINX Service Mesh – O NGINX Service Mesh especificação do circuit breaker tem três campos personalizados: embora errors e timeoutSeconds sejam recursos padrão de circuit breakers, fallback aumenta ainda mais a resiliência, permitindo que você defina um servidor de backup. Se as respostas do servidor de backup forem exclusivas, elas poderão ser um indicador precoce de problemas no cluster, permitindo que você comece a solucioná-los imediatamente.
  • errors – O número de erros antes que o circuito seja interrompido
  • timeoutSeconds – O intervalo em que os erros podem ocorrer antes de o circuito ser aberto, bem como o tempo de espera antes de fechar o circuito
  • fallback – O nome e a porta do serviço do Kubernetes para o qual o tráfego é redirecionado após o circuito ser desarmado

Interprete os resultados da divisão de tráfego com painéis

Você implementou a divisão de tráfego… e agora? É hora de analisar o resultado. Essa pode ser a parte mais difícil, pois muitas organizações não têm informações essenciais sobre o desempenho do tráfego e dos aplicativos no Kubernetes. O NGINX facilita a obtenção dessas informações com o painel do NGINX Plus e painéis pré-configurados do Grafana que exibem as métricas disponibilizadas pelo Prometheus Exporter. Para saber mais sobre como melhorar a visibilidade e obter informações relevantes, leia Como melhorar a visibilidade no Kubernetes em nosso blog.

Domine os microsserviços com o NGINX

O NGINX Ingress Controller baseado no NGINX Plus está disponível para uma avaliação gratuita de 30 dias que inclui o NGINX App Protect para proteger seus aplicativos em contêineres.

Para experimentar o NGINX Ingress Controller com o NGINX Open Source, você pode obter o código-fonte da versão ou baixar um contêiner pré-compilado do DockerHub.

O NGINX Service Mesh, que é sempre gratuito, está disponível para download em f5.com.

Sobre o autor

Jenn GileDiretor de Marketing de Produto, NGINX

Mais publicações de Jenn Gile