Planeje endereços IP ao migrar para o GKE

Neste documento, descrevemos como gerenciar o uso de endereços IP no Google Kubernetes Engine (GKE) e como usar modelos de rede alternativos no GKE, quando necessário. Este documento abrange os seguintes conceitos:

  • Como reduzir o uso de endereços IP do pod no GKE para que o GKE atenda às necessidades do endereço IP da maioria das organizações.
  • Como modelos de rede alternativos podem ser implementados no GKE quando a arquitetura de cluster padrão não atende aos requisitos da sua organização.

O documento para arquitetos de nuvem, engenheiros de operações e engenheiros de rede que planejam migrar clusters do Kubernetes de outros ambientes para o GKE. Use a orientação neste documento quando sua organização estiver encontrando um desafio para atribuir endereços IP internos suficientes para o uso esperado do 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 há informações sobre estratégias de gerenciamento para o intervalo de endereços usado para endereços IP de serviço. O número de endereços necessários para os serviços é muito menor do que para os pods, e as opções para reduzir esse número são limitadas. No GKE, o intervalo de endereços IP do serviço é fixo durante a vida útil do cluster. Portanto, o intervalo de endereços IP do serviço precisa ser dimensionado para o maior número esperado de serviços. Como os endereços IP do serviço não podem ser acessados fora do cluster, é possível reutilizá-los em outras redes.

Este documento também se refere a diferentes modelos de rede do Kubernetes: totalmente integrado, modo de ilha e isolado. Esses modelos diferem na maneira como os endereços IP do pod podem ser acessados em toda a rede. Essas diferenças têm um impacto nas estratégias de gerenciamento de endereços IP que podem ser usadas. Para informações mais detalhadas sobre esses modelos e o modelo de rede do GKE, consulte Comparação de modelos de rede usados pelo GKE e outras implementações do Kubernetes.

Reduzir o uso de endereços IP internos no GKE

O GKE usa um modelo de rede totalmente integrado onde os clusters são implantados na rede VPC que também pode ter outros aplicativos. O modelo do GKE tem muitos benefícios. No entanto, esse tipo de modelo não permite que os endereços IP do pod sejam reutilizados. Essa falta de reutilização exige que você use endereços IP do pod exclusivos em toda a rede VPC. Portanto, considere cuidadosamente quantos endereços IP exclusivos são necessários.

O número de endereços exclusivos que você precisa influencia se é necessário reduzir o uso de endereços IP, da seguinte maneira:

  • Se você tiver espaço suficiente para as suas necessidades de endereço IP, não precisará necessariamente tomar medidas para reduzir o uso do endereço. No entanto, saber como reduzir o uso do endereço IP é útil para identificar o número mínimo de endereços IP a serem usados.
  • Se não tiver espaço suficiente, reduza o uso do endereço IP para criar clusters do GKE que se ajustem às restrições do espaço de endereço.

Para ajudar a reduzir o uso de endereços IP no GKE, considere as seguintes opções:

  • Altere a configuração de pods por nó. Por padrão, os clusters Padrão do GKE reservam um intervalo de sub-rede /24 para cada nó e permitem até 110 pods por nó. Se você espera usar apenas 64 pods ou menos por nó, é possível ajustar o número máximo de pods por nó e, portanto, reduzir o uso do endereço IP do pod pela metade ou mais de dados. Os clusters do Autopilot permitem 32 pods por nó e essa configuração não pode ser alterada.
  • Use vários intervalos de endereços IP do pod. Com o roteamento entre domínios sem classe multiclasse (CIDR, na sigla em inglês), é possível adicionar intervalos de endereços IP de pod secundários a clusters atuais. É possível selecionar qual intervalo de endereços IP do pod cada pool de nós usa. Selecionar o intervalo de endereços IP usado por cada pool permite que você seja conservador ao alocar o espaço de endereço IP do pod inicial, enquanto ainda aumenta o cluster.

  • Use endereços IP não RFC 1918. Sua rede corporativa pode não ter endereços IP RFC 1918 não alocados suficientes para usar para os endereços IP do pod. Se você não tiver endereços IP RFC 1918 não alocados suficientes, use endereços não RFC 1918, como endereços no espaço de endereço RFC 6598 (100.64.0.0/10).

    Se você já estiver usando o espaço RFC 6598 em outro lugar da rede corporativa, use o espaço de endereço Class E/RFC 5735 (240.0.0.0/4) para endereços IP do pod. No entanto, o tráfego desses endereços IP é bloqueado nos hosts do Windows e em alguns hardwares locais. Para evitar o bloqueio de endereços RFC 5735, mascare o tráfego para esses destinos externos conforme descrito na seção Ocultar endereços IP do pod apenas de redes locais. No entanto, você perde alguns dados de telemetria direcionados a aplicativos locais quando mascara o tráfego para destinos externos.

