No mundo da orquestração de contêineres, há dois nomes com os quais nos deparamos o tempo todo: RedHat OpenShift Container Platform (OCP) e Kubernetes. Como você provavelmente sabe, o OpenShift usa o Kubernetes como base, assim como muitas outras plataformas de orquestração de contêineres. O roteamento de tráfego externo para um ambiente Kubernetes ou OpenShift sempre foi um pouco desafiador, por dois motivos:
- Exposição de serviços implantados no Kubernetes para o mundo externo. A solução é um controlador de Ingress como o Controlador de Ingress NGINX Plus. Saiba mais em nosso blog Introdução ao NGINX Ingress Operator no Red Hat OpenShift.
- Balanceamento de carga do tráfego entre os nós do Kubernetes. Para resolver esse problema, as organizações geralmente optam por um balanceador de carga externo, físico ou virtual, ou por uma solução nativa da nuvem. No entanto, o NGINX Plus também pode ser usado como balanceador de carga externo, melhorando o desempenho e simplificando o investimento em tecnologia.
Neste blog, concentro-me em como resolver o segundo problema usando o NGINX Plus de maneira simples e eficiente, permitindo que suas equipes de desenvolvimento de aplicativos gerenciem tanto a configuração de Ingress dentro do Kubernetes quanto a configuração do balanceador de carga externo. Como arquitetura de referência para ajudar você a começar, criei o projeto nginx-lb-operator no GitHub – o NGINX Load Balancer Operator (NGINX-LB-Operator) é um operador baseado em Ansible para o NGINX Controller, criado usando o Red Hat Operator Framework e o SDK. O NGINX-LB-Operator usa a API declarativa do NGINX Controller para atualizar a configuração do balanceador de carga externo NGINX Plus quando novos serviços são adicionados, os pods são alterados ou as implantações são escalonadas no cluster do Kubernetes.
Observe que o NGINX-LB-Operator não está coberto pelo seu contrato de suporte do NGINX Plus ou do NGINX Controller. Você pode relatar bugs ou solicitar ajuda para solucionar problemas no GitHub.
Kubernetes e tecnologias NGINX – uma análise
O NGINX-LB-Operator utiliza diversas tecnologias do Kubernetes e do NGINX. Por isso, apresento uma breve revisão para garantir que todos estejam alinhados. Se você já conhece essas tecnologias, fique à vontade para pular para O operador de balanceamento de carga do NGINX.
Controladores e operadores do Kubernetes
O Kubernetes é uma plataforma de orquestração desenvolvida em torno de uma API central com baixo acoplamento. A API fornece um conjunto de definições de recursos, além de Controladores (que normalmente são executados como Pods dentro da plataforma) para monitorar e gerenciar esses recursos. A API do Kubernetes é extensível, e Operadores (um tipo de Controlador) podem ser usados para ampliar a funcionalidade do Kubernetes.
- Controladores – Uma parte essencial do sistema Kubernetes. Eles criam “observadores” para recursos específicos do Kubernetes e executam as etapas necessárias para alcançar o estado desejado de cada recurso à medida que ele muda. Em conversas com clientes, o Controlador do Kubernetes mencionado com mais frequência é o “Controlador de Ingress”.
- Operadores – Controladores personalizados que definem e utilizam definições de recursos personalizados (CRDs) para gerenciar aplicações e seus componentes.
Controladores de Ingress NGINX para Kubernetes
Há duas opções principais de controladores Ingress para o NGINX, e pode ser um pouco confuso diferenciá-las porque os nomes no GitHub são muito parecidos. Discutimos esse assunto em detalhes em um blog anterior, mas aqui está uma breve recapitulação:
- kubernetes/ingress-nginx – O controlador Ingress com suporte e manutenção da comunidade de código aberto do Kubernetes. Para facilitar, nós o chamamos de “controlador Ingress da comunidade”. Como era de se esperar, ele é baseado no NGINX Open Source. Ele oferece recursos adicionais habilitados por módulos Lua de terceiros que, infelizmente, tendem a prejudicar o desempenho.
- nginxinc/kubernetes-ingress – O controlador Ingress mantido pela equipe do NGINX na F5. Há duas versões: uma para o NGINX Open Source (desenvolvida para oferecer velocidade) e outra para o NGINX Plus (também desenvolvida para oferecer velocidade, mas com suporte comercial e recursos adicionais de nível empresarial). Nós as chamamos de “controladores Ingress do NGINX (ou nossos)”. Você pode gerenciar ambos os nossos controladores Ingress usando recursos padrão do Kubernetes Ingress. Também oferecemos suporte a Anotações e ConfigMaps para ampliar a funcionalidade limitada fornecida pela especificação do Ingress, mas estender recursos dessa forma não é o ideal.A versão 1.6.0 e as versões posteriores dos nossos controladores Ingress incluem uma solução melhor: recursos do NGINX Ingress personalizados chamados VirtualServer e VirtualServerRoute, que estendem a API do Kubernetes e fornecem recursos adicionais de forma nativa do Kubernetes. Os recursos do NGINX Ingress expõem mais funcionalidades do NGINX e permitem usar recursos avançados de balanceamento de carga com o Ingress, implementar implantações blue-green e canário, padrões de circuit breaker e muito mais.
Para ver um resumo das principais diferenças entre essas três opções de controladores Ingress, consulte nosso repositório no GitHub.
Controlador NGINX
NGINX Controller é nosso plano de controle independente de nuvem para gerenciar suas instâncias do NGINX Plus em vários ambientes e aproveitar insights essenciais sobre desempenho e estados de erro. Seus módulos fornecem gerenciamento centralizado de configurações para entrega de aplicações (balanceamento de carga) e gerenciamento de APIs. O NGINX Controller pode gerenciar a configuração de instâncias do NGINX Plus em diversos ambientes: físicos, virtuais e em nuvem. Ele foi desenvolvido com base em uma API declarativa e de consistência eventual e oferece uma visão das suas aplicações e de seus componentes centrada na aplicação. Foi projetado para se integrar facilmente aos seus pipelines de CI/CD, abstrair a infraestrutura do código e permitir que os desenvolvedores se concentrem em seu trabalho.
Quando se trata do Kubernetes, o NGINX Controller pode gerenciar instâncias do NGINX Plus implantadas na camada de entrada como proxy reverso ou gateway de API. No entanto, não faz sentido que o NGINX Controller gerencie o próprio NGINX Plus Ingress Controller, pois o Ingress Controller executa a função de loop de controle de um recurso central do Kubernetes (o Ingress) e, portanto, precisa ser gerenciado com as ferramentas da plataforma Kubernetes — usando recursos Ingress padrão ou recursos NGINX Ingress.
Balanceadores de carga externos
O NGINX Plus Ingress Controller para Kubernetes é uma ótima maneira de expor serviços do Kubernetes ao mundo externo, mas geralmente é necessária uma camada externa de balanceamento de carga para gerenciar o tráfego direcionado aos nós ou clusters do Kubernetes. Se você estiver usando uma nuvem pública, o balanceador de carga externo poderá ser o NGINX Plus, o F5 BIG-IP LTM Virtual Edition ou uma solução nativa da nuvem. Se estiver fazendo a implantação localmente ou em uma nuvem privada, você poderá usar o NGINX Plus ou um dispositivo BIG-IP LTM (físico ou virtual). Disseram-me que há outros balanceadores de carga disponíveis, mas não acredito nisso 😉 .
Quando se trata de gerenciar seus balanceadores de carga externos, você pode gerenciar instâncias externas do NGINX Plus diretamente com o NGINX Controller. A API declarativa dele foi projetada para se integrar ao seu pipeline de CI/CD, e você pode usá-la para implantar cada um dos componentes da sua aplicação. Mas e se a sua camada de Ingress for escalável, você usar NodePorts do Kubernetes atribuídas dinamicamente ou suas Rotas do OpenShift puderem mudar?
Em casos como esses, provavelmente é recomendável combinar a configuração do balanceador de carga externo com o estado do Kubernetes e controlar a API do NGINX Controller por meio de um operador do Kubernetes. O diagrama mostra um exemplo de implantação que inclui justamente esse tipo de operador (NGINX-LB-Operator) para gerenciar o balanceador de carga externo e destaca as diferenças entre o NGINX Plus Ingress Controller e o NGINX Controller.
onde:
- Recursos de Ingress (caixa azul) – Um recurso padrão de Ingress e um recurso VirtualServer do NGINX são definidos no namespace do projeto.
- Setas azuis – Os recursos de Ingress são criados na API do Kubernetes e detectados pelo NGINX Plus Ingress Controller, que está sendo executado em outro namespace.
- Recursos personalizados (caixa verde) – Os recursos personalizados, que são instâncias de CRDs instaladas com o NGINX-LB-Operator, são definidos no namespace do seu projeto e utilizados pelo NGINX-LB-Operator em execução no mesmo namespace.
- Setas verdes – Os recursos são criados na API e, em seguida, processados pelo NGINX-LB-Operator. Ao contrário do Ingress Controller, que configura uma instância local do NGINX Plus em execução no mesmo Pod, o NGINX-LB-Operator faz uma chamada de API para o NGINX Controller.
- Setas laranja – O NGINX Controller configura a instância externa do NGINX Plus para balancear a carga no NGINX Plus Ingress Controller.
Nesta topologia, os recursos personalizados contêm o estado desejado do balanceador de carga externo e definem o upstream (grupo de cargas de trabalho) como o NGINX Plus Ingress Controller. O NGINX-LB-Operator coleta informações sobre os Pods de Ingress e as combina com o estado desejado antes de enviá-las à API do NGINX Controller.
O operador de balanceamento de carga do NGINX
Criar um Operator para Kubernetes pode parecer uma tarefa desafiadora a princípio, mas a Red Hat e a comunidade de código aberto do Kubernetes mantêm o Operator Framework, que torna essa tarefa relativamente fácil. O Operator SDK permite que qualquer pessoa crie um Operator para Kubernetes usando Go, Ansible ou Helm. Na F5, já publicamos coleções do Ansible para muitos dos nossos produtos, incluindo a coleção certificada para o NGINX Controller, portanto, criar um Operator para gerenciar instâncias externas do NGINX Plus e integrá-las ao NGINX Controller é bastante simples.
Usei o Operator SDK para criar o NGINX Load Balancer Operator, NGINX-LB-Operator, que pode ser implantado com escopo de namespace ou de cluster e monitora alguns recursos personalizados. Os recursos personalizados são mapeados diretamente para objetos do NGINX Controller (Certificate, Gateway, Application e Component) e, assim, representam o modelo centrado em aplicações do NGINX Controller diretamente no Kubernetes. Os recursos personalizados configurados no Kubernetes são detectados pelo NGINX-LB-Operator, que então cria recursos equivalentes no NGINX Controller.
O NGINX-LB-Operator permite gerenciar a configuração de uma instância externa do NGINX Plus usando a API declarativa do NGINX Controller. Como o NGINX Controller gerencia a instância externa, você também conta com os benefícios adicionais de monitoramento e alertas, além dos insights detalhados sobre aplicações fornecidos pelo NGINX Controller.
Este diagrama ilustra como:
- Você cria recursos personalizados no namespace do projeto, que são enviados para a API do Kubernetes.
- O NGINX-LB-Operator detecta os recursos recém-configurados e coleta o estado desejado do componente e as informações de implantação do controlador Ingress no namespace do Ingress.
- Uma configuração mesclada com base na sua definição e no estado atual do controlador de Ingress é enviada ao NGINX Controller.
- A configuração é enviada às instâncias solicitadas do NGINX Plus, e o NGINX Controller começa a coletar métricas para o novo aplicativo.
Instruções detalhadas de implantação e um aplicativo de exemplo estão disponíveis no GitHub. Se você não gosta de encenações ou veio aqui em busca da versão resumida, acesse-o agora.
Um exemplo de implantação
Então, vamos fazer uma encenação. Eu serei a Susan e você pode ser o Dave.
Como Dave, você administra uma linha de negócios no seu conglomerado fictício favorito. Você está por dentro das tendências e antenado com as novidades, então implanta todos os seus aplicativos e microsserviços no OpenShift e, para o Ingress, usa o NGINX Plus Ingress Controller for Kubernetes. Todos os seus aplicativos são implantados como projetos do OpenShift (namespaces), e o NGINX Plus Ingress Controller é executado em seu próprio namespace de Ingress.
Você nunca ficou satisfeito com os recursos disponíveis na especificação padrão do Ingress e sempre achou os ConfigMaps e as Annotations um pouco complicados. Por isso, ficou muito feliz quando a NGINX anunciou que o NGINX Plus Ingress Controller passaria a oferecer suporte às suas próprias CRDs. Hoje, os desenvolvedores de aplicações usam os recursos VirtualServer e VirtualServerRoutes para gerenciar a implantação de aplicações no NGINX Plus Ingress Controller e configurar o roteamento interno e o tratamento de erros no OpenShift.
Às vezes, você até expõe serviços não HTTP, tudo graças aos recursos personalizados TransportServer também disponíveis com o NGINX Plus Ingress Controller. Os desenvolvedores podem definir os recursos personalizados nos namespaces dos próprios projetos, que são então detectados pelo NGINX Plus Ingress Controller e aplicados imediatamente. É incrível, mas você gostaria que fosse possível gerenciar com a mesma facilidade o balanceador de carga de rede externo na borda do seu cluster OpenShift. Sempre que você precisa escalar a camada de Ingress, sua lombalgia volta a atacar.
É sábado à noite e você deveria estar na balada, mas ontem precisou escalar a camada de Ingress novamente e agora está com dor na lombar. Plim! Em meio a uma nuvem de fumaça, surge Susan, sua fada madrinha.
“Olá, Dave”, diz ela.
“Quem é você? Veja o que fez com o meu tapete persa” — você responde.
Ignorando sua atitude, Susan continua falando sobre o NGINX-LB-Operator, agora disponível no GitHub. Ela explica que, com um cluster do NGINX Plus na borda do OpenShift e o NGINX Controller para gerenciá-lo de uma perspectiva centrada em aplicações, você pode criar recursos personalizados que definem como configurar o balanceador de carga do NGINX Plus.
O NGINX-LB-Operator monitora esses recursos e os utiliza para enviar a configuração centrada na aplicação ao NGINX Controller. Por sua vez, o NGINX Controller gera a configuração necessária do NGINX Plus e a envia ao balanceador de carga externo do NGINX Plus.
Seus usuários finais obtêm acesso imediato aos seus aplicativos, e você mantém o controle sobre as alterações que exigem modificações no balanceador de carga externo NGINX Plus!
O NGINX Controller coleta métricas do balanceador de carga externo NGINX Plus e as apresenta a você com a mesma perspectiva centrada em aplicações que você já conhece. E, na próxima vez que você dimensionar a camada de Ingress do NGINX Plus, o NGINX-LB-Operator atualizará automaticamente o NGINX Controller e o balanceador de carga externo NGINX Plus para você. Chega de dor de cabeça!
Conclusão
O Kubernetes é uma plataforma criada para gerenciar aplicações em contêineres. O NGINX Controller oferece um modelo centrado em aplicações para conceber e gerenciar o balanceamento de carga de aplicações. O NGINX-LB-Operator combina os dois e permite gerenciar toda a pilha de ponta a ponta sem precisar se preocupar com a infraestrutura subjacente. Acesse o GitHub para obter mais informações técnicas sobre o NGINX-LB-Operator e conferir um passo a passo completo de exemplo.
Saiba mais sobre nossas soluções:
- Solicite uma avaliação gratuita do NGINX Controller
- Entre em contato conosco para conversar sobre seus casos de uso
- Obtenha o NGINX Ingress Operator para OpenShift
- Inscreva-se em um curso ministrado por um instrutor
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.