BLOG | NGINX

Implantando o BIG-IP e o NGINX Ingress Controller na mesma arquitetura

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Micheál Kingston Miniatura
Michael Kingston
Publicado em 15 de novembro de 2021

Em nossa série de blogs anterior, Implantando serviços de aplicativos no Kubernetes , discutimos um padrão que vemos em muitos clientes durante suas jornadas de transformação digital. A maioria das jornadas começa com o modelo tradicional de criação e implantação de aplicativos (geralmente monólitos), dividindo a responsabilidade por essas duas funções entre equipes isoladas de Desenvolvimento e Operações. À medida que as organizações migram para um modelo mais moderno, elas criam aplicativos baseados em microsserviços e os implantam usando práticas de DevOps que confundem a divisão entre silos tradicionais.

Embora as equipes de DevOps e os proprietários de aplicativos estejam assumindo um controle mais direto sobre como seus aplicativos são implantados, gerenciados e entregues, muitas vezes não é prático quebrar as paredes do silo de uma só vez - nem achamos que seja necessário. Em vez disso, observamos que uma divisão lógica de responsabilidades ainda se aplica:

  • As equipes de rede e segurança continuam focadas na segurança geral, no desempenho e na disponibilidade da infraestrutura corporativa. Eles se preocupam mais com serviços globais, que geralmente são implantados na “porta da frente” dessa infraestrutura.

    Essas equipes contam com o F5 BIG-IP para casos de uso como balanceamento global de carga de servidor (GSLB), resolução e balanceamento de carga de DNS e modelagem de tráfego sofisticada. O BIG‑IQ e o NGINX Controller [agora F5 NGINX Management Suite ] fornecem métricas e alertas em um formato que melhor se adapta às equipes de NetOps e, para as equipes de SecOps, eles fornecem a visibilidade e o controle sobre a segurança que o SecOps precisa ter para proteger os ativos da organização e cumprir com as regulamentações do setor.

  • As equipes de operações (DevOps com ênfase em Operações) criam e gerenciam aplicativos individuais conforme exigido por suas linhas de negócios associadas. Eles se preocupam mais com serviços como automação e pipelines de CI/CD que os ajudam a iterar mais rapidamente em recursos atualizados; esses serviços geralmente são implantados "mais perto" do aplicativo, por exemplo, dentro de um ambiente Kubernetes.

    Essas equipes contam com produtos NGINX como NGINX Plus , NGINX App Protect , NGINX Ingress Controller e NGINX Service Mesh para balanceamento de carga e modelagem de tráfego de aplicativos distribuídos baseados em microsserviços hospedados em vários ambientes, incluindo clusters Kubernetes. Os casos de uso incluem terminação TLS, roteamento baseado em host, reescrita de URI, autenticação JWT, persistência de sessão, limitação de taxa, verificação de integridade, segurança (com NGINX App Protect como um WAF integrado) e muito mais.

NetOps e DevOps em ambientes Kubernetes

As diferentes preocupações das equipes de NetOps e DevOps são refletidas nas funções que desempenham em ambientes Kubernetes e nas ferramentas que usam para realizá-las. Correndo o risco de simplificar demais, podemos dizer que as equipes de NetOps estão preocupadas principalmente com a infraestrutura e a funcionalidade de rede fora do cluster do Kubernetes, e as equipes de DevOps com essa funcionalidade dentro do cluster.

Para direcionar o tráfego para clusters do Kubernetes, as equipes do NetOps podem usar o BIG-IP como um balanceador de carga externo que oferece suporte aos recursos e à variedade de tecnologias de rede de sobreposição com as quais elas já estão familiarizadas. No entanto, por si só, o BIG-IP não tem como rastrear alterações no conjunto de pods dentro do cluster do Kubernetes (por exemplo, alterações no número de pods ou em seus endereços IP). Para contornar essa restrição, o F5 Container Ingress Services (CIS) é implantado como um operador dentro do cluster. O CIS monitora alterações no conjunto de pods e modifica automaticamente os endereços no pool de balanceamento de carga do sistema BIG-IP de acordo. Ele também procura a criação de novos recursos de entrada, rota e personalizados e atualiza a configuração do BIG-IP adequadamente.

Embora você possa usar a combinação de BIG-IP com CIS para balancear a carga do tráfego para pods de aplicativos diretamente , na prática o NGINX Ingress Controller é a solução ideal para descobrir e acompanhar as mudanças dinâmicas de aplicativos em pods e cargas de trabalho que representam um grande número de serviços — por exemplo, durante o dimensionamento horizontal dos seus pods de aplicativos para atender aos níveis de demanda em constante mudança.

Outra vantagem de implantar o NGINX Ingress Controller é que ele transfere o controle do balanceamento de carga do aplicativo para as equipes de DevOps que são responsáveis pelos próprios aplicativos. Seu plano de controle de alto desempenho e design centrado em DevOps o tornam particularmente forte no suporte a casos de uso de DevOps em rápida mudança – como reconfigurações no local e atualizações contínuas – em serviços Kubernetes em vários namespaces. O NGINX Ingress Controller usa a API nativa do Kubernetes para descobrir pods à medida que são dimensionados.

Como o BIG-IP e o NGINX Ingress Controller funcionam juntos

Como você deve saber, o BIG-IP e o NGINX Ingress Controller foram originalmente projetados por duas empresas distintas (F5 e NGINX, respectivamente). Desde que a F5 adquiriu o NGINX, os clientes nos disseram que melhorar a interoperabilidade entre as duas ferramentas simplificaria o gerenciamento de sua infraestrutura. Em resposta, desenvolvemos um novo recurso do Kubernetes que chamamos de IngressLink.

O recurso IngressLink é um aprimoramento simples que usa um Kubernetes CustomResourceDefinition (CRD) para “vincular” o NGINX Ingress Controller e o BIG-IP. Simplificando, ele permite que o CIS “informe” ao BIG-IP sempre que o conjunto de pods do NGINX Ingress Controller for alterado. Com essas informações, o BIG-IP pode mudar agilmente suas políticas de balanceamento de carga correspondentes para corresponder.

Com o BIG-IP implantado para balanceamento de carga nos clusters do Kubernetes e o NGINX Ingress Controller manipulando o tráfego de entrada e saída, o fluxo de tráfego se parece com isto:

  1. O BIG-IP direciona o tráfego externo para as instâncias do NGINX Ingress Controller.
  2. O NGINX Ingress Controller distribui o tráfego para os serviços apropriados dentro do cluster.
  3. Como o NGINX Ingress Controller é excepcionalmente eficiente, um conjunto estável de instâncias pode lidar com alterações frequentes e grandes no conjunto de pods de aplicativos. Mas quando seu NGINX Ingress Controller precisa ser dimensionado horizontalmente para dentro ou para fora (para lidar com picos e quedas de tráfego), o CIS informa o BIG-IP sobre as alterações (por meio do recurso IngressLink), permitindo que o BIG-IP se adapte rapidamente às alterações.

Diagrama de topologia do F5 BIG-IP e do F5 NGINX Ingress Controller implantados no mesmo ambiente Kubernetes com o F5 Container Ingress Services

Primeiros passos

Para mais detalhes sobre como o recurso IngressLink funciona, incluindo um guia de implantação, visite o F5 CloudDocs .

Comece solicitando sua avaliação gratuita de 30 dias do NGINX Ingress Controller com NGINX App Protect WAF e DoS. Se você ainda não é um usuário do BIG-IP, selecione a versão de avaliação no F5.com que funciona melhor para sua equipe.


"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."