Gerenciamento de endereços do GKE: NAT para um bloco CIDR de pod do GKE

Este documento faz parte de uma série destinada a arquitetos de rede. A série discute as opções de gerenciamento de endereços do Google Kubernetes Engine (GKE) disponíveis para organizações restritas a endereços IPv4.

A série consiste nas partes a seguir:

Neste documento, descrevemos uma solução em que o bloco de CIDR de pod é atribuído a um bloco de endereços RFC 1918 que já está em uso na rede local. Esse bloco de CIDR é então convertido com o recurso ip-masq-agent. Essa abordagem oculta os endereços IPv4 do pod atrás dos endereços IP do nó.

Considerações sobre o bloco de CIDR

Ao instalar um cluster do GKE, é necessário alocar três blocos de CIDR: um de nó, um de pod e um de Serviço. Depois de ler os dois primeiros documentos desta série, você terá uma lista das máscaras de rede necessárias para esses blocos e saberá que precisa reutilizar o espaço de endereço do bloco de CIDR de pod.

Ao selecionar um intervalo de endereços, siga estas características e regras de bloco:

  • O bloco de CIDR de pod é considerado um intervalo de endereços reutilizado de VPC isolada. Isso ocorre porque é necessário selecionar o bloco de CIDR no espaço de endereço já atribuído no local e configurar o bloco na VPC isolada.
  • O bloco de CIDR de Serviço pode ser considerado um intervalo de endereços reutilizado de VPC isolada. Faz sentido atribuir um endereço reutilizado a esse espaço porque ele é usado apenas para comunicação entre pods no cluster.
  • O bloco de CIDR de nó precisa ser um endereço alocado de domínio roteado.
  • Os blocos de CIDR de pod e de Serviço não podem ser um subconjunto do bloco de CIDR atribuído à VPC isolada ou um bloco de CIDR atribuído a uma VPC com peering.
  • Os blocos de CIDR de pod e de Serviço não podem ser reutilizados em uma VPC com peering.
  • Os blocos de CIDR de pod, nó e Serviço não podem se sobrepor.
  • Ao selecionar um intervalo de endereços para reutilizar o bloco de CIDR de pod, é necessário selecionar um intervalo atribuído a recursos aos quais os pods nunca precisarão se conectar. Essa abordagem evita a necessidade de atribuir endereços reutilizados de domínio roteado a esses recursos no local.

Solução

A figura a seguir mostra uma visão geral da solução. À direita do diagrama, você encontra sua rede local. À esquerda, você encontra um cluster do GKE dentro da VPC isolada. Os nós do cluster têm o recurso ip-masq-agent configurado. A VPC isolada está divulgando o CIDR de nó do GKE para a rede local. Cada componente funcional é discutido nas seções a seguir.

NAT para um bloco CIDR do pod em um cluster do GKE. Para uma versão em PDF legível na tela, clique na imagem.
Figura 1. NAT para um bloco de CIDR de pod em um cluster do GKE. Para uma versão em PDF legível na tela, clique na imagem.

VPC isolada

A VPC isolada é uma VPC normal. Ela é chamada de isolada para indicar que o espaço de endereço reutilizado precisa estar isolado da tabela de roteamento global no local. Essa VPC tem as seguintes características:

  • Tem a API GKE ativada.
  • Contém o cluster do GKE.
  • Contém balanceadores de carga internos para acesso de domínio roteado aos endereços IP do Serviço do GKE.

Nesta VPC, os intervalos de CIDR de pod são espaços de endereços reutilizados alocados. Os intervalos de CIDR de Serviço podem ser espaços de endereços alocados ou reutilizados alocados. Os blocos CIDR de nó podem ser um espaço de endereço alocado de domínio roteado.

Roteamento

Ao divulgar rotas para a rede local, não é permitido divulgar intervalos de endereços reutilizados de VPC isolada, ou seja, o pod e, possivelmente, os intervalos de CIDR de Serviço. Roteadores ou firewalls no local que fazem peering com os roteadores de nuvem não aceitam blocos de endereços reutilizados de VPC isolada dos respectivos peers roteados.

Configuração NAT

É preciso configurar o cluster do GKE para usar o recurso ip-masq-agent. Os nós do cluster não podem converter os intervalos de blocos de CIDR de pod ou de Serviço na VPC ou em VPCs com peering.

