Comparar modelos de rede no GKE

Neste documento, descrevemos o modelo de rede usado pelo Google Kubernetes Engine (GKE) e como ele pode ser diferente dos modelos de rede em outros ambientes do Kubernetes. Este documento abrange os seguintes conceitos:

  • Os modelos de rede mais comuns usados por várias implementações do Kubernetes.
  • Os mecanismos de endereçamento IP dos modelos de rede mais comuns.
  • As vantagens e desvantagens de cada modelo de rede.
  • Uma descrição detalhada do modelo de rede padrão usado pelo GKE.

O documento é destinado a arquitetos de nuvem, engenheiros de operações e engenheiros de rede que podem conhecer outras implementações do Kubernetes e planejar usar o GKE. Para seguir este documento, é necessário ter familiaridade com o Kubernetes e o modelo de rede básico. Também é necessário conhecer conceitos de rede, como endereçamento IP, conversão de endereços de rede (NAT, na sigla em inglês), firewalls e proxies.

Neste documento, não abordamos como modificar o modelo de rede padrão do GKE para atender a várias restrições de endereços IP. Se você tiver uma falta de endereços IP ao migrar para o GKE, consulte Estratégias de gerenciamento de endereços IP ao migrar para o GKE.

Implementações típicas do modelo de rede

É possível implementar o modelo de rede do Kubernetes de várias maneiras. No entanto, qualquer implementação sempre precisa atender aos seguintes requisitos:

  • Todo pod precisa de um endereço IP exclusivo.
  • Os pods podem se comunicar com outros pods em todos os nós sem usar o NAT.
  • Os agentes em um nó, como o kubelet, podem se comunicar com todos os pods nesse nó.
  • Os pods na rede do host de um nó podem se comunicar com todos os pods em todos os nós sem usar o NAT.

Existem mais de 20 implementações diferentes para o modelo de rede do Kubernetes desenvolvidas que atendem a esses requisitos.

Essas implementações podem ser agrupadas em três tipos de modelos de rede. Esses três modelos diferem das seguintes maneiras:

  • Como os pods podem se comunicar com serviços que não são do Kubernetes na rede corporativa.
  • Como os pods podem se comunicar com outros clusters do Kubernetes na mesma organização.
  • Indica se o NAT é necessário para comunicação fora do cluster.
  • Se os endereços IP do pod podem ser reutilizados em outros clusters ou em outro lugar na rede corporativa.

Cada nuvem comprovada implementou um ou mais desses tipos de modelo.

A tabela a seguir identifica os três tipos de modelos que costumam ser usados e em qual implementação do Kubernetes eles são usados:

Nome do modelo da rede Usado nessas implementações
Totalmente integrado ou plano
Modo Ilha ou em ponte
Isolado ou aéreo
  • Não é comumente usado por implementações do Kubernetes, mas pode ser usado com qualquer implementação quando o cluster é implantado em uma rede separada ou em uma nuvem privada virtual (VPC, na sigla em inglês)

Quando este documento descreve esses modelos de rede, ele se refere aos efeitos deles em redes locais conectadas. No entanto, é possível aplicar os conceitos descritos para redes locais conectadas a redes conectadas por meio de uma rede privada virtual (VPN) ou de uma interconexão privada, incluindo conexões com outros provedores de nuvem. Para o GKE, essas conexões incluem toda a conectividade por meio do Cloud VPN ou do Cloud Interconnect.

Modelo de rede totalmente integrado

O modelo de rede (ou plano) totalmente integrado oferece facilidade de comunicação com aplicativos fora do Kubernetes e em outros clusters do Kubernetes. Grandes provedores de serviços de nuvem geralmente implementam esse modelo porque podem integrar perfeitamente a implementação do Kubernetes deles com a rede definida por software (SDN, na sigla em inglês).

Quando você usa o modelo totalmente integrado, os endereços IP usados para pods são roteados na rede em que o cluster do Kubernetes está localizado. Além disso, a rede subjacente sabe em qual nó os endereços IP do pod estão localizados. Em muitas implementações, os endereços IP do pod no mesmo nó são de um intervalo de endereços IP do pod pré-atribuído específico. No entanto, esse intervalo de endereços pré-atribuído não é obrigatório.

O diagrama a seguir mostra as opções de comunicação de pod no modelo de rede totalmente integrado:

Diagrama de rede que mostra os padrões de comunicação no modelo de rede totalmente integrado.

