Configurando o NGINX Plus como um balanceador de carga externo para Red Hat OCP e Kubernetes

No mundo da orquestração de contêineres, há dois nomes que encontramos o tempo todo: Plataforma de contêiner RedHat OpenShift (OCP) e Kubernetes. O OpenShift, como você provavelmente sabe, usa o Kubernetes por baixo, assim como muitas outras plataformas de orquestração de contêineres. Rotear tráfego externo para um ambiente Kubernetes ou OpenShift sempre foi um pouco desafiador, de duas maneiras:

• Expondo serviços implantados dentro do Kubernetes para o mundo externo. A solução é um controlador Ingress como o NGINX Plus Ingress Controller . Você pode ler mais sobre isso em nosso blog Introdução ao NGINX Ingress Operator no Red Hat OpenShift .
• Balanceamento de carga de tráfego entre seus nós do Kubernetes. Para resolver esse problema, as organizações geralmente escolhem um hardware externo, um balanceador de carga virtual ou 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 seu investimento em tecnologia.

Neste blog, foco em como resolver o segundo problema usando o NGINX Plus de uma forma simples, eficiente e que permita que suas equipes de desenvolvimento de aplicativos gerenciem tanto a configuração do Ingress dentro do Kubernetes quanto a configuração do balanceador de carga externo. Como uma 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 controlador NGINX criado usando o Red Hat Operator Framework e o SDK. O NGINX-LB-Operator aciona 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 mudam ou as implantações são dimensionadas dentro do cluster do Kubernetes.

Observe que o NGINX-LB-Operator não é coberto pelo seu contrato de suporte NGINX Plus ou NGINX Controller. Você pode relatar bugs ou solicitar assistência para solução de problemas no GitHub .

Kubernetes e NGINX Technologies – Uma revisão

O NGINX-LB-Operator depende de diversas tecnologias do Kubernetes e do NGINX, então estou fornecendo uma rápida análise para que todos nós estejamos na mesma página. Se você já estiver familiarizado com eles, sinta-se à vontade para pular para O Operador do Balanceador de Carga NGINX .

Controladores e operadores do Kubernetes

Kubernetes é uma plataforma de orquestração construída em torno de uma API central fracamente acoplada. A API fornece uma coleção de definições de recursos, juntamente com Controladores (que normalmente são executados como Pods dentro da plataforma) para monitorar e gerenciar esses recursos. A API do Kubernetes é extensível, e os Operadores (um tipo de Controlador) podem ser usados para estender a funcionalidade do Kubernetes.

• Controladores – Uma parte essencial do sistema Kubernetes. Eles criam “relógios” para recursos específicos do Kubernetes e executam as etapas necessárias para atingir o estado desejado de cada recurso conforme ele muda. Em conversas com clientes, o controlador Kubernetes mais comumente discutido é o “Ingress Controller”.
• Operadores – Controladores personalizados que definem e fazem uso de definições de recursos personalizados (CRDs) para gerenciar aplicativos e seus componentes.

Controladores de entrada NGINX para Kubernetes

Há duas opções principais de controlador Ingress para NGINX, e pode ser um pouco confuso diferenciá-las porque os nomes no GitHub são muito semelhantes. Discutimos esse tópico em detalhes em um blog anterior , mas aqui vai uma rápida revisão:

• kubernetes/ingress-nginx – O controlador Ingress suportado e mantido pela comunidade de código aberto do Kubernetes. Para facilitar o uso, chamamos isso de “controlador Ingress da comunidade”. Não é de surpreender que ele seja baseado no NGINX Open Source. Ele fornece recursos adicionais que são habilitados por módulos Lua de terceiros, o que infelizmente tende a prejudicar o desempenho.

• nginxinc/kubernetes-ingress – O controlador Ingress mantido pela equipe NGINX na F5. Há duas versões: uma para o NGINX Open Source (criado para velocidade) e outra para o NGINX Plus (também criado para velocidade, mas com suporte comercial e recursos adicionais de nível empresarial). Nós os chamamos de “controladores NGINX (ou nossos) Ingress”.

  Você pode gerenciar ambos os controladores do Ingress usando recursos padrão do Kubernetes Ingress. Também oferecemos suporte a Anotações e ConfigMaps para estender a funcionalidade limitada fornecida pela especificação Ingress, mas estender recursos dessa maneira não é o ideal.

  A versão 1.6.0 e posteriores dos nossos controladores Ingress incluem uma solução melhor: recursos personalizados do NGINX Ingress 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 que você use recursos avançados de balanceamento de carga com o Ingress, implemente versões azul-verde e canário e padrões de disjuntor e muito mais.

Para um resumo das principais diferenças entre essas três opções de controlador Ingress, consulte nosso repositório GitHub .

