Você é um desenvolvedor de aplicativos modernos. Você usa um conjunto de ferramentas de código aberto e, talvez, algumas ferramentas comerciais para criar, testar, implantar e gerenciar novos aplicativos e contêineres. Você escolheu o Kubernetes para executar esses contêineres e pods em ambientes de desenvolvimento, teste, homologação e produção. Você adotou as arquiteturas e os conceitos de microsserviços, da Cloud Native Computing Foundation e de outros padrões modernos do setor.
Nessa jornada, você descobriu que o Kubernetes é realmente poderoso. Mas provavelmente também se surpreendeu com o quanto ele pode ser difícil, inflexível e frustrante. Implementar e coordenar alterações e atualizações em roteadores, firewalls, balanceadores de carga e outros dispositivos de rede pode se tornar uma tarefa exaustiva — especialmente no seu próprio data center! É o bastante para levar qualquer desenvolvedor às lágrimas.
A maneira como você lida com esses desafios depende muito de onde e como executa o Kubernetes (como um serviço gerenciado ou no local). Este artigo aborda o balanceamento de carga TCP, uma área fundamental em que as escolhas de implantação afetam a facilidade de uso.
Balanceamento de carga TCP com Kubernetes gerenciado (também conhecido como a opção mais fácil)
Se você usa um serviço gerenciado, como o de um provedor de nuvem pública para Kubernetes, grande parte dessa tediosa configuração de rede é feita para você. Com apenas um comando (kubectl apply -f loadbalancer.yaml), o Service do tipo LoadBalancer fornece um IP público, um registro DNS e um balanceador de carga TCP. Por exemplo, você pode configurar o Amazon Elastic Load Balancer para distribuir o tráfego entre pods que contêm o NGINX Ingress Controller e, usando esse comando, não precisar se preocupar quando os backends mudarem. É tão fácil que apostamos que você nem dá o devido valor!
Balanceamento de carga TCP com Kubernetes local (também conhecido como a opção difícil)
Com clusters locais, o cenário é completamente diferente. Você ou seus colegas da equipe de redes precisam fornecer os componentes de rede. Talvez você se pergunte: “Por que é tão difícil fazer com que os usuários acessem meus aplicativos no Kubernetes?” A resposta é simples, mas um pouco chocante: o Service do tipo LoadBalancer, a porta de entrada do seu cluster, na verdade não existe.
Para expor seus aplicativos e Serviços fora do cluster, sua equipe de rede provavelmente exige chamados, aprovações, procedimentos e talvez até análises de segurança — tudo isso antes de reconfigurar os equipamentos. Ou talvez você precise fazer tudo por conta própria, reduzindo drasticamente o ritmo de entrega dos aplicativos. Pior ainda, você não ousa fazer alterações em nenhum Serviço do Kubernetes, pois, se a NodePort mudar, o tráfego poderá ser bloqueado! E todos sabemos o quanto os usuários gostam de receber erros 500. Seu chefe provavelmente gosta menos ainda.
Uma solução melhor para balanceamento de carga TCP local: NGINX Loadbalancer para Kubernetes
Você pode transformar a “opção difícil” na “opção fácil” com nosso novo projeto: NGINX Loadbalancer for Kubernetes. Este projeto gratuito é um controlador do Kubernetes que monitora o NGINX Ingress Controller e atualiza automaticamente uma instância externa do NGINX Plus configurada para balanceamento de carga. Como seu design é bastante simples, ele é fácil de instalar e operar. Com essa solução implementada, você pode realizar o balanceamento de carga TCP em ambientes locais, garantindo que novos aplicativos e serviços sejam detectados imediatamente e estejam disponíveis para receber tráfego, sem necessidade de intervenção manual.
Arquitetura e fluxo
O NGINX Loadbalancer for Kubernetes fica dentro de um cluster do Kubernetes. Ele é registrado no Kubernetes para monitorar o serviço nginx-ingress (NGINX Ingress Controller). Quando há uma alteração nos backends, o NGINX Loadbalancer for Kubernetes coleta os IPs dos Workers e os números das portas TCP do NodePort e, em seguida, envia os IPs e as portas ao NGINX Plus por meio da API do NGINX Plus. Os servidores upstream do NGINX são atualizados sem necessidade de recarregamento, e o NGINX Plus balanceia o tráfego entre os servidores upstream e os NodePorts do Kubernetes corretos. Outras instâncias do NGINX Plus podem ser adicionadas para garantir alta disponibilidade.
Uma visão geral do NGINX Loadbalancer para Kubernetes em ação
Na captura de tela abaixo, há duas janelas que mostram o NGINX Loadbalancer for Kubernetes implantado e em funcionamento:
- Tipo de serviço – LoadBalancer (para
nginx-ingress) - IP externo – Conecta-se aos servidores NGINX Plus
- Portas – O NodePort é mapeado para 443:30158 com servidores upstream do NGINX correspondentes (conforme mostrado no painel em tempo real)
- Logs – Indica que o NGINX Loadbalancer for Kubernetes está enviando dados com sucesso para o NGINX Plus
Observação: neste exemplo, os nós de trabalho do Kubernetes são 10.1.1.8 e 10.1.1.10
Comece hoje mesmo
Se você está frustrado com os desafios de rede na borda do seu cluster Kubernetes, experimente o projeto e conte-nos o que achou. O código-fonte do NGINX Loadbalancer for Kubernetes é aberto (sob a licença Apache 2.0), e todas as instruções de instalação estão disponíveis no GitHub.
Para enviar seu feedback, deixe um comentário no repositório ou mande uma mensagem para nós no Slack da Comunidade NGINX.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.