O diagrama anterior de um modelo de rede totalmente integrado mostra os seguintes padrões de comunicação:

  • Os pods em um cluster do Kubernetes podem se comunicar diretamente.
  • Os pods podem se comunicar com outros pods em outros clusters, desde que eles estejam dentro da mesma rede.
  • Os pods não precisam do NAT para se comunicar com outros aplicativos fora do cluster, independentemente de estarem na mesma rede ou nas redes interconectadas.

O diagrama também mostra que os intervalos de endereços IP do pod são distintos entre diferentes clusters.

O modelo de rede totalmente integrado está disponível nas seguintes implementações:

  • Por padrão, o GKE implementa esse modelo. Para mais informações sobre essa implementação, consulte Modelo de rede do GKE mais adiante neste documento.
  • Por padrão, o Amazon EKS implementa esse modelo. Nesta implementação, o Amazon EKS usa o plug-in da interface de rede de contêiner (CNI, na sigla em inglês) da Amazon para Kubernetes para atribuir endereços IP do pod diretamente do espaço de endereço da VPC. O plug-in da CNI atribui endereços IP da sub-rede padrão em que os nós estão ou de uma sub-rede personalizada. Os endereços IP do pod não vêm de um intervalo de endereços IP do pod dedicado por nó.
  • No Azure, o AKS implementa esse modelo ao usar o Azure CNI (rede avançada). Essa implementação não é a configuração padrão. Nesta implementação, cada pod recebe um endereço IP da sub-rede. Também é possível configurar o número máximo de pods por nó. Assim, o número de endereços IP reservados com antecedência para pods nesse nó é o mesmo que o número máximo de pods por nó.

Usar um modelo de rede totalmente integrado oferece as seguintes vantagens:

  • Melhor dados de telemetria. Os endereços IP do pod são visíveis em toda a rede. Essa visibilidade torna os dados de telemetria mais úteis do que em outros modelos porque eles podem ser identificados até mesmo em dados de telemetria coletados fora do cluster.
  • Configuração de firewall mais fácil. Ao definir regras de firewall, diferenciar o tráfego de nós e de pods é mais fácil no modelo de rede totalmente integrado do que nos outros modelos.
  • Melhor compatibilidade. Os pods podem se comunicar usando protocolos não compatíveis com NAT.
  • Melhoria na depuração. Com a permissão do firewall, recursos fora do cluster podem acessar pods diretamente durante o processo de depuração.
  • Compatibilidade com malhas de serviço. As malhas de serviço, como o Istio ou o Anthos Service Mesh, podem se comunicar facilmente entre clusters porque os pods podem se comunicar diretamente entre si. Algumas implementações de malha de serviço são compatíveis apenas com a conectividade entre pods para malhas de serviço de vários clusters.

Usar um modelo de rede totalmente integrado tem as seguintes desvantagens:

  • Uso do endereço IP. Não é possível reutilizar endereços IP do pod dentro da rede, e cada endereço IP precisa ser exclusivo. Esses requisitos podem levar a um grande número de endereços IP que precisam ser reservados para pods.
  • Requisitos do SDN. Um modelo de rede totalmente integrado requer uma integração profunda com a rede subjacente, porque a implementação do Kubernetes precisa programar diretamente o SDN. A programação do SDN é transparente para o usuário e não produz desvantagens para o usuário. No entanto, esses modelos de rede profundamente integrados não podem ser facilmente implementados em ambientes autogerenciados e locais.

Modelo de rede no modo ilha

O modelo de rede no modo ilha (ou ponte) é normalmente usado para implementações locais do Kubernetes, em que nenhuma integração profunda com a rede subjacente é possível. Quando você usa um modelo de rede no modo ilha, os pods em um cluster Kubernetes podem se comunicar com recursos fora do cluster por meio de algum tipo de gateway ou proxy.

O diagrama a seguir mostra opções de comunicação de pod em um modelo de rede no modo de ilha:

Diagrama de rede que mostra os padrões de comunicação no modelo de rede no modo ilha.

O diagrama anterior de um modelo de rede no modo de ilha mostra como os pods em um cluster do Kubernetes podem se comunicar diretamente entre si. Ele também mostra que os pods em um cluster precisam usar um gateway ou proxy ao se comunicar com aplicativos fora do cluster ou pods em outros clusters. Embora a comunicação entre um cluster e um aplicativo externo exija um único gateway, a comunicação entre clusters requer dois gateways. O tráfego entre dois clusters passa por um gateway ao sair do primeiro e outro gateway ao entrar no outro.