NGINX Controller

O NGINX Controller é nosso plano de controle independente de nuvem para gerenciar suas instâncias do NGINX Plus em vários ambientes e aproveitar insights críticos sobre desempenho e estados de erro. Seus módulos fornecem gerenciamento de configuração centralizado para entrega de aplicativos (balanceamento de carga) e gerenciamento de API . O NGINX Controller pode gerenciar a configuração de instâncias do NGINX Plus em uma infinidade de ambientes: físico, virtual e na nuvem. Ele é construído em torno de uma API declarativa e consistente e fornece uma visão centrada em aplicativos dos seus aplicativos e seus componentes. Ele foi projetado para interagir facilmente com seus pipelines de CI/CD, abstrair a infraestrutura do código e permitir que os desenvolvedores continuem com seus trabalhos.

Quando se trata do Kubernetes, o NGINX Controller pode gerenciar instâncias do NGINX Plus implantadas frontalmente como um proxy reverso ou gateway de API. No entanto, não faz sentido que o NGINX Controller gerencie o NGINX Plus Ingress Controller em si; como o Ingress Controller executa a função de loop de controle para um recurso principal do Kubernetes (o Ingress), ele precisa ser gerenciado usando ferramentas da plataforma Kubernetes – recursos Ingress padrão ou recursos Ingress NGINX.

Balanceadores de carga externos

O NGINX Plus Ingress Controller para Kubernetes é uma ótima maneira de expor serviços dentro do Kubernetes para o mundo externo, mas geralmente você precisa de uma camada de balanceamento de carga externa para gerenciar o tráfego em nós ou clusters do Kubernetes. Se você estiver executando em uma nuvem pública, o balanceador de carga externo pode ser o NGINX Plus, o F5 BIG-IP LTM Virtual Edition ou uma solução nativa da nuvem. Se estiver implantando no local ou em uma nuvem privada, você pode 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 😉 .

Quando se trata de gerenciar seus balanceadores de carga externos, você pode gerenciar instâncias externas do NGINX Plus usando o NGINX Controller diretamente. Sua API declarativa foi projetada com o propósito de interagir com seu pipeline de CI/CD, e você pode implantar cada um dos componentes do seu aplicativo usando-a. Mas e se sua camada de entrada for escalável, você usar NodePorts do Kubernetes atribuídos dinamicamente ou suas rotas do OpenShift puderem mudar?

Em casos como esses, você provavelmente desejará mesclar a configuração do balanceador de carga externo com o estado do Kubernetes e conduzir a API do NGINX Controller por meio de um Kubernetes Operator. O diagrama mostra uma implantação de exemplo que inclui exatamente esse 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 entrada (caixa azul) – Um recurso de entrada padrão e um recurso NGINX VirtualServer são definidos no namespace do projeto.
• Setas azuis – Os recursos do Ingress são criados na API do Kubernetes e coletados pelo NGINX Plus Ingress Controller, que está sendo executado em um namespace diferente.
• Recursos personalizados (caixa verde) – Recursos personalizados, que são instanciações de CRDs instalados com NGINX-LB-Operator , são definidos no namespace do seu projeto e consumidos pelo NGINX-LB-Operator em execução no mesmo namespace.
• Setas verdes – Os recursos são criados na API e então coletados 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.

Nessa topologia, os recursos personalizados contêm o estado desejado do balanceador de carga externo e definem o upstream (grupo de carga de trabalho) como o NGINX Plus Ingress Controller. O NGINX-LB-Operator coleta informações sobre os Pods de Ingresso e mescla essas informações com o estado desejado antes de enviá-las para a API do Controlador NGINX.

O operador do balanceador de carga NGINX

Escrever um operador para o Kubernetes pode parecer uma tarefa assustadora no início, mas a Red Hat e a comunidade de código aberto do Kubernetes mantêm o Operator Framework , o que torna a tarefa relativamente fácil. O Operator SDK permite que qualquer pessoa crie um operador do Kubernetes usando Go, Ansible ou Helm. Na F5, já publicamos coleções 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 interagir com o NGINX Controller é bastante simples.

Usei o Operator SDK para criar o NGINX Load Balancer Operator, NGINX-LB-Operator , que pode ser implantado com um Namespace ou Cluster Scope e observa alguns recursos personalizados. Os recursos personalizados são mapeados diretamente nos objetos do NGINX Controller (Certificado, Gateway, Aplicativo e Componente) e, portanto, representam o modelo centrado em aplicativos do NGINX Controller diretamente no Kubernetes. Os recursos personalizados configurados no Kubernetes são selecionados pelo NGINX-LB-Operator , que então cria recursos equivalentes no NGINX Controller.