Se sua organização tiver um grande espaço de endereços IP públicos, também será possível usar endereços públicos (PUPI) de uso particular. Ao usar endereços PUPI, é preciso incluir esses endereços na lista nonMasqueradeCIDRs para ter conectividade fora do cluster sem usar NAT.

Escolher um modelo de rede no GKE

No documento do modelo de rede do GKE, discutimos como os clusters padrão funcionam no GKE, incluindo os endereços IP do pod envolvidos. Neste documento, na seção Reduzir o uso de endereços IP internos no GKE, você verá como reduzir o número de endereços IP internos necessários nesses clusters. Saber como o modelo de rede do GKE funciona e como reduzir endereços IP internos é fundamental para qualquer modelo de rede que você usar no GKE.

No entanto, conhecer e aplicar esses conceitos pode não fornecer uma implementação de rede que atenda às suas necessidades. A árvore de decisão a seguir pode ajudá-lo a decidir como implementar o modelo de rede do GKE que é melhor para você:

Árvore de decisão para estratégias de mitigação de endereços IP no GKE.

A árvore de decisão sempre começa com a criação de clusters do GKE Standard, que são baseados em um modelo de rede totalmente integrado. A próxima etapa na árvore é reduzir o uso de endereços IP aplicando todas as opções descritas neste documento.

Se você tiver reduzido o uso do endereço IP o máximo possível e ainda não tiver espaço de endereço suficiente para os clusters do GKE, será necessário um modelo de rede alternativo. A árvore de decisão ajuda você a decidir qual dos seguintes modelos de rede alternativos usar:

Essa árvore de decisão deve ser usada somente como orientação. De acordo com seu caso de uso específico, ainda é possível preferir outro modelo com base nas vantagens e desvantagens de cada modelo. Muitas vezes, vários modelos são viáveis e você pode escolher qual abordagem se adapta melhor à sua organização.

Em casos raros, os modelos alternativos apresentados na árvore de decisão não atendem às suas necessidades. Nesses casos raros, é possível usar o modelo descrito em Como usar instâncias multi-NIC para ocultar endereços de cluster.

Emular modelos de rede alternativos

Para aproveitar os benefícios do modelo de rede totalmente integrado, recomendamos que você mantenha os clusters do GKE na mesma rede lógica dos outros recursos de nuvem. No entanto, talvez não seja possível seguir essa recomendação. Talvez você não tenha espaço suficiente de endereço IP ou talvez seja necessário ocultar os endereços IP do pod da rede maior da sua organização.

Nesta seção, fornecemos opções para usar o modelo de rede totalmente integrado descrevendo diferentes padrões de arquitetura que imitam vários modelos de rede alternativos no GKE. Esses padrões de arquitetura alternativos criam um modo de operação para o GKE semelhante ao modelo de rede no modo de ilha ou de modo isolado.

Cada padrão de arquitetura alternativa inclui as seguintes informações:

Ocultar endereços IP do pod apenas de redes locais

O padrão de arquitetura em que você oculta endereços IP das redes locais usa uma combinação dos seguintes objetivos de roteamento:

  • Faça com que os clusters do GKE no Google Cloud atribuam endereços IP de pod que são roteados em toda a implantação do Google Cloud.
  • Evite que esses endereços IP sejam roteados sem NAT para recursos locais ou para outros ambientes de nuvem por meio do Cloud VPN ou do Cloud Interconnect.

Esse padrão de arquitetura é normalmente usado com o espaço de endereço IP de classe E/RFC 5735, porque esse espaço inclui muitos endereços IP. Ter tantos endereços IP disponíveis ajuda a acomodar a necessidade de fornecer endereços IP exclusivos a cada pod. No entanto, os endereços IP Classe E/RFC 5735 não podem ser facilmente encaminhados para recursos locais porque muitos fornecedores de hardware de rede bloqueiam esse tráfego.