Há diferentes maneiras de implementar os gateways ou proxies em um modelo de rede isolado. As seguintes implementações são os dois gateways ou proxies mais comuns:

  • Como usar os nós como gateways. Essa implementação é normalmente usada quando os nós no cluster fazem parte da rede existente e os endereços IP deles são nativamente roteáveis nessa rede. Nesse caso, os próprios nós são os gateways que fornecem conectividade de dentro do cluster para a rede maior. O tráfego de saída de um pod para fora do cluster pode ser direcionado para outros clusters ou para aplicativos que não são do Kubernetes, por exemplo, para chamar uma API local na rede corporativa. Para esse tráfego de saída, o nó que contém o pod usa o NAT de origem (SNAT) para mapear o endereço IP do pod para o endereço IP do nó. Para permitir que aplicativos fora do cluster se comuniquem com os serviços no cluster, é possível usar o tipo de serviço NodePort para a maioria das implementações. Em algumas implementações, é possível usar o tipo de serviço LoadBalancer para expor serviços. Ao usar o tipo de serviço LoadBalancer, você fornece a esses serviços um endereço IP virtual com balanceamento de carga entre nós e roteado para um pod que faz parte do serviço.

    O diagrama a seguir mostra o padrão de implementação ao usar nós como gateways:

    Diagrama de rede que mostra os padrões de comunicação no modelo de rede no modo ilha que usa nós como gateways.

    O diagrama anterior mostra que o uso de nós como gateways não tem impacto na comunicação entre pods em um cluster. Os pods em um cluster ainda se comunicam diretamente. No entanto, o diagrama também mostra os seguintes padrões de comunicação fora do cluster:

    • Como os pods se comunicam com outros clusters ou aplicativos que não são do Kubernetes usando o SNAT ao sair do nó.
    • Como o tráfego de Serviços externos em outros clusters ou aplicativos que não são do Kubernetes entra no cluster por meio de um serviço NodePort antes de ser encaminhado para o pod correto no cluster.

  • Usar máquinas virtuais (VMs) de proxy com várias interfaces de rede. Esse padrão de implementação usa proxies para acessar a rede que contém o cluster do Kubernetes. Os proxies precisam ter acesso ao espaço de endereços IP do pod e do nó. Nesse padrão, cada VM do proxy tem duas interfaces de rede: uma interface na rede corporativa maior e uma interface na rede que contém o cluster do Kubernetes.

    O diagrama a seguir mostra o padrão de implementação ao usar VMs de proxy:

    Diagrama de rede que mostra os padrões de comunicação no modelo de rede no modo ilha que usa VMs de proxy.

    O diagrama anterior mostra que o uso de proxies no modo de ilha não tem impacto na comunicação em um cluster. Os pods em um cluster ainda podem se comunicar diretamente. No entanto, o diagrama também mostra como a comunicação de pods para outros clusters ou aplicativos que não são do Kubernetes passa por um proxy que tem acesso à rede do cluster e à rede de destino. Além disso, a comunicação externa do cluster também passa pelo mesmo tipo de proxy.

O modelo de rede no modo ilha está disponível nas seguintes implementações:

  • Por padrão, o Azure Kubernetes Service (AKS) usa redes em modo de ilha ao usar a rede Kubenet (básica). Quando o AKS usa rede em modo de ilha, a rede virtual que contém o cluster inclui apenas endereços IP de nó. Os endereços IP do pod não fazem parte da rede virtual. Em vez disso, os pods recebem endereços IP de um espaço lógico diferente. O modelo no modo ilha usado pelo AKS também roteia o tráfego de pod para pod entre nós usando rotas definidas pelo usuário com encaminhamento de IP ativado na interface de nós. Para a comunicação de pods com recursos fora do cluster, o nó usa o SNAT para mapear o endereço IP do pod para o endereço IP do nó antes que o tráfego de saída saia do nó.
  • No Oracle Container Engine para Kubernetes (OKE), a comunicação entre pods usa uma rede de sobreposição VXLAN (em inglês). Além disso, o tráfego de pods para aplicativos fora do cluster usa o SNAT para mapear o endereço IP do pod para o endereço IP do nó.