O NGINX-LB-Operator permite que você gerencie a configuração de uma instância externa do NGINX Plus usando a API declarativa do NGINX Controller. Como o NGINX Controller está gerenciando a instância externa, você obtém os benefícios adicionais de monitoramento e alerta, e os insights profundos do aplicativo que o NGINX Controller fornece.

Este diagrama ilustra como:

1. Você cria recursos personalizados no namespace do projeto que são enviados para a API do Kubernetes.
2. O NGINX-LB-Operator vê os recursos recém-configurados e coleta o estado desejado do componente e as informações de implantação do controlador Ingress no namespace Ingress.
3. Uma configuração mesclada da sua definição e do estado atual do controlador Ingress é enviada ao controlador NGINX.
4. A configuração é entregue às instâncias do NGINX Plus solicitadas 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 são fornecidos no GitHub . Se você não gosta de RPG ou veio aqui pela versão TL;DR, vá lá agora.

Uma implantação de exemplo

Então vamos fazer uma dramatização. Eu serei Susan e você pode ser Dave.

Como Dave, você administra uma linha de negócios em seu conglomerado imaginário favorito. Você está com as crianças e está sempre atento, etc., então você implanta todos os seus aplicativos e microsserviços no OpenShift e para o Ingress você usa o NGINX Plus Ingress Controller para Kubernetes. Todos os seus aplicativos são implantados como projetos OpenShift (namespaces) e o NGINX Plus Ingress Controller é executado em seu próprio namespace Ingress.

Você nunca ficou satisfeito com os recursos disponíveis na especificação padrão do Ingress e sempre achou que ConfigMaps e Annotations eram um pouco desajeitados. É por isso que você ficou nas nuvens quando a NGINX anunciou que o NGINX Plus Ingress Controller começaria a oferecer suporte aos seus próprios CRDs. Hoje, seus desenvolvedores de aplicativos usam os recursos VirtualServer e VirtualServerRoutes para gerenciar a implantação de aplicativos no NGINX Plus Ingress Controller e para 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 do TransportServer também disponíveis com o NGINX Plus Ingress Controller. Os desenvolvedores podem definir os recursos personalizados em seus próprios namespaces de projeto, que são então selecionados pelo NGINX Plus Ingress Controller e aplicados imediatamente. É incrível, mas você gostaria que fosse possível gerenciar o balanceador de carga de rede externo na borda do seu cluster OpenShift com a mesma facilidade. Os momentos em que você precisa escalar a camada Ingress sempre fazem com que sua lumbago piore.

É sábado à noite e você deveria estar na discoteca, mas ontem você teve que escalar a camada Ingress novamente e agora está com dor na parte inferior das costas. Ping! Em uma nuvem de fumaça, sua fada madrinha Susan aparece.

“Olá, Dave”, ela diz.

"Quem é você? "Olha o que você fez com meu tapete persa", você responde.

Ignorando sua atitude, Susan passa a falar sobre o NGINX-LB-Operator, agora disponível no GitHub. Ela explica que com um cluster NGINX Plus na borda do OpenShift e um NGINX Controller para gerenciá-lo de uma perspectiva centrada no aplicativo, você pode criar recursos personalizados que definem como configurar o balanceador de carga NGINX Plus.

O NGINX-LB-Operator monitora esses recursos e os utiliza para enviar a configuração centrada no aplicativo ao NGINX Controller. Por sua vez, o NGINX Controller gera a configuração necessária do NGINX Plus e a envia para o balanceador de carga externo do NGINX Plus.

Seus usuários finais têm acesso imediato aos seus aplicativos, e você obtém 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ê da mesma perspectiva centrada no aplicativo que você já desfruta. E na próxima vez que você dimensionar a camada NGINX Plus Ingress, o NGINX-LB-Operator atualizará automaticamente o NGINX Controller e o balanceador de carga NGINX Plus externo para você. Chega de dores nas costas!

Conclusão

O Kubernetes é uma plataforma criada para gerenciar aplicativos em contêineres. O NGINX Controller fornece um modelo centrado em aplicativos para pensar e gerenciar o balanceamento de carga de aplicativos. O NGINX-LB-Operator combina os dois e permite que você gerencie a pilha completa de ponta a ponta sem precisar se preocupar com nenhuma infraestrutura subjacente. Acesse o GitHub para obter mais informações técnicas sobre o NGINX-LB-Operator e um exemplo completo de explicação passo a passo.

Saiba mais sobre nossas soluções:

• Solicite uma avaliação gratuita do NGINX Controller
• Entre em contato conosco para discutir seus casos de uso
• Obtenha o operador NGINX Ingress para OpenShift
• Inscreva-se para um curso ministrado por um instrutor