Editor – Este post faz parte de uma série de 10 partes:
Você também pode baixar o conjunto completo de blogs como um e-book gratuito – Levando o Kubernetes do teste à produção .
Há uma maneira muito fácil de saber se uma empresa não está usando com sucesso tecnologias modernas de desenvolvimento de aplicativos: seus clientes são rápidos em reclamar nas redes sociais. Eles reclamam quando não conseguem assistir ao último lançamento que vale a pena assistir. Ou acesse o banco on-line. Ou faça uma compra, porque o tempo do carrinho está acabando.
Mesmo que os clientes não reclamem publicamente, isso não significa que sua experiência ruim não tenha consequências. Um dos nossos clientes – uma grande seguradora – nos disse que eles perdem clientes quando sua página inicial não carrega em 3 segundos .
Todas essas reclamações de usuários sobre baixo desempenho ou interrupções apontam para um culpado comum: resiliência... ou a falta dela. A beleza das tecnologias de microsserviços – incluindo contêineres e Kubernetes – é que elas podem melhorar significativamente a experiência do cliente, melhorando a resiliência de seus aplicativos. Como? É tudo sobre a arquitetura.
Gosto de explicar a principal diferença entre arquiteturas monolíticas e de microsserviços usando a analogia de uma fileira de luzes de Natal. Quando uma lâmpada queima em um fio antigo, todo o fio fica escuro. Se você não puder substituir a lâmpada, a única coisa que vale a pena decorar com esse fio é o interior da sua lata de lixo. Esse estilo antigo de luzes é como um aplicativo monolítico, que também tem componentes fortemente acoplados e falha se um componente quebra.
Mas a indústria de iluminação, assim como a indústria de software, detectou esse ponto problemático. Quando uma lâmpada quebra em um moderno conjunto de luzes, as outras continuam brilhando intensamente, assim como um aplicativo de microsserviços bem projetado continua funcionando mesmo quando uma instância de serviço falha.
Os contêineres são uma escolha popular em arquiteturas de microsserviços porque são ideais para construir um aplicativo usando componentes menores e discretos – eles são leves, portáteis e fáceis de escalar. O Kubernetes é o padrão de fato para orquestração de contêineres, mas há muitos desafios em tornar o Kubernetes pronto para produção . Um elemento que melhora tanto seu controle sobre aplicativos Kubernetes quanto sua resiliência é uma estratégia de gerenciamento de tráfego madura que permite que você controle serviços em vez de pacotes e adapte regras de gerenciamento de tráfego dinamicamente ou com a API do Kubernetes. Embora o gerenciamento de tráfego seja importante em qualquer arquitetura, para aplicativos de alto desempenho, duas ferramentas de gerenciamento de tráfego são essenciais: controle de tráfego e divisão de tráfego .
Controle de tráfego (às vezes chamado de roteamento de tráfego ou modelagem de tráfego ) refere-se ao ato de controlar para onde o tráfego vai e como ele chega lá. É uma necessidade ao executar o Kubernetes em produção porque permite proteger sua infraestrutura e aplicativos contra ataques e picos de tráfego. Duas técnicas para incorporar ao ciclo de desenvolvimento do seu aplicativo são limitação de taxa e interrupção de circuito .
Caso de uso: Quero proteger os serviços de receberem muitas solicitações
Solução: Limitação de taxa
Seja malicioso (por exemplo, tentativa de adivinhação de senhas por força bruta e ataques DDoS) ou benigno (como clientes indo em massa para uma liquidação), um alto volume de solicitações HTTP pode sobrecarregar seus serviços e fazer com que seus aplicativos travem. A limitação de taxa restringe o número de solicitações que um usuário pode fazer em um determinado período de tempo. As solicitações podem incluir algo tão simples como uma solicitação GET
para a página inicial de um site ou uma solicitação POST
em um formulário de login. Quando estiver sob ataque DDoS, por exemplo, você pode usar a limitação de taxa para limitar a taxa de solicitações de entrada a um valor típico para usuários reais.
Caso de uso: Quero evitar falhas em cascata
Solução: Quebra de circuito
Quando um serviço está indisponível ou com alta latência, pode levar muito tempo para que as solicitações recebidas expirem e os clientes recebam uma resposta de erro. Os longos tempos limite podem potencialmente causar uma falha em cascata, na qual a interrupção de um serviço leva a tempos limite em outros serviços e à falha final do aplicativo como um todo.
Os disjuntores evitam falhas em cascata monitorando falhas de serviço. Quando o número de solicitações com falha para um serviço excede um limite predefinido, o disjuntor desarma e começa a retornar uma resposta de erro aos clientes assim que as solicitações chegam, efetivamente limitando o tráfego do serviço.
O disjuntor continua interceptando e rejeitando solicitações por um período de tempo definido antes de permitir que um número limitado de solicitações passe como teste. Se essas solicitações forem bem-sucedidas, o disjuntor para de limitar o tráfego. Caso contrário, o relógio é reiniciado e o disjuntor rejeita novamente as solicitações para o tempo definido.
A divisão de tráfego (às vezes chamada de teste de tráfego ) é uma subcategoria do controle de tráfego e se refere ao ato de controlar a proporção do tráfego de entrada direcionado para diferentes versões de um aplicativo de back-end em execução simultaneamente em um ambiente (geralmente a versão de produção atual e uma versão atualizada). É uma parte essencial do ciclo de desenvolvimento de aplicativos porque permite que as equipes testem a funcionalidade e a estabilidade de novos recursos e versões sem impactar negativamente os clientes. Cenários de implantação úteis incluem roteamento de depuração , implantações canário , testes A/B e implantações azul-verde . (Há uma boa dose de inconsistência no uso desses quatro termos no setor. Aqui nós os usamos conforme entendemos suas definições.)
Caso de uso: Estou pronto para testar uma nova versão em produção
Solução: Roteamento de depuração
Digamos que você tenha um aplicativo bancário e queira adicionar um recurso de pontuação de crédito. Antes de testar com clientes, você provavelmente vai querer ver como ele se sai na produção. O roteamento de depuração permite que você o implante publicamente, mas o “esconda” de 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 acesso apenas a usuários que tenham um cookie de sessão de administrador – suas solicitações são roteadas para a nova versão com o recurso de pontuação de crédito, enquanto todos os outros continuam na versão estável.
Caso de uso: Preciso ter certeza de que minha nova versão é estável
Solução: Implantação Canary
O conceito de implantação de canários é retirado de uma prática histórica de mineração, onde os mineiros levavam um canário enjaulado para uma mina de carvão para servir como um alerta precoce de gases tóxicos. O gás matou o canário antes de matar os mineiros, permitindo que eles escapassem rapidamente do perigo. No mundo dos aplicativos, nenhum pássaro é ferido! As implantações canárias fornecem uma maneira segura e ágil de testar a estabilidade de um novo recurso ou versão. Uma implantação canário típica começa com uma alta parcela (digamos, 99%) de seus usuários na versão estável e move um pequeno grupo (o outro 1%) para a nova versão. Se a nova versão falhar, por exemplo, travando ou retornando erros aos clientes, você pode mover imediatamente o grupo de teste de volta para a versão estável. Se tiver sucesso, você pode alternar os usuários da versão estável para a nova, de uma só vez ou (como é mais comum) em uma migração gradual e controlada.
Caso de uso: Preciso descobrir se os clientes gostam mais de uma nova versão do que da versão atual
Solução: Teste A/B
Agora que você confirmou que seu novo recurso funciona em produção, talvez queira obter feedback do cliente sobre o sucesso do recurso, com base em indicadores-chave de desempenho (KPIs), como número de cliques, usuários recorrentes ou classificações explícitas. O teste A/B é um processo usado em muitos setores para medir e comparar o comportamento do usuário com o objetivo de determinar o sucesso relativo de diferentes versões de produtos ou aplicativos na 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 50% restantes recebem a Versão B (a versão com o recurso novo, mas estável). O vencedor é aquele com o melhor conjunto geral de KPIs.
Caso de uso: Quero mover meus usuários para uma nova versão sem tempo de inatividade
Solução: Implantação azul-verde
Agora, 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 remover a versão antiga antes de colocar a nova versão em produção. Mas no ambiente competitivo de hoje, o tempo de inatividade para atualizações é inaceitável para a maioria dos usuários. As implantações azul-verde reduzem muito, ou até mesmo eliminam, o tempo de inatividade para atualizações. Basta manter a versão antiga (azul) em produção enquanto simultaneamente implanta a nova versão (verde) no mesmo ambiente de produção.
A maioria das organizações não quer mover 100% dos usuários do azul para o verde de uma só vez – afinal, e se a versão verde falhar?! A solução é usar uma implantação canário para mover usuários em incrementos que melhor atendam à sua estratégia de mitigação de riscos. Se a nova versão for um desastre, você pode facilmente reverter todos para a versão estável em apenas alguns toques de tecla.
Você pode realizar controle avançado de tráfego e divisão com a maioria dos controladores Ingress e malhas de serviço . A tecnologia a ser usada depende da arquitetura do seu aplicativo e dos casos de uso. Por exemplo, usar um controlador Ingress faz sentido nestes três cenários:
Se sua implantação for complexa o suficiente para precisar de uma malha de serviços, um caso de uso comum é dividir o tráfego entre serviços para teste ou atualização de microsserviços individuais. Por exemplo, você pode querer fazer uma implantação canário por trás do seu front-end móvel, entre duas versões diferentes da sua API de 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:
Com o NGINX Ingress Controller e o NGINX Service Mesh , você pode facilmente configurar políticas robustas de roteamento e divisão de tráfego em segundos. Confira esta demonstração de transmissão ao vivo com nossos especialistas e continue lendo para saber como economizamos seu tempo com configurações mais fáceis, personalizações avançadas e visibilidade aprimorada.
Esses recursos do NGINX facilitam a configuração:
Recursos do NGINX Ingress para o NGINX Ingress Controller – Embora o recurso padrão do Kubernetes Ingress facilite a configuração de terminação SSL/TLS, balanceamento de carga HTTP e roteamento de camada 7, ele não inclui o tipo de recursos de personalização necessários para interrupção de circuito, testes A/B e implantação azul-verde. Em vez disso, usuários não-NGINX precisam usar anotações, ConfigMaps e modelos personalizados, que não oferecem controle preciso, são inseguros, propensos a erros e difíceis de usar.
O NGINX Ingress Controller vem com recursos NGINX Ingress como uma alternativa ao recurso Ingress padrão (que também é compatível). Eles fornecem um estilo de configuração nativo, seguro e recuado que simplifica a implementação do balanceamento de carga do Ingress. Os recursos do NGINX Ingress têm um benefício adicional para usuários existentes do NGINX: eles facilitam a reutilização de configurações de balanceamento de carga de ambientes não Kubernetes, para que todos os seus balanceadores de carga NGINX possam usar 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 service meshes no Kubernetes, com recursos tipados como TrafficSplit
, TrafficTarget
e HTTPRouteGroup
. Usando métodos de configuração padrão do Kubernetes, o NGINX Service Mesh e as extensões NGINX SMI tornam as políticas de divisão de tráfego, como a implantação canário, simples de implantar com interrupção mínima no tráfego de produção. Por exemplo, veja como definir uma implantação canário com o NGINX Service Mesh:
apiVersão: split.smi-spec.io/v1alpha2kind: TrafficSplit
metadados:
nome: target-ts
especificação:
serviço: target-svc
backends:
- serviço: target-v1-0
peso: 90
- serviço: target-v2-0
peso: 10
Nosso tutorial, Implantações usando divisão de tráfego , aborda padrões de implantação de exemplo que aproveitam a divisão de tráfego, incluindo implantações canário e azul-verde.
Esses 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 executar testes A/B ou implantações azul-verde, você pode querer fazer a transição do 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 muito manual porque você precisa editar a porcentagem e recarregar o arquivo de configuração para cada incremento. Com essa quantidade de despesas gerais, você pode decidir correr o risco de ir direto de 5% para 100%. No entanto, com a versão do NGINX Ingress Controller baseada no NGINX Plus , você pode aproveitar o armazenamento de chave-valor para alterar as porcentagens sem a necessidade de uma recarga .
Interrupção de circuito com o NGINX Ingress Controller – Disjuntores sofisticados economizam tempo e melhoram a resiliência ao detectar falhas e failovers mais rapidamente, e até mesmo ativar páginas de erro personalizadas e formatadas para upstreams que não estão íntegros. Por exemplo, um disjuntor para um serviço de pesquisa pode ser configurado para retornar um conjunto de resultados de pesquisa corretamente formatados, mas vazios. Para obter esse nível de sofisticação, a versão do NGINX Ingress Controller baseada no NGINX Plus usa verificações de integridade ativas que monitoram proativamente a integridade dos seus servidores upstream TCP e UDP. Como o monitoramento é em tempo real, seus clientes terão menos probabilidade de encontrar aplicativos que retornam erros.
Quebra de circuito com NGINX Service Mesh – A especificação do disjuntor NGINX Service Mesh tem três campos personalizados:
erros
– O número de erros antes do circuito disparartimeoutSeconds
– A janela para que erros ocorram antes de disparar o circuito, bem como a quantidade de tempo de espera antes de fechar o circuitofallback
– O nome e a porta do serviço Kubernetes para o qual o tráfego é redirecionado após o circuito ter sido acionadoEmbora erros
e timeoutSeconds
sejam recursos padrão de disjuntor, o fallback
aumenta ainda mais a resiliência ao permitir que você defina um servidor de backup. Se as respostas do seu servidor de backup forem únicas, elas podem ser um indicador precoce de problemas no seu cluster, permitindo que você comece a solucionar problemas imediatamente.
Você implementou sua divisão de tráfego... e agora? É hora de analisar o resultado. Essa pode ser a parte mais difícil porque muitas organizações não têm informações importantes sobre o desempenho do tráfego e dos aplicativos do Kubernetes. O NGINX facilita a obtenção de insights com o painel NGINX Plus e os painéis Grafana pré-criados que visualizam as métricas expostas pelo Prometheus Exporter. Para saber mais sobre como melhorar a visibilidade para obter insights, leia Como melhorar a visibilidade no Kubernetes em nosso blog.
O NGINX Ingress Controller baseado no NGINX Plus está disponível para um teste gratuito de 30 dias que inclui o NGINX App Protect para proteger seus aplicativos em contêineres.
Para testar 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é-criado do DockerHub .
O sempre gratuito NGINX Service Mesh está disponível para download em f5.com .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."