Em vez de usar o espaço de endereço IP da classe E/RFC 5735, é possível usar endereços IP RFC 1918 ou um conjunto interno de endereços IP não RFC 1918. Se você usar um desses outros conjuntos de endereços IP, determine se há sobreposição de endereços IP entre esses endereços usados para os pods e os endereços usados em redes locais. Se houver sobreposição, verifique se nunca há comunicação entre os clusters que usam esses endereços e os aplicativos locais que usam esses mesmos endereços.

Veja nas etapas a seguir como configurar esse padrão de arquitetura:

  1. Crie um intervalo secundário de endereços IP da sub-rede de pod. Conforme descrito nesta seção, é possível criar esse intervalo de endereços a partir do espaço de classe E/RFC 5735, do espaço RFC 1918 ou de um conjunto interno de endereços IP não RFC 1918. Normalmente, o espaço de classe E/RFC 5735 é usado.
  2. Use rotas divulgadas personalizadas e remova o intervalo de endereços IP do pod das divulgações no Cloud Routers. A remoção desses endereços ajuda a garantir que os intervalos de IP do pod não sejam anunciados pelo Border Gateway Protocol (BGP) para seus roteadores locais.
  3. Crie o cluster do GKE usando o intervalo secundário de endereços IP como o roteamento entre domínios sem classe (CIDR) do pod. É possível usar as estratégias descritas em Reduzir o uso de endereços IP internos no GKE para reduzir o uso de endereços IP.

  4. Adicione os seguintes endereços IP à lista nonMasqueradeCIDRs no agente de mascaramento:

    • O intervalo de endereços IP que você usou para os pods.
    • O intervalo de endereços IP usado para os nós.
    • Outros endereços IP usados apenas no Google Cloud, como os intervalos de endereços IP primários usados no Google Cloud.

    Não inclua os intervalos de endereços IP internos usados em ambientes locais ou em outros ambientes de nuvem. Se você tiver cargas de trabalho do Windows no Google Cloud, mantenha-as em sub-redes separadas e não inclua esses intervalos.

Ao usar as etapas anteriores para configurar esse padrão, você configura seus clusters para ter os seguintes comportamentos:

  • Aja como um modelo de rede totalmente integrado no Google Cloud.
  • Aja como um modelo de rede em modo de ilha ao interagir com redes locais.

Para que esse padrão alternativo emule completamente o modelo de rede no modo ilha, é necessário alterar a lista nonMasqueradeCIDRs no agente de mascaramento para uma lista que contenha apenas os intervalos de endereços IP do nó e do pod do cluster. Fazer essa lista resulta no mascaramento do tráfego fora do cluster para o endereço IP do nó, mesmo dentro do Google Cloud. No entanto, depois de fazer essa alteração, não é possível coletar dados de telemetria no nível do pod na rede VPC.

O diagrama a seguir mostra uma implementação desse padrão de arquitetura:

Diagrama de rede que mostra a implementação de ocultar o endereço IP apenas de redes locais.

O diagrama anterior mostra como ocultar endereços IP do pod de redes externas. Conforme mostrado neste diagrama, os pods no Google Cloud podem se comunicar diretamente entre si, mesmo entre clusters. Essa comunicação de pod é semelhante ao modelo padrão do GKE. Observe que o diagrama também mostra os pods usando endereços no espaço de classe E/RFC 5735.

Para o tráfego enviado fora dos clusters, o diagrama mostra como o NAT de origem (SNAT) é aplicado a esse tráfego quando ele sai do nó. O SNAT é usado quando o tráfego é encaminhado pelo Cloud VPN para aplicativos locais ou por meio do Cloud NAT para aplicativos externos.

Esse padrão de arquitetura usa endereços IP de pod para comunicação no Google Cloud. O tráfego só é mascarado quando direcionado para aplicativos locais ou outros ambientes de nuvem. Não é possível se conectar aos pods diretamente de aplicativos locais, mas pode se conectar a serviços expostos por meio de balanceamento de carga interno.

