Criar e gerenciar um ambiente Kubernetes robusto exige uma colaboração harmoniosa entre as equipes de Rede e de Aplicações. No entanto, suas prioridades e formas de trabalho costumam ser bastante diferentes, o que gera conflitos com consequências potencialmente graves — desenvolvimento lento de aplicações, atrasos na implantação e até mesmo indisponibilidade da rede.
Somente o sucesso de ambas as equipes, trabalhando em prol de um objetivo comum, pode garantir que as aplicações modernas de hoje sejam entregues no prazo, com a segurança e a escalabilidade adequadas. Então, como aproveitar as habilidades e a experiência de cada equipe e, ao mesmo tempo, ajudá-las a trabalhar em conjunto?
Em nosso whitepaper, Leve-me até o cluster, detalhamos uma solução para viabilizar o acesso externo aos serviços do Kubernetes, permitindo que as equipes de Redes e Aplicações combinem seus pontos fortes sem conflitos.
Como expor aplicações em clusters Kubernetes
A solução funciona especificamente para clusters Kubernetes hospedados localmente, com nós executados em servidores físicos ou máquinas virtuais (VMs) Linux tradicionais e switches padrão de camada 2 e roteadores de camada 3 que fornecem a conectividade necessária para a comunicação no data center. Ela não se aplica a clusters Kubernetes hospedados na nuvem, pois os provedores de nuvem não nos permitem controlar a infraestrutura de rede principal de seus data centers nem a rede de seus ambientes Kubernetes gerenciados.
Antes de abordarmos os detalhes da nossa solução, vamos analisar por que outras formas convencionais de expor aplicações em um cluster Kubernetes não funcionam em implantações locais:
- Serviço – Agrupa pods que executam os mesmos aplicativos. Isso é ótimo para a comunicação interna entre pods, mas só fica visível dentro do cluster e, portanto, não ajuda a expor aplicativos externamente.
- NodePort – Abre uma porta específica em cada nó do cluster e encaminha o tráfego para o aplicativo correspondente. Embora isso permita que usuários externos acessem o serviço, não é a solução ideal, pois a configuração é estática, é necessário usar portas TCP com números altos (em vez de portas mais baixas e conhecidas) e coordenar os números das portas com outros aplicativos. Além disso, não é possível compartilhar portas TCP comuns entre diferentes aplicativos.
- LoadBalancer – Usa as definições de NodePort em cada nó para criar um caminho de rede do mundo externo até os nós do Kubernetes. É uma ótima opção para o Kubernetes hospedado na nuvem, pois a AWS, o Google Cloud Platform, o Microsoft Azure e a maioria dos outros provedores de nuvem oferecem suporte a esse recurso, que é fácil de configurar, funciona bem e fornece o endereço IP público necessário e o registro DNS
Acorrespondente para um serviço. Infelizmente, não há equivalente para clusters locais.
Habilitando o acesso de usuários externos a clusters Kubernetes locais
Isso nos deixa com o objeto Ingress do Kubernetes, projetado especificamente para o tráfego que flui de usuários externos ao cluster para pods dentro dele (tráfego norte-sul). O Ingress cria um ponto de entrada HTTP/HTTPS externo para o cluster — um único endereço IP ou nome DNS por meio do qual usuários externos podem acessar vários serviços. É exatamente o que precisamos! O objeto Ingress é implementado por um controlador Ingress — em nossa solução, o F5 NGINX Ingress Controller de nível empresarial, baseado no NGINX Plus.
Talvez você se surpreenda ao saber que outro componente essencial da solução é o Border Gateway Protocol (BGP), um protocolo de roteamento da camada 3. Mas uma ótima solução não precisa ser complexa!
A solução apresentada em Get Me to the Cluster na verdade tem quatro componentes:
- Rede iBGP – O BGP interno (iBGP) é usado para trocar informações de roteamento dentro de um sistema autônomo (AS) no data center e ajuda a garantir que a rede seja confiável e escalável. O iBGP já está implementado e conta com o suporte da equipe de Rede na maioria dos data centers.
- Rede CNI do Project Calico – Project Calico é uma solução de rede de código aberto que conecta ambientes de forma flexível em data centers locais, oferecendo controle granular sobre o fluxo de tráfego. Usamos o plug-in CNI do Project Calico para a rede do cluster do Kubernetes, com o BGP habilitado. Isso permite controlar os pools de endereços IP alocados aos pods, o que ajuda a identificar rapidamente possíveis problemas de rede.
- NGINX Ingress Controller baseado no NGINX Plus – Com o NGINX Ingress Controller, você pode monitorar os endereços IP dos endpoints de serviço dos pods e reconfigurar automaticamente a lista de serviços upstream sem interromper o processamento do tráfego. As equipes de aplicações também podem aproveitar os diversos outros recursos HTTP de camada 7 de nível empresarial do NGINX Plus, incluindo verificações ativas de integridade, mTLS e autenticação baseada em JWT.
- NGINX Plus como proxy reverso na borda – O NGINX Plus atua como um proxy reverso na borda do cluster do Kubernetes, fornecendo um caminho entre os switches e roteadores no data center e a rede interna do cluster do Kubernetes. Essa configuração substitui o objeto LoadBalancer do Kubernetes e usa o Quagga para BGP.
O diagrama ilustra a arquitetura da solução, indicando quais protocolos os componentes da solução usam para se comunicar, e não a ordem em que os dados são trocados durante o processamento das solicitações.
Baixe o whitepaper gratuitamente
Ao trabalharem em conjunto para implementar uma solução com componentes bem definidos, as equipes de Redes e Aplicações podem facilmente oferecer desempenho e confiabilidade ideais.
Nossa solução utiliza ferramentas e protocolos de rede modernos, além das arquiteturas existentes. Como foi projetada para ter baixo custo e ser fácil de implementar, gerenciar e oferecer suporte, ela simplifica o trabalho e promove a integração entre suas equipes.
Para ver o código em ação e aprender passo a passo como implantar nossa solução, baixe gratuitamente Get Me to the Cluster for free.
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.