Usar um modelo de rede no modo de ilha tem as seguintes vantagens:

  • Uso do endereço IP. Os endereços IP do pod no cluster podem ser reutilizados em outros clusters. No entanto, os endereços IP que já são usados por serviços externos na rede corporativa não podem ser usados para pods se a comunicação precisar acontecer entre os pods e esses serviços. Portanto, a prática recomendada para a rede no modo de ilha é reservar um espaço de endereço IP do pod exclusivo na rede e usar esse espaço de endereço IP para todos os clusters.
  • Configurações de segurança mais fáceis. Como os pods não são diretamente expostos ao restante da rede corporativa, você não precisa proteger os pods contra o tráfego de entrada do restante da rede corporativa.

Usar um modelo de rede no modo de ilha tem as seguintes desvantagens:

  • Telemetria imprecisa. Os dados de telemetria coletados fora do cluster contêm apenas o endereço IP do nó, não o endereço IP do pod. A falta de endereços IP do pod dificulta a identificação da origem e do destino do tráfego.
  • Mais difícil de depurar. Ao depurar, não é possível se conectar diretamente aos pods de fora do cluster.
  • Mais difícil de configurar firewalls. Só é possível usar endereços IP de nós quando você configura o firewall. Assim, as configurações de firewall resultantes permitem que todos os pods em um nó e o próprio nó alcancem serviços externos ou que nenhum deles alcance serviços externos.

  • Compatibilidade com malhas de serviço. No modo ilha, a comunicação direta entre pods nos clusters em malhas de serviço, como o Istio ou o Anthos Service Mesh, não é possível.

    Há outras restrições em algumas implementações de malha de serviço. O suporte a vários clusters do Anthos Service Mesh para clusters do GKE no Google Cloud é compatível apenas com clusters na mesma rede. Para implementações do Istio compatíveis com um modelo de várias redes, a comunicação precisa ocorrer por meio de gateways do Istio, que faz implantações de malha de serviço de vários clusters. mais complexo.

Modelo de rede isolado

O modelo de rede isolado (ou aéreo) é mais usado para clusters que não precisam de acesso à rede corporativa maior, exceto por meio de APIs voltadas para o público. Quando você usa um modelo de rede isolado, cada cluster do Kubernetes é isolado e não pode usar endereços IP internos para se comunicar com o restante da rede. O cluster fica em uma rede privada própria. Se algum pod no cluster precisar se comunicar com serviços fora do cluster, essa comunicação precisará usar endereços IP públicos para entrada e saída.

O diagrama a seguir mostra opções de comunicação de pod em um modelo de rede isolado:

Diagrama de rede que mostra os padrões de comunicação no modelo de rede isolado.

O diagrama anterior de um modelo de rede isolado mostra que os pods em um cluster do Kubernetes podem se comunicar diretamente entre si. O diagrama também mostra que os pods não podem usar endereços IP internos para se comunicar com pods em outros clusters. Além disso, os pods só podem se comunicar com aplicativos fora do cluster quando os seguintes critérios são atendidos:

  • Há um gateway de Internet que conecta o cluster ao lado externo.
  • O aplicativo externo usa um endereço IP externo para comunicações.

Por fim, o diagrama mostra como o mesmo espaço de endereço IP para pods e nós pode ser reutilizado entre ambientes diferentes.

O modelo de rede isolado não é normalmente usado por implementações do Kubernetes. No entanto, é possível conseguir um modelo de rede isolado em qualquer implementação. Você só precisa implantar um cluster do Kubernetes em uma rede ou VPC separada sem conectividade com outros serviços ou na rede corporativa. A implementação resultante teria as mesmas vantagens e desvantagens que o modelo de rede isolado.

Usar um modo de rede isolado tem as seguintes vantagens:

  • Uso do endereço IP. É possível reutilizar todos os endereços IP internos no cluster: endereços IP dos nós, do serviço e do pod. Isso é possível porque cada cluster tem uma rede privada própria. A comunicação com os recursos fora do cluster só acontece por meio de endereços IP públicos.
  • Controle. Os administradores do cluster têm controle total sobre os endereços IP no cluster e não precisam executar tarefas de gerenciamento de endereços IP. Por exemplo, os administradores podem alocar o espaço de endereço 10.0.0.0/8 completo para pods e Serviços no cluster, mesmo se esses endereços já estiverem sendo usados na organização.
  • Segurança. A comunicação fora do cluster é bem controlada e, quando permitida, usa interfaces externas bem definidas e NAT.

Usar um modelo de rede isolado tem as seguintes desvantagens:

  • Proibição de comunicação particular. A comunicação usando endereços IP internos não é permitida para outros clusters ou outros serviços na rede.

Modelo de rede do GKE

O GKE usa um modelo de rede totalmente integrado onde os clusters são implantados na rede de nuvem privada virtual (VPC) que também pode ter outros aplicativos.

Recomendamos o uso de um cluster nativo de VPC no ambiente do GKE. É possível criar seu cluster nativo de VPC no Standard ou no Autopilot. Se você escolher o modo Autopilot, o modo nativo de VPC estará sempre ativado e não poderá ser desativado. Os parágrafos a seguir descrevem o modelo de rede do GKE no modo Standard com observações sobre como o modo Autopilot é diferente.

Gerenciamento de endereços IP em clusters nativos de VPC

Quando você usa um cluster nativo de VPC, os endereços IP do pod são endereços IP secundários em cada nó. Cada nó recebe uma sub-rede específica de um intervalo de endereços IP do pod que você seleciona fora do espaço de endereço IP interno ao criar o cluster. Por padrão, um cluster nativo de VPC atribui uma sub-rede /24 a cada nó para uso como endereços IP do pod. Uma sub-rede /24 corresponde a 256 endereços IP. No modo Autopilot, o cluster usa uma sub-rede /26 que corresponde a 64 endereços e não é possível alterar essa configuração de sub-rede.

O modelo de rede do GKE não permite que os endereços IP sejam reutilizados na rede. Ao migrar para o GKE, você precisa planejar a alocação de endereços IP para Reduzir o uso de endereços IP internos no GKE.

Como os endereços IP do pod são roteáveis dentro da rede VPC, os pods podem receber tráfego, por padrão, dos seguintes recursos:

Gerenciar a comunicação de tráfego externo com um agente de mascaramento de IP

Quando você se comunica de pods para serviços fora do cluster, o agente de mascaramento de IP rege a aparência do tráfego para esses serviços. O agente de mascaramento de IP lida com endereços IP particulares e externos de maneira diferente, conforme descrito nos marcadores a seguir:

  • Por padrão, o agente de mascaramento de IP não mascara o tráfego para endereços IP internos, incluindo endereços IP RFC 1918 ou endereços não RFC 1918 normalmente usados internamente. Para mais informações, consulte a lista de destinos padrão não mascarados. Como os endereços IP internos não são mascarados, o nó não usa NAT nesses endereços.
  • Em endereços IP externos, o agente de mascaramento de IP mascara os endereços para o endereço IP do nó. Portanto, esses endereços mascarados são convertidos em um endereço IP externo pelo Cloud NAT ou pelo endereço IP externo da máquina virtual (VM) .

Também é possível usar endereços IP públicos de uso privado (PUPI) dentro da rede VPC ou de redes conectadas. Se você usar endereços PUPI, ainda poderá se beneficiar do modelo de rede totalmente integrado e ver o endereço IP do pod diretamente como origem. Para alcançar esses objetivos, é preciso incluir os endereços PUPI na lista nonMasqueradeCIDRs.

Noções básicas sobre o fluxo de tráfego do pod em uma rede do GKE

O diagrama a seguir mostra como os pods podem se comunicar no modelo de rede do GKE:

Diagrama de rede que mostra os padrões de comunicação no modelo de rede do GKE.

O diagrama anterior mostra como os pods em ambientes do GKE podem usar endereços IP internos para se comunicar diretamente com os seguintes recursos:

  • Outros pods no mesmo cluster.
  • Pods em outros clusters do GKE na mesma rede VPC.
  • Outros aplicativos do Google Cloud na mesma rede VPC.
  • Aplicativos locais conectados pelo Cloud VPN.

Ele também mostra o que acontece quando um pod precisa usar um endereço IP externo para se comunicar com um aplicativo. À medida que o tráfego sai do nó, o nó em que o pod reside usa o SNAT para mapear o endereço IP do pod para o endereço IP do nó. Depois que o tráfego sai do nó, o Cloud NAT converte o endereço IP do nó em um endereço IP externo.

Para os benefícios descritos anteriormente neste documento, especialmente para que os endereços IP do pod fiquem visíveis em todos os dados de telemetria, o Google escolheu um modelo de rede totalmente integrado. No GKE, os endereços IP do pod são expostos em registros de fluxo de VPC (incluindo nomes de pod em metadados), Espelhamento de pacotes, Geração de registros de regras de firewall e nos próprios registros de aplicativo para destinos não mascarados.

A seguir