Tráfego originado na VPC isolada que segue até o domínio roteado

O tráfego originário de endereços reutilizados de VPC isolada de pod é convertido na interface do nó. Portanto, todo o tráfego de um pod tem um endereço de origem do nó em que ele reside. Um pod também não pode iniciar a comunicação com blocos de CIDR idênticos usados como endereços alocados de domínio roteado. É dito que os endereços são vinculados à VPC isolada porque sempre se considera que essas sub-redes estejam diretamente conectadas. Esse tráfego nunca é roteado para o gateway de VPC isolada. Esse é um problema de roteamento, não de NAT.

Tráfego originado no domínio roteado que segue até a VPC isolada

O tráfego do domínio roteado é conectado aos pods por meio dos endereços IP do balanceador de carga interno. Esses endereços IP são atribuídos pelo bloco de CIDR de nó alocado de domínio roteado.

Os recursos na rede local que compartilham o mesmo bloco de CIDR dos pods, ou seja, um bloco de CIDR usado como um endereço alocado de domínio roteado e como um endereço reutilizado de VPC isolada, não podem se comunicar com os pods porque os pods veem o intervalo de CIDR como conectado localmente. Os endereços são vinculados ao cluster. A figura a seguir mostra como ocorre a vinculação de endereço.

Endereços IP do balanceador de carga interno vinculados a um cluster. Para uma versão em PDF legível na tela, clique na imagem.
Figura 2. Endereços IP do balanceador de carga interno vinculados a um cluster. Para uma versão em PDF legível na tela, clique na imagem.

Na figura, como o endereço 10.0.0.2 de domínio roteado é considerado parte do espaço de endereço 10.0.0.0/11 do pod na VPC isolada, os seguintes eventos ocorrem:

  1. O tráfego sai do nó Host1 com destino ao nó Host2 com um endereço de origem 10.0.0.2.
  2. O pacote entra no Host2 na VPC isolada conforme o esperado e é processado, mas é vinculado à VPC isolada por um processo chamado buraco negro.
  3. O pacote de resposta com um endereço de destino 10.0.0.2 é roteado incorretamente para um endereço de pod no nó Host3 porque a decisão de roteamento no nó Host2 vê a rede como local. Para evitar esse problema, você precisa selecionar endereços reutilizados de recursos que não precisam se conectar aos pods. Se isso não for possível, use a solução NAT para todos os blocos de CIDR do GKE.

Balanceamento de carga

Com o arquivo de configuração do Serviço do GKE, você disponibiliza os endereços IP do Serviço para o domínio roteado por meio de endereços IPv4 do balanceador de carga interno. Você seleciona esses endereços de balanceamento de carga internos do intervalo de CIDR IPv4 do nó atribuído à sub-rede primária na VPC isolada. Como o bloco de nó é um endereço alocado de domínio roteado, não há outras etapas de configuração.

Outros problemas

O NAT do gateway da camada de aplicativos não é aceito no payload do pacote. Essa solução só se traduz na camada 3.

Outras considerações

Nesta seção, discutiremos outros fatores a serem considerados ao configurar o cluster do GKE.

Gerenciamento de identidade e acesso

Revise os seguintes papéis e procedimentos do IAM e atribua-os conforme as regras da sua organização:

Custo

Com o faturamento ativado para o projeto, o tutorial complementar gera os seguintes custos adicionais (os custos exatos dependem da implementação):

Para ajudar a estimar os custos, use a calculadora de preços do Google Cloud.

Cotas e limites

Lembre-se das seguintes cotas e limites:

APIs

É preciso ativar a API GKE na VPC isolada.

Segurança

Recomendamos que você discuta os seguintes pontos de segurança com sua equipe de rede e segurança:

  • Como a configuração incorreta em cenários de reutilização de endereço pode causar interrupções na rede, configure aliases de e-mail e automação, como ipv4addrspaceviolation@example.com e ipv4routingviolation@example.com, para alertar sobre problemas.
  • Acompanhe traduções de futuras análises de dados.
  • Para garantir que as regras de firewall estejam em conformidade com os padrões estabelecidos, revise toda conexão externa com a Internet com a VPC isolada.
  • Antes de aplicar regras de firewall na produção, revise cada regra.

A seguir