NodePort, LoadBalancer, controlador de Ingress… meu Deus!
Quando conversamos com clientes e com a comunidade sobre como preparar o Kubernetes para ambientes de produção, uma das perguntas mais comuns é: preciso de um controlador Ingress? A resposta a essa pergunta raramente é um simples sim ou não. Em vez disso, é preciso entender as diferentes maneiras de direcionar o tráfego para seus pods. Neste blog, abordamos os conceitos básicos de redes no Kubernetes para que você possa tomar uma decisão bem fundamentada sobre se — e quando — precisa de um controlador Ingress.
O Kubernetes oferece suporte a várias abordagens e camadas possíveis para rotear o tráfego externo para um pod – mas nem todas são equivalentes. O modelo padrão é o kube-proxy, que, na verdade, não é um proxy e não foi projetado para balancear o tráfego, controlar APIs nem monitorar o comportamento dos serviços.
Felizmente, há outras maneiras de gerenciar o tráfego externo, mas, antes de continuarmos, vamos fazer uma breve revisão dos componentes do Kubernetes:
- As implantações do Kubernetes são compostas por nós, que são máquinas físicas ou virtuais.
- Os nós se unem para formar um cluster.
- Cada cluster gerencia pods, que são a menor unidade comum no nível de rede e infraestrutura do Kubernetes. Um ou mais pods juntos formam um serviço.
- Dentro de cada pod, há um ou mais contêineres (dependendo do tamanho da aplicação).
O Kubernetes monitora os pods que compõem um serviço e os dimensiona conforme necessário para atender aos requisitos da aplicação. Mas como direcionar o tráfego para os pods? É aí que entram dois tipos de objetos do Kubernetes: serviços e controladores de Ingress.
O que é um serviço do Kubernetes?
De acordo com a documentação do Kubernetes, um serviço é “uma forma abstrata de expor um aplicativo executado em um conjunto de Pods”. Um serviço conecta pods em um cluster ou uma rede de contêineres de modo que sua localização em um nó específico não seja relevante. Isso significa que o tráfego externo pode ser direcionado a pods específicos mesmo quando suas localizações mudam ou quando eles são destruídos e reiniciados. Dessa forma, um serviço funciona de maneira muito semelhante a um proxy reverso bastante básico.
Há vários tipos de serviços e de objetos de serviço relevantes para o roteamento de tráfego externo para o Kubernetes. Eles costumam ser confundidos entre si, mas, na verdade, cada um desempenha funções muito diferentes. Por isso, vale a pena analisar suas funções, aplicações e desvantagens.
ClusterIP
ClusterIP é o serviço padrão que disponibiliza um serviço no Kubernetes que pode ser acessado por outros serviços dentro do cluster. Ele não pode ser acessado de fora do cluster. A única maneira de expor um serviço ClusterIP é usar algo como o kube-proxy, mas há poucos cenários em que isso faz sentido. Alguns exemplos específicos incluem acessar um serviço no seu laptop, depurar um serviço ou consultar dados de monitoramento e métricas.
NodePort
Um serviço NodePort abre uma porta específica em cada nó do cluster e encaminha todo o tráfego enviado ao nó nessa porta para o aplicativo correspondente. Essa é uma maneira muito básica de direcionar tráfego para seus aplicativos e apresenta muitas limitações em casos reais de uso de gerenciamento de tráfego. Você pode ter apenas um serviço por NodePort e usar somente portas no intervalo de 30000 a 32767. Embora 2768 portas possam parecer muitas, organizações que executam o Kubernetes em grande escala ficarão rapidamente sem portas disponíveis. Além disso, o NodePort usa regras de roteamento da Camada 4 e o utilitário iptables do Linux, o que limita o roteamento da Camada 7.
Além das limitações de roteamento, há três outras grandes desvantagens no uso do NodePort:
- Os clientes downstream precisam saber o endereço IP de cada nó para se conectarem a ele – isso se torna problemático se o endereço IP do nó ou o host da máquina virtual mudar.
- O NodePort não pode encaminhar o tráfego para vários endereços IP.
- Como mostrado no diagrama, o NodePort não fornece balanceamento de carga nos clusters do Kubernetes, portanto, o tráfego é distribuído aleatoriamente entre os serviços. Isso pode resultar em sobrecarga dos serviços e esgotamento de portas.
LoadBalancer
Um serviço LoadBalancer aceita tráfego externo, mas requer um balanceador de carga externo como interface para esse tráfego. Isso permite o roteamento de camada 7 (para endereços IP de pods), desde que o balanceador de carga externo esteja devidamente ajustado e reconfigurado para mapear os pods em execução. O LoadBalancer é uma das formas mais populares de expor serviços externamente. Ele é usado com mais frequência em plataformas de nuvem e é uma boa opção para implantações pequenas e estáticas.
Se você estiver usando um serviço gerenciado do Kubernetes, receberá automaticamente o balanceador de carga selecionado pelo provedor de nuvem. Por exemplo, no Google Cloud Platform, você pode criar um Network Load Balancer usando o tipo de serviço LoadBalancer, enquanto o Application Load Balancer (ALB) é o padrão na AWS. Cada serviço exposto recebe seu próprio endereço IP público, que encaminha todo o tráfego, mas sem qualquer filtragem ou roteamento, o que significa que você pode enviar praticamente qualquer tipo de tráfego (HTTP, TCP/UDP, WebSocket etc.). Como alternativa, se não quiser usar as ferramentas do provedor de nuvem — por exemplo, se precisar de mais funcionalidades ou de uma ferramenta independente de plataforma —, você poderá substituí-las por algo como F5 BIG-IP (como balanceador de carga externo) e F5 Container Ingress Services (como um operador que desempenha a função de LoadBalancer). Para saber mais sobre esse padrão, consulte Implantação do BIG-IP e do NGINX Ingress Controller na mesma arquitetura em nosso blog.
Usar o LoadBalancer para expor seus aplicativos torna-se um desafio em ambientes dinâmicos, nos quais os pods dos aplicativos precisam ser escalados para acompanhar as variações na demanda. Como cada serviço recebe seu próprio endereço IP, um aplicativo popular pode ter centenas — ou até milhares — de endereços IP para gerenciar. Na maioria dos casos, o balanceador de carga externo se conecta aos serviços por meio do NodePort, conforme mostrado no diagrama a seguir. Embora isso garanta que o tráfego seja distribuído uniformemente entre os nós, ainda não é possível balancear a carga entre os serviços, portanto, você continua sujeito à sobrecarga dos serviços e ao esgotamento de portas.
O que é um controlador de Ingress do Kubernetes?
De acordo com a documentação do Kubernetes, “os controladores são loops de controle que monitoram o estado do cluster e fazem ou solicitam alterações quando necessário. Cada controlador tenta aproximar o estado atual do cluster do estado desejado.” Os controladores são usados para gerenciar o estado no Kubernetes em diversas tarefas, como alocar recursos corretamente, definir o armazenamento persistente e gerenciar tarefas cron.
No contexto do roteamento, um controlador Ingress é a solução para superar as limitações do NodePort e do LoadBalancer.
Um controlador Ingress é usado para configurar e gerenciar interações externas com pods rotulados para um serviço específico. Os controladores Ingress são projetados para tratar o roteamento dinâmico da Camada 7 como um recurso de primeira classe. Isso significa que eles oferecem controle e gerenciamento muito mais granulares, com menos trabalho operacional. Você pode usar facilmente um controlador Ingress não apenas para controlar o tráfego de entrada, mas também para fornecer métricas de desempenho no nível do serviço e como parte de uma política de segurança. Os controladores Ingress têm muitos recursos dos balanceadores de carga externos tradicionais, como terminação TLS, gerenciamento de vários domínios e namespaces e, é claro, balanceamento de tráfego. Eles podem balancear o tráfego por solicitação, em vez de por serviço, proporcionando uma visão mais útil do tráfego da Camada 7 e uma maneira muito melhor de aplicar SLAs.
E há mais uma vantagem! Os controladores de Ingress também podem aplicar regras de egress que permitem o tráfego de saída de determinados pods apenas para serviços externos específicos ou garantir que o tráfego seja criptografado mutuamente usando mTLS. Exigir mTLS é fundamental para fornecer serviços regulamentados em setores como saúde, finanças, telecomunicações e governo — além de ser um componente essencial de uma estratégia de criptografia de ponta a ponta (E2EE). Controlar o tráfego de saída com a mesma ferramenta também simplifica a aplicação da lógica de negócios aos serviços. É muito mais fácil configurar regras de recursos adequadas quando o ingress e o egress estão vinculados no mesmo plano de controle.
O diagrama a seguir mostra como um controlador de Ingress reduz a complexidade para o cliente, que não precisa mais saber o endereço IP ou a porta de um serviço. A distribuição do tráfego entre os serviços é garantida. Alguns controladores de Ingress oferecem suporte a vários algoritmos de balanceamento de carga, proporcionando mais flexibilidade e controle.
Implantando um balanceador de carga com um controlador de Ingress
Conforme discutimos em Implantação do BIG-IP e do NGINX Ingress Controller na mesma arquitetura, muitas organizações têm casos de uso que se beneficiam da implantação de um balanceador de carga externo com um Ingress Controller (ou, na maioria dos casos, várias instâncias do Ingress Controller). Isso é especialmente comum quando as organizações precisam escalar o Kubernetes ou operar em ambientes com requisitos rigorosos de conformidade. Normalmente, as ferramentas são gerenciadas por equipes diferentes e usadas para finalidades distintas:
- Balanceador de carga (ou ADC):
- Responsável: uma equipe de NetOps (ou talvez de SecOps)
- Caso de uso: fora do Kubernetes, como o único endpoint voltado ao público para serviços e aplicativos disponibilizados a usuários externos ao cluster. Usado como um appliance mais genérico, projetado para reforçar a segurança e oferecer gerenciamento de rede de nível mais avançado.
- Controlador de Ingress:
- Responsável: uma equipe de Operações de Plataforma ou DevOps
- Caso de uso: Dentro do Kubernetes, para balanceamento de carga granular do tráfego norte-sul (HTTP2, HTTP/HTTPS, terminação SSL/TLS, TCP/UDP, WebSocket, gRPC), funções de gateway de API e gerenciamento centralizado de segurança e identidade.
Este diagrama mostra o balanceador de carga gerenciando a distribuição do tráfego entre vários clusters, enquanto os clusters têm controladores de Ingress para garantir uma distribuição uniforme entre os serviços.
Próximos passos
Se você leu tudo isso e ainda está com dúvidas, confira o webinar da Linux Foundation Por que você precisa de um controlador de Ingress e como escolher um, no qual especialistas da NGINX apresentam uma introdução às redes do Kubernetes, exploram em detalhes os controladores de Ingress e discutem o panorama dessas soluções.
Para saber mais sobre como usar um controlador de Ingress – e como escolher o mais adequado às suas necessidades – leia Guia para escolher um controlador de Ingress, Parte 1: identifique seus requisitos em nosso blog.
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.