Ocultar os endereços IP do pod das redes locais tem as seguintes vantagens:

  • Você ainda pode aproveitar o modelo de rede totalmente integrado no Google Cloud, como usar firewalls e coletar dados de telemetria com base nos endereços IP do pod. Além disso, é possível se conectar diretamente aos pods para fins de depuração no Google Cloud.
  • Ainda é possível usar malhas de serviço de vários clusters com endereços IP de pod no Google Cloud.

No entanto, ocultar os endereços IP do pod de redes externas tem as seguintes desvantagens:

  • Não é possível reutilizar intervalos de endereços IP de pod ou de Serviços para diferentes clusters no Google Cloud.
  • Talvez seja necessário gerenciar dois conjuntos diferentes de regras de firewall: um para o tráfego entre redes locais e outro para o tráfego totalmente dentro do Google Cloud.
  • Não é possível ter comunicação direta entre pods em malhas de serviço de vários clusters que abrangem o Google Cloud e seu ambiente local ou de outros provedores de serviços em nuvem. Ao usar o Istio, por exemplo, toda a comunicação precisa acontecer entre os gateways do Istio.

Ocultar endereços IP do pod usando o Private Service Connect

Esse padrão de arquitetura usa o Private Service Connect para ocultar endereços IP do pod. Use esse padrão de arquitetura quando você tiver as seguintes necessidades:

  • Você só precisa expor um número limitado de serviços dos clusters do GKE.
  • Os clusters do GKE podem funcionar de maneira independente e não exigem comunicação de saída para muitos aplicativos na rede corporativa.

O Private Service Connect oferece uma maneira de publicar os serviços que serão consumidos de outras redes. É possível expor os serviços do GKE usando um balanceador de carga de rede de passagem interno e anexos de serviço e consumir esses serviços usando um endpoint de outras redes VPC.

Veja nas etapas a seguir como configurar esse padrão de arquitetura:

  1. Em uma rede VPC separada, crie um cluster do GKE. A rede VPC precisa conter apenas esse cluster.
  2. Para cada serviço do GKE no cluster que precise estar acessível em outros clusters ou aplicativos em outra rede VPC, crie um balanceador de carga de rede de passagem interno com o Private Service Connect.

  3. (Opcional) Se o cluster do GKE precisar de comunicação de saída para alguns aplicativos na rede corporativa, exponha-os publicando serviços pelo Private Service Connect.

    O diagrama a seguir mostra uma implementação desse padrão de arquitetura:

Diagrama de rede que mostra a implementação de ocultar o endereço IP usando o Private Service Connect.

O diagrama anterior mostra como a comunicação dentro e entre clusters no modelo Private Service Connect é semelhante a um modelo de rede isolado. No entanto, a comunicação permitida acontece por meio de endpoints do Private Service Connect em vez de endereços IP públicos. Conforme mostrado neste diagrama, cada cluster tem sua própria rede VPC separada. Além disso, cada rede VPC pode compartilhar o mesmo endereço IP, e cada cluster pode compartilhar o mesmo espaço de endereço IP. Somente pods em um cluster podem se comunicar diretamente entre si.

Para comunicação de fora do cluster, o diagrama mostra como um aplicativo externo pode acessar o cluster por meio de um endpoint do Private Service Connect. Esse endpoint se conecta ao anexo de serviço fornecido pelo produtor de serviços na VPC do cluster. A comunicação entre clusters também passa por um endpoint do Private Service Connect e por um anexo de serviço de um fornecedor de serviços.

O uso do Private Service Connect para ocultar endereços IP do pod tem as seguintes vantagens:

  • Você não precisa planejar endereços IP porque o espaço de endereço IP do cluster do GKE está oculto no restante da rede. Essa abordagem expõe apenas um único endereço IP por serviço à rede VPC consumidora.
  • Proteger seu cluster é mais fácil porque esse modelo define claramente quais serviços são expostos, e somente eles podem ser acessados no restante da rede VPC.

No entanto, o uso do Private Service Connect para ocultar endereços IP do pod tem as seguintes desvantagens:

  • Os pods dentro do cluster não podem estabelecer uma comunicação particular fora do cluster. Os pods só podem se comunicar com serviços públicos (quando os pods têm conectividade com a Internet) ou APIs do Google (usando o Acesso privado do Google). Se os serviços fora do cluster forem expostos por meio do Private Service Connect, os pods também poderão alcançar esses serviços. No entanto, nem todos os provedores de serviços internos criam anexos. Portanto, o uso do Private Service Connect só funciona quando o número desses serviços é limitado aos provedores que fornecem anexos.
  • Os endpoints só podem ser acessados na mesma região do serviço. Além disso, esses endpoints só podem ser acessados pela própria rede VPC conectada, e não por redes VPC com peering ou redes conectadas por meio do Cloud VPN ou do Cloud Interconnect.

Ocultar endereços IP do pod usando o Cloud VPN

Esse padrão de arquitetura usa o Cloud VPN para criar uma separação entre os clusters do GKE e a rede VPC principal. Quando você cria essa separação, a rede resultante funciona de maneira semelhante ao modelo de rede no modo ilha. Assim como o modelo no modo ilha, esse padrão oferece a vantagem de reutilizar os intervalos de endereços IP do pod e do Serviço entre os clusters. A reutilização é possível porque a comunicação com aplicativos fora do cluster usa a SNAT. Os nós usam o SNAT para mapear os endereços IP do pod para o próprio endereço IP do nó antes que o tráfego saia do nó.

Veja nas etapas a seguir como configurar esse modelo:

  1. Em uma rede VPC separada, crie um cluster do GKE. A rede VPC precisa conter apenas esse cluster.

    Para o cluster, use a parte não utilizada da atribuição de endereço IP público para definir dois intervalos de endereços IP: um para pods e outro para serviços. Dimensione esses intervalos de endereços IP com base nas necessidades do maior cluster do GKE que você espera usar. Reserve cada um desses intervalos para uso exclusivo no GKE. Você também reutiliza esses intervalos para todos os clusters do GKE na organização.

    Às vezes, não é possível reservar um intervalo de endereços IP tão grande. Sua organização já pode usar um ou ambos os intervalos de endereços IP do pod e do Services para outros aplicativos. Se o intervalo de endereços IP estiver em uso e não puder ser reservado, verifique se os aplicativos que usam esses endereços IP não precisam se comunicar com o cluster do GKE.

  2. Para o cluster que você acabou de criar, configure a lista nonMasqueradeCIDRs no agente de mascaramento para uma lista contendo os intervalos de endereços IP do nó e do pod. Essa lista faz com que o GKE sempre mascare o tráfego saindo do cluster para o endereço IP do nó, mesmo no Google Cloud.

  3. Use o Cloud VPN para conectar a rede VPC que contém o cluster do GKE à rede VPC atual (principal).

  4. Use rotas divulgadas personalizadas para impedir que a rede VPC do cluster divulgue os intervalos de endereços IP do pod e dos serviços direcionados à rede VPC principal.

  5. Repita as etapas 1 a 4 para os outros clusters do GKE necessários. Para todos os clusters, use os mesmos intervalos de endereços IP para pods e Serviços. No entanto, use endereços IP distintos para cada nó.

  6. Se você tiver conectividade com redes locais por meio do Cloud VPN ou do Cloud Interconnect, use rotas divulgadas personalizadas para divulgar manualmente os intervalos de IP dos nós.

  7. Se você tiver outras redes conectadas à sua rede VPC principal por meio do peering de rede VPC, exporte rotas personalizadas nesses peerings para garantir que os nós do cluster do GKE alcancem as seguintes redes com peering.

O diagrama a seguir mostra uma implementação de como usar o Cloud VPN para ocultar endereços IP do pod:

Diagrama de rede que mostra a implementação de ocultar o endereço IP usando o Cloud VPN.

O diagrama anterior mostra como ocultar endereços IP do pod usando o Cloud VPN, que cria uma abordagem semelhante ao modelo de rede no modo de ilha. Conforme mostrado no diagrama, cada cluster do GKE recebe a própria rede VPC separada. Cada rede tem um espaço de endereço IP de nó que é distinto, mas usa o mesmo espaço de endereço IP do pod. Os túneis do Cloud VPN conectam essas redes VPC entre si e à rede corporativa, e o espaço de IP do pod não é anunciado nas redes VPC que contêm clusters.

Observe no diagrama que apenas os pods em um cluster podem se comunicar diretamente. O nó usa o SNAT para mascarar o espaço de endereço IP do pod ao se comunicar fora do cluster com outro cluster, para a rede corporativa ou para uma rede local conectada. Não é possível acessar os pods diretamente a partir de outros clusters ou da rede corporativa. Somente os serviços de cluster expostos com um balanceador de carga interno podem ser acessados por meio das conexões do Cloud VPN.

O uso do Cloud VPN para ocultar endereços IP do pod tem as seguintes vantagens:

  • Conforme descrito no modelo de rede no modo ilha, é possível reutilizar intervalos de endereços IP de pod e de serviço entre clusters.
  • Os firewalls podem precisar de menos configuração porque os endereços IP do pod não podem ser acessados diretamente da rede VPC principal e das redes conectadas. Portanto, você não precisa configurar regras de firewall explícitas para bloquear a comunicação com os pods.

No entanto, o uso do Cloud VPN para ocultar endereços IP do pod tem as seguintes desvantagens:

  • As mesmas desvantagens mencionadas no modelo de rede no modo ilha se aplicam. Por exemplo, não é possível definir regras de firewall no nível do pod. Também não é possível coletar dados de telemetria no nível do pod na rede VPC principal ou na rede conectada.
  • Em comparação com o modelo de rede padrão do GKE, esse padrão gera custos adicionais provenientes dos custos associados a túneis do Cloud VPN e transferência de dados.
  • O Cloud VPN tem um limite de largura de banda por túnel VPN. Se você atingir esse limite de largura de banda, será possível configurar vários túneis do Cloud VPN e distribuir o tráfego usando vários caminhos de custo igual (ECMP, na sigla em inglês). No entanto, realizar essas ações aumenta a complexidade de configurar e manter a implementação do GKE.
  • Manter as divulgações de rota sincronizadas aumenta a complexidade da criação de clusters. Sempre que você criar novos clusters do GKE, será necessário configurar túneis do Cloud VPN e criar rotas divulgadas personalizadas nesses túneis e aplicativos locais.

Ocultar os endereços IP do pod usando endereços IP públicos usados internamente e o peering de rede VPC

Se sua organização é proprietária de endereços IP públicos não utilizados, é possível usar esse padrão de arquitetura semelhante a um modelo de rede no modo ilha, mas por meio do uso particular desse espaço de endereço IP público de dados. Essa arquitetura é semelhante ao modelo que usa o Cloud VPN, mas usa o peering de rede VPC para criar a separação entre o cluster do GKE e a rede principal.

Veja nas etapas a seguir como configurar esse padrão de arquitetura:

  1. Em uma rede VPC separada, crie um cluster do GKE. A rede VPC precisa conter apenas esse cluster.

    Para o cluster, use a parte não utilizada da atribuição de endereço IP público para definir dois intervalos de endereços IP: um para pods e outro para serviços. Dimensione esses intervalos de endereços IP com base nas necessidades do maior cluster do GKE que você espera usar. Reserve cada um desses intervalos para uso exclusivo no GKE. Você também reutiliza esses intervalos para todos os clusters do GKE na organização.

    Em vez de usar a atribuição de endereço IP público, é possível, teoricamente, usar blocos de endereços IP maiores e não utilizados que pertencem a terceiros. No entanto, recomendamos essa configuração não é possível porque esses endereços IP podem ser vendidos ou usados publicamente a qualquer momento. A venda ou o uso de endereços levou a problemas de segurança e conectividade ao usar serviços públicos na Internet.

  2. Para o cluster que você acabou de criar, configure a lista nonMasqueradeCIDRs no agente de mascaramento para uma lista contendo os intervalos de endereços IP do nó e do pod. Essa lista faz com que o GKE sempre mascare o tráfego saindo do cluster para o endereço IP do nó, mesmo no Google Cloud.

  3. Use o peering de rede VPC para conectar a rede VPC que contém o cluster do GKE à rede VPC atual (principal). Como você não quer que os endereços PUPI sejam trocados nesse modelo, defina a sinalização --no-export-subnet-routes-with-public-ip ao configurar o peering.

  4. Repita as etapas 1 a 3 para os outros clusters do GKE necessários. Para todos os clusters, use o mesmo intervalo de endereços IP para pod e serviços. No entanto, use um endereço IP distinto para cada nó.

  5. Se você tiver conectividade com redes locais por meio do Cloud VPN ou do Cloud Interconnect, use divulgações de rotas personalizadas para divulgar manualmente os intervalos de endereços IP de nós.

O diagrama a seguir mostra uma implementação desse padrão de arquitetura:

Diagrama de rede que mostra a implementação de ocultar endereços IP usando o PUPI e o peering de rede VPC.

O diagrama anterior mostra como ocultar endereços IP usando o peering de rede VPC. Conforme mostrado no diagrama, cada cluster do GKE tem sua própria rede VPC separada. Cada nó tem um espaço de endereço IP de nó distinto, mas usa o mesmo espaço de endereço IP de pod definido no espaço de endereço PUPI da organização. As redes VPC se conectam umas às outras e a aplicativos não Kubernetes no Google Cloud por meio do Peering de redes VPC. O espaço de endereço da PUPI não é anunciado entre os peerings. As redes VPC se conectam à rede corporativa por meio de túneis do Cloud VPN.

Somente pods em um cluster podem se comunicar diretamente entre si. O nó usa o SNAT para mascarar o espaço de IP do pod ao se comunicar fora do cluster com outro cluster, para a rede corporativa ou para uma rede local conectada. Não é possível acessar os pods diretamente de outros clusters ou da rede corporativa. Somente os serviços expostos com um balanceador de carga interno podem ser acessados por meio das conexões de peering de redes VPC.

Esse padrão de arquitetura é semelhante à abordagem do Cloud VPN descrita anteriormente, mas tem as seguintes vantagens em relação a esse padrão:

  • Ao contrário do padrão de arquitetura do Cloud VPN,o peering de rede VPC não tem custos extras para túneis do Cloud VPN ou largura de banda entre ambientes.
  • O Peering de redes VPC não tem limitações de largura de banda e é totalmente integrado às redes definidas pelo software do Google. Assim, o peering de rede VPC pode fornecer uma latência um pouco menor do que o Cloud VPN porque o peering não exige os gateways e o processamento necessários pelo Cloud VPN.

No entanto, o modelo de peering de rede VPC também tem as seguintes desvantagens em relação ao modelo do Cloud VPN:

  • Sua organização requer um espaço de endereço IP público que não seja usado e que seja grande o suficiente para o espaço de endereço IP do pod necessário para o maior cluster do GKE que você espera ter.
  • O peering de rede VPC não é transitivo. Assim, os clusters do GKE conectados por meio do peering de rede VPC à VPC principal não se comunicam diretamente entre si ou com os aplicativos em redes VPC que têm peering com a VPC principal. Você precisa conectar diretamente essas redes pelo peering de rede VPC para ativar a comunicação ou usar uma VM do proxy na rede VPC principal.

Usar instâncias de multi-NIC para ocultar endereços de cluster

Esse padrão de arquitetura consiste nos seguintes componentes e tecnologias para criar um modelo semelhante a um modelo de rede no modo de ilha:

  • Ele usa instâncias do Compute Engine com várias placas de rede (multi-NIC, na sigla em inglês) para criar uma camada de separação entre os clusters do GKE e a rede VPC principal.
  • Ele usa NAT em endereços IP enviados entre esses ambientes.

Use esse padrão quando for necessário inspecionar, transformar ou filtrar o tráfego específico que entra ou sai dos clusters do GKE. Se você precisar fazer esse tipo de inspeção, transformação ou filtragem, use as instâncias implantadas do Compute Engine para executar essas tarefas.

O uso de instâncias multi-NIC para ocultar endereços de cluster tem as seguintes vantagens:

  • O espaço de endereço IP do cluster do GKE fica oculto do restante da rede. Somente um único endereço IP por serviço é exposto à rede VPC consumidora.
  • Os serviços podem ser acessados globalmente, de redes locais conectadas e de redes com peering.

No entanto, o uso de instâncias multi-NIC para ocultar endereços de cluster tem as seguintes desvantagens:

  • Esse modelo é mais complexo de implementar do que outras abordagens porque requer não só a implementação do modelo, mas também a configuração do monitoramento e da geração de registros para as instâncias multi-NIC.
  • As instâncias multi-NIC têm limitações de largura de banda e estão sujeitas aos preços das instâncias de VM.
  • Você precisa gerenciar e fazer upgrade das instâncias de várias NICs.

A seguir