Noções básicas de rede do Kubernetes

NodePort, LoadBalancer, controlador Ingress…oh meu Deus!

Quando conversamos com clientes e a comunidade sobre como tornar o Kubernetes de nível 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, mas envolve alguma educação sobre as diferentes maneiras de obter tráfego para seus pods. Neste blog, abordamos os conceitos básicos de rede do Kubernetes para que você possa tomar uma decisão informada sobre se – e quando – você precisa de um controlador Ingress.

O Kubernetes oferece suporte a diversas abordagens e camadas possíveis para rotear tráfego externo para um pod, mas elas não são todas criadas da mesma forma. O modelo padrão é kube-proxy , que não é realmente um proxy e não foi projetado para balancear tráfego, controlar APIs ou monitorar comportamentos de serviço.

Felizmente, existem outras maneiras de gerenciar o tráfego externo, mas antes de continuarmos, vamos fazer uma rápida revisão dos componentes do Kubernetes:

• As implantações do Kubernetes são compostas de 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 o menor denominador comum no nível de rede e infraestrutura no Kubernetes. Um ou mais pods juntos formam um serviço .
• Dentro de cada pod reside um ou mais contêineres (dependendo do tamanho do aplicativo).

O Kubernetes monitora os pods que compõem um serviço e os dimensiona conforme necessário para atender aos requisitos do aplicativo. Mas como você direciona tráfego para os pods? É aqui que entram dois tipos de objetos do Kubernetes: serviços e controladores do Ingress.

O que é um serviço Kubernetes?

De acordo com a documentação do Kubernetes , um serviço é “uma maneira abstrata de expor um aplicativo em execução em um conjunto de Pods”. Um serviço conecta pods em um cluster ou rede de contêineres de forma que sua localização em um nó específico não seja relevante. Isso significa que o tráfego externo pode ser roteado para pods específicos, mesmo quando suas localizações mudam ou mesmo quando eles são destruídos e reiniciados. Dessa forma, um serviço atua de forma muito semelhante a um proxy reverso muito básico.

Existem vários tipos de serviços e tipos de objetos de serviço relevantes para o roteamento de tráfego externo para o Kubernetes. Eles costumam ser confundidos, mas na verdade cada um faz coisas muito diferentes, então vale a pena analisar suas funções, usos e desvantagens.

ClusterIP

ClusterIP é o serviço padrão que fornece um serviço dentro do Kubernetes que outros serviços dentro do cluster podem acessar. Não é acessível de fora do cluster. A única maneira de expor um serviço ClusterIP é usar algo como kube-proxy , mas há poucos cenários em que isso faz sentido. Os exemplos limitados incluem acessar um serviço no seu laptop, depurar um serviço ou observar algum monitoramento e métricas.

Porta do nó

Um serviço NodePort abre uma porta específica em cada nó no cluster e encaminha qualquer tráfego enviado ao nó naquela porta para o aplicativo correspondente. Esta é uma maneira muito básica de obter tráfego para seus aplicativos e tem muitas limitações em casos de uso reais de gerenciamento de tráfego. Você pode ter apenas um serviço por NodePort e só pode usar portas no intervalo de 30000 a 32767. Embora 2.768 portas possam parecer muito, organizações que executam Kubernetes em escala ficarão sem espaço rapidamente. Além disso, o NodePort usa regras de roteamento da Camada 4 e o utilitário iptables do Linux, que limita o roteamento da Camada 7.

Além das limitações de roteamento, há três outras grandes desvantagens em usar o NodePort:

• Os clientes downstream devem saber o endereço IP de cada nó para se conectar 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 fazer proxy de tráfego para vários endereços IP.

• Conforme mostrado no diagrama, o NodePort não fornece balanceamento de carga dentro dos clusters do Kubernetes, então o tráfego é distribuído aleatoriamente entre os serviços. Isso pode resultar em sobrecarga de serviço e exaustão de porta.

  

Balanceador de carga

Um serviço LoadBalancer aceita tráfego externo, mas requer um balanceador de carga externo como interface para esse tráfego. Isso oferece suporte ao roteamento da Camada 7 (para endereços IP de pod), desde que o balanceador de carga externo seja ajustado e reconfigurado corretamente para mapear os pods em execução. O LoadBalancer é uma das maneiras mais populares de expor serviços externamente. É mais frequentemente usado em uma plataforma de nuvem e é uma boa escolha para implantações pequenas e estáticas.

Se estiver usando um serviço Kubernetes gerenciado, você obterá 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 que você expõe obtém seu próprio endereço IP público que encaminha todo o tráfego, mas sem nenhuma filtragem ou roteamento, o que significa que você pode enviar quase qualquer tipo de tráfego (HTTP, TCP/UDP, WebSocket, etc.). Como alternativa, se você não quiser usar as ferramentas do provedor de nuvem (por exemplo, se precisar de maior funcionalidade ou de uma ferramenta independente de plataforma), você pode substituí-las por algo como o F5 BIG-IP (como balanceador de carga externo) e o F5 Container Ingress Services (como um operador atuando na capacidade do LoadBalancer). Para mais discussões sobre esse padrão, consulte Implantando o BIG-IP e o NGINX Ingress Controller na mesma arquitetura em nosso blog.

Usar o LoadBalancer para expor seus aplicativos se torna desafiador em ambientes dinâmicos, onde seus pods de aplicativos precisam ser dimensionados para atender aos níveis de demanda em constante mudança. Como cada serviço obtém 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 via NodePort, conforme mostrado no diagrama a seguir. Embora isso garanta que o tráfego seja distribuído uniformemente entre os nós, o balanceamento de carga para os serviços ainda não é possível, então você ainda encontra sobrecarga de serviço e exaustão de porta.

O que é um controlador de entrada do Kubernetes?

De acordo com a documentação do Kubernetes , “os controladores são loops de controle que monitoram o estado do seu cluster e, em seguida, fazem ou solicitam alterações quando necessário. Cada controlador tenta mover o estado atual do cluster para mais perto do estado desejado.” Os controladores são usados para gerenciar o estado no Kubernetes para muitas tarefas: atribuição adequada de recursos, designação de armazenamento persistente e gerenciamento de tarefas cron.

No contexto de roteamento, um controlador Ingress é a maneira de 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 de entrada são projetados para tratar o roteamento dinâmico da Camada 7 como um cidadão de primeira classe. Isso significa que os controladores Ingress fornecem controle e gerenciamento muito mais granulares com menos esforço. 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 em nível de serviço e como parte de uma política de segurança. Os controladores de entrada têm muitos recursos de balanceadores de carga externos tradicionais, como terminação TLS, manipulação de múltiplos domínios e namespaces e, claro, balanceamento de carga de tráfego. Os controladores de entrada podem balancear a carga do tráfego no nível por solicitação em vez de por serviço, uma visão mais útil do tráfego da Camada 7 e uma maneira muito melhor de aplicar SLAs.

E tem outro bônus! Os controladores de entrada também podem impor regras de saída que permitem 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 é crucial para fornecer serviços regulamentados em setores como saúde, finanças, telecomunicações e governo – e é um componente essencial em uma estratégia de criptografia de ponta a ponta (E2EE). Controlar o tráfego de saída da 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 apropriadas quando a entrada e a saída estão vinculadas no mesmo plano de controle.

O diagrama a seguir mostra como um controlador 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 Ingress oferecem suporte a vários algoritmos de balanceamento de carga para mais flexibilidade e controle.

Implantando um balanceador de carga com um controlador de entrada

Conforme discutimos em Implantando o BIG-IP e o 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 controlador Ingress (ou, na maioria dos casos, várias instâncias do controlador Ingress). Isso é especialmente comum quando as organizações precisam dimensionar o Kubernetes ou operar em ambientes de alta conformidade. As ferramentas são normalmente gerenciadas por equipes diferentes e usadas para finalidades diferentes:

• Balanceador de carga (ou ADC):

  • Proprietário: Uma equipe NetOps (ou talvez SecOps)
  • Caso de uso: Fora do Kubernetes como o único ponto de extremidade público para serviços e aplicativos entregues a usuários fora do cluster. Usado como um dispositivo mais genérico projetado para facilitar a segurança e fornecer gerenciamento de rede de nível superior.

• Controlador de entrada:

  • Proprietário: Uma equipe de Platform Ops ou DevOps
  • Caso de uso: Dentro do Kubernetes para balanceamento de carga refinado de tráfego norte-sul (HTTP2, HTTP/HTTPS, terminação SSL/TLS, TCP/UDP, WebSocket, gRPC), funções de gateway de API e segurança e identidade centralizadas.

Este diagrama mostra o balanceador de carga manipulando a distribuição do tráfego entre vários clusters, enquanto os clusters têm controladores de entrada para garantir distribuição igual aos serviços.

PRÓXIMOS PASSOS

Se você leu tudo isso e ainda está coçando a cabeça, confira o webinar da Linux Foundation Por que você precisa de um controlador Ingress e como escolher um , onde especialistas da NGINX fornecem uma introdução à rede Kubernetes, se aprofundam nos controladores Ingress e discutem o cenário dos controladores Ingress.

Para mais informações sobre como você pode usar um controlador Ingress – e como escolher um que funcione melhor para suas necessidades – leia Um guia para escolher um controlador Ingress, Parte 1: Identifique suas necessidades em nosso blog.