Faça a gestão da migração de endereços IP no GKE

Padrão

---

Este documento descreve como gerir a utilização de endereços IP no Google Kubernetes Engine (GKE) e como usar modelos de rede alternativos no GKE quando necessário. Este documento aborda os seguintes conceitos:

• Como reduzir a utilização de endereços IP de pods no GKE para que o GKE se ajuste às necessidades de endereços IP da maioria das organizações.
• Como os modelos de rede alternativos podem ser implementados no GKE quando a arquitetura do cluster não cumpre os requisitos da sua organização.

Este documento destina-se a arquitetos da nuvem, engenheiros de operações e engenheiros de rede que planeiam migrar clusters do Kubernetes de outros ambientes para o GKE. Use as orientações neste documento quando a sua organização tiver dificuldade em atribuir endereços IP internos suficientes para a utilização esperada do GKE.

Este documento pressupõe que tem conhecimentos sobre o Kubernetes e o respetivo modelo de rede. Também deve estar familiarizado com conceitos de rede, como o endereçamento IP, a tradução de endereços de rede (NAT), as firewalls e os proxies.

Este documento não aborda as estratégias de gestão do intervalo de endereços usado para endereços IP de serviço. O número de moradas necessárias para os serviços é muito inferior ao dos agrupamentos e as opções para reduzir este número são limitadas. No GKE, o intervalo de endereços IP de serviço é fixo durante a duração do cluster. Assim, o intervalo de endereços IP de serviço tem de ser dimensionado para o número de serviços esperado mais elevado. Como os endereços IP de serviço não são acessíveis fora do cluster, pode reutilizar esses endereços noutras redes.

Este documento também se refere a diferentes modelos de rede do Kubernetes: totalmente integrado, modo isolado e isolado. Estes modelos diferem na forma como os endereços IP dos pods podem ser alcançados em toda a rede. Estas diferenças têm um impacto nas estratégias de gestão de endereços IP que podem ser usadas. Para obter informações mais detalhadas sobre estes modelos e o modelo de rede do GKE, consulte o artigo Comparação de modelos de rede usados pelo GKE e outras implementações do Kubernetes.

Nota: quando se fala de diferentes modelos de rede, este documento refere-se aos respetivos efeitos nas redes no local ligadas. Os mesmos conceitos aplicam-se a todas as redes ligadas à nuvem virtual privada (VPC) que contém o seu cluster do GKE através do Cloud VPN ou do Cloud Interconnect, incluindo ligações a outros fornecedores de nuvem.

Reduza a utilização de endereços IP internos no GKE

O GKE usa um modelo de rede totalmente integrado, onde os clusters são implementados numa rede VPC que também pode conter outras aplicações. O modelo do GKE tem muitas vantagens. No entanto, este tipo de modelo não permite a reutilização de endereços IP de pods. Esta falta de reutilização requer que use endereços IP de pods que sejam únicos em toda a rede VPC. Por conseguinte, tem de considerar cuidadosamente quantos endereços IP únicos precisa.

O número de endereços únicos de que precisa influencia a necessidade de reduzir a utilização de endereços IP, da seguinte forma:

• Se tiver espaço de endereços suficiente para as suas necessidades de endereços IP, não tem necessariamente de tomar medidas para reduzir a utilização de endereços IP. No entanto, saber como reduzir a utilização de endereços IP é útil para identificar o número mínimo de endereços IP a usar.
• Se não tiver espaço de endereços suficiente, tem de reduzir a utilização de endereços IP para criar clusters do GKE que se enquadrem nas restrições do seu espaço de endereços.

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

• Altere a definição de pods por nó. Por predefinição, os clusters Standard do GKE reservam um intervalo de /24 sub-redes para cada nó e permitem até 110 pods por nó. Se espera usar apenas 64 ou menos agrupamentos por nó, pode ajustar o número máximo de agrupamentos por nó e, por conseguinte, reduzir a utilização de endereços IP de agrupamentos em metade ou mais. Os clusters do Autopilot permitem 32 pods por nó e não é possível alterar esta definição.
• Use vários intervalos de endereços IP de pods. Ao usar o Classless Inter-Domain Routing (CIDR) de vários agrupamentos descontinuados, pode adicionar intervalos de endereços IP de agrupamentos secundários a clusters existentes. Pode selecionar o intervalo de endereços IP do pod que cada node pool usa. A seleção do intervalo de endereços IP usado por cada conjunto permite-lhe ser conservador ao atribuir o espaço de endereços IP inicial do pod, ao mesmo tempo que continua a poder expandir o cluster.

• Use endereços IP não RFC 1918. A sua rede empresarial pode não ter endereços IP RFC 1918 não atribuídos suficientes para usar nos endereços IP dos pods. Se não tiver endereços IP RFC 1918 não atribuídos suficientes, pode usar endereços não RFC 1918, como endereços no espaço de endereços RFC 6598 (100.64.0.0/10).

  Se já estiver a usar o espaço RFC 6598 noutro local na sua rede empresarial, pode usar o espaço de endereços Classe E/RFC 5735 (240.0.0.0/4) para endereços IP de pods. No entanto, o tráfego destes endereços IP é bloqueado em anfitriões Windows e em algum hardware no local. Para evitar o bloqueio de endereços RFC 5735, considere mascarar o tráfego para estes destinos externos, conforme descrito na secção Oculte os endereços IP dos pods apenas das redes no local. No entanto, perde alguns dados de telemetria direcionados para aplicações no local quando mascara o tráfego para destinos externos.

Se a sua organização tiver um grande espaço de endereços IP públicos, também pode usar endereços públicos usados de forma privada (PUPI). Quando usar endereços PUPI, tem de incluir os endereços PUPI na lista nonMasqueradeCIDRs para ter conetividade fora do cluster sem usar NAT.

Escolha um modelo de rede no GKE

O documento sobre o modelo de rede do GKE aborda o funcionamento dos clusters Standard no GKE, incluindo os endereços IP dos pods envolvidos. Neste documento, a secção Reduza a utilização de endereços IP internos no GKE descreve como reduzir o número de endereços IP internos necessários nesses clusters. Saber como funciona o modelo de rede do GKE e como reduzir os endereços IP internos é fundamental para qualquer modelo de rede que use no GKE.

No entanto, conhecer e aplicar esses conceitos pode não lhe dar uma implementação de rede que satisfaça as suas necessidades. A árvore de decisão seguinte pode ajudar a decidir como implementar o modelo de rede do GKE mais adequado para si:

A árvore de decisão começa sempre com a criação de clusters padrão do GKE baseados num modelo de rede totalmente integrado. O passo seguinte na árvore é reduzir a utilização de endereços IP aplicando todas as opções descritas neste documento.

Se reduziu a utilização de endereços IP o máximo possível e ainda não tem espaço de endereços suficiente para os seus clusters do GKE, precisa de um modelo de rede alternativo. A árvore de decisão ajuda a decidir qual dos seguintes modelos de rede alternativos usar:

• Oculte os endereços IP dos pods apenas das redes no local. Use este modelo quando tiver os seguintes critérios:
  • Não pode usar o espaço RFC 6598 para reduzir a utilização de endereços IP internos.
  • Pode usar o espaço de endereços de classe E/RFC 5735 e ocultar este espaço das redes no local.
• Oculte os endereços IP dos pods através do Private Service Connect. Use este modelo quando tiver os seguintes critérios:
  • Não pode usar o espaço de endereços de classe E/RFC 5735.
  • Os seus clusters não precisam de comunicação privada com os serviços na rede maior.
  • Não precisa de aceder aos seus clusters a partir de regiões que estejam fora da região do cluster.
• Oculte os endereços IP dos pods através da utilização interna de endereços IP públicos e da interligação de redes VPC. Embora raramente seja necessário, use este modelo quando tiver os seguintes critérios:
  • Não pode usar o espaço de endereços de classe E/RFC 5735.
  • Os seus clusters precisam de comunicação privada com os serviços na rede maior.
  • A sua organização foi-lhe atribuído um espaço de endereços IP públicos que não está a ser usado e é suficientemente grande para o seu maior cluster.
• Oculte os endereços IP dos pods através da VPN do Google Cloud. Use este modelo quando os seus clusters não cumprirem nenhum dos outros critérios descritos na árvore de decisão.

Lembre-se de que esta árvore de decisões deve ser usada apenas como orientação. De acordo com o seu exemplo de utilização específico, pode continuar a preferir outro modelo com base nas vantagens e desvantagens de cada modelo. Muitas vezes, existem vários modelos viáveis e pode escolher a abordagem que melhor se adapta à sua organização.

Existem casos raros em que os modelos alternativos apresentados na árvore de decisão não satisfazem as suas necessidades. Para estes casos raros, pode usar o modelo descrito no artigo Usar instâncias com várias NICs para ocultar endereços de cluster.

Emule modelos de rede alternativos

Para tirar partido das vantagens do modelo de rede totalmente integrado, recomendamos que mantenha os seus clusters do GKE na mesma rede lógica que os seus outros recursos na nuvem. No entanto, pode não conseguir seguir esta recomendação. Pode não ter espaço de endereço IP suficiente ou pode ter de ocultar os endereços IP dos pods da rede maior da sua organização.

Esta secção oferece 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. Estes padrões de arquitetura alternativos criam um modo de funcionamento para o GKE semelhante ao modelo de rede no modo de ilha ou ao modelo de rede no modo isolado.

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

• Uma descrição do padrão de arquitetura.

• Um diagrama que mostra como implementar esse padrão.

  Cada diagrama de implementação mostra a utilização de um equilibrador de carga interno. Se não for apresentado um balanceador de carga específico no diagrama, recomendamos que use um balanceador de carga de rede de encaminhamento interno. Se quiser usar vários serviços de back-end, pode usar um Application Load Balancer interno.

• Uma discussão sobre as vantagens e as desvantagens desse padrão.

Oculte endereços IP de pods apenas de redes no local

O padrão de arquitetura em que oculta os endereços IP de redes no local usa uma combinação dos seguintes objetivos de encaminhamento:

• Os clusters do GKE têm de Google Cloud atribuir endereços IP de pods que são encaminhados durante toda a Google Cloud implementação.
• Impedir que estes endereços IP sejam encaminhados sem NAT para recursos nas instalações ou para outros ambientes na nuvem através do Cloud VPN ou do Cloud Interconnect.

Este padrão de arquitetura é usado frequentemente com o espaço de endereços IP de classe E/RFC 5735, uma vez que este espaço inclui muitos endereços IP. A disponibilidade de tantos endereços IP ajuda a satisfazer a necessidade de fornecer endereços IP únicos a cada Pod. No entanto, não é possível encaminhar facilmente os endereços IP de classe E/RFC 5735 para recursos no local, porque muitos fornecedores de hardware de rede bloqueiam este tráfego.

Em vez de usar o espaço de endereços IP de classe E/RFC 5735, pode usar endereços IP RFC 1918 ou um conjunto interno de endereços IP não RFC 1918. Se usar um destes outros conjuntos de endereços IP, determine se existe alguma sobreposição de endereços IP entre os endereços usados para os pods e os endereços usados em redes no local. Se existir sobreposição, certifique-se de que nunca existe comunicação entre clusters que usam esses endereços e as aplicações no local que usam esses mesmos endereços.

Os passos seguintes descrevem como configurar este padrão de arquitetura:

1. Crie um intervalo de endereços IP secundário para a sub-rede do pod. Conforme descrito anteriormente nesta secção, pode criar este 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, é usado o espaço E/RFC 5735.
2. Use rotas anunciadas personalizadas e remova o intervalo de endereços IP do pod dos anúncios nos seus Cloud Routers. A remoção destes endereços ajuda a garantir que os intervalos de IP dos pods não são anunciados através do Border Gateway Protocol (BGP) aos seus routers no local.
3. Crie o cluster do GKE usando o intervalo de endereços IP secundário como o Classless Inter-Domain Routing (CIDR) para o Pod. Pode usar as estratégias descritas no artigo Reduza a utilização de endereços IP internos no GKE para reduzir a utilização de endereços IP.

4. Adicione os seguintes endereços IP à lista nonMasqueradeCIDRs no agente de ocultação:

   • O intervalo de endereços IP que usou para os pods.
   • O intervalo de endereços IP usado para nós.
   • Outros endereços IP que são usados apenas no Google Cloud, como os intervalos de endereços IP principais usados no Google Cloud.

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

Quando usa os passos anteriores para configurar este padrão, configura os seus clusters para terem os seguintes comportamentos:

• Atua como um modelo de rede totalmente integrado em Google Cloud.
• Atuar como um modelo de rede no modo isolado quando interage com redes no local.

Para que este padrão alternativo emule totalmente o modelo de rede no modo isolado, tem de 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. A criação de uma lista deste tipo resulta na ocultação sempre do tráfego fora do cluster para o endereço IP do nó, mesmo dentro do Google Cloud. No entanto, após fazer esta alteração, não pode recolher dados de telemetria ao nível do pod na rede da VPC.

O diagrama seguinte mostra uma implementação deste padrão de arquitetura:

O diagrama anterior mostra como ocultar endereços IP de pods de redes externas. Conforme mostrado neste diagrama, os pods dentro do Google Cloud podem comunicar diretamente entre si, mesmo entre clusters. Esta comunicação Pod é semelhante ao modelo GKE. Tenha em atenção que o diagrama também mostra os pods a usar endereços no espaço Class E/RFC 5735.

Para o tráfego enviado para fora dos clusters, o diagrama mostra como o NAT de origem (SNAT) é aplicado a esse tráfego à medida que sai do nó. A SNAT é usada independentemente de o tráfego ser encaminhado através da Cloud VPN para aplicações no local ou através do Cloud NAT para aplicações externas.

Este padrão de arquitetura usa endereços IP de pods para comunicação dentro Google Cloud. O tráfego só é mascarado quando é direcionado para aplicações nas instalações ou outros ambientes na nuvem. Embora não possa estabelecer ligação aos pods diretamente a partir de aplicações no local, pode estabelecer ligação a serviços expostos através do balanceamento de carga interno.

Ocultar os endereços IP dos pods das redes no local tem as seguintes vantagens:

• Pode continuar a tirar partido do modelo de rede totalmente integrado no Google Cloud, como usar firewalls e recolher dados de telemetria com base nos endereços IP dos pods. Além disso, pode ligar-se diretamente aos Pods para fins de depuração a partir do interior do Google Cloud.
• Pode continuar a usar malhas de serviços de vários clusters com endereços IP de pods em Google Cloud.

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

• Não pode reutilizar intervalos de endereços IP de pods ou serviços para diferentes clusters no Google Cloud.
• Pode ter de gerir dois conjuntos diferentes de regras de firewall: um para o tráfego entre redes no local e outro para o tráfego totalmente dentro do Google Cloud.
• Não pode ter comunicação direta de pod para pod em malhas de serviço de vários clusters que abrangem o Google Cloud e o seu ambiente no local ou de outros fornecedores de serviços na nuvem. Por exemplo, quando usa o Istio, toda a comunicação tem de ocorrer entre gateways do Istio.

Oculte os endereços IP dos pods através do Private Service Connect

Este padrão de arquitetura usa o Private Service Connect para ocultar os endereços IP dos pods. Use este padrão de arquitetura quando tiver as seguintes necessidades:

• Só precisa de expor um número limitado de serviços dos seus clusters do GKE.
• Os seus clusters do GKE podem funcionar de forma independente e não requerem comunicação de saída para muitas aplicações na sua rede empresarial.

O Private Service Connect oferece uma forma de publicar os seus serviços que vão ser consumidos a partir de outras redes. Pode expor os seus serviços GKE através de um Network Load Balancer de passagem interno e de associações de serviços, e consumir estes serviços através de um ponto final de outras redes VPC.

Os passos seguintes descrevem como configurar este padrão de arquitetura:

1. Numa rede VPC separada, crie um cluster do GKE. A rede VPC deve conter apenas esse cluster.
2. Para cada serviço do GKE no seu cluster que precise de ser acessível a partir de outros clusters ou aplicações noutra rede VPC, crie um equilibrador de carga de rede de passagem interno com o Private Service Connect.

3. (Opcional) Se o seu cluster do GKE precisar de comunicação de saída para algumas aplicações na sua rede corporativa, exponha essas aplicações publicando serviços através do Private Service Connect.

   O diagrama seguinte mostra uma implementação deste padrão de arquitetura:

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

Para a comunicação a partir do exterior do cluster, o diagrama mostra como uma aplicação externa pode alcançar o cluster através de um ponto final do Private Service Connect. Esse ponto final liga-se à associação de serviço fornecida pelo produtor de serviços na rede VPC do cluster. A comunicação entre clusters também passa por um ponto final do Private Service Connect e uma associação de serviço de um produtor de serviços.

A utilização do Private Service Connect para ocultar endereços IP de pods tem as seguintes vantagens:

• Não tem de planear endereços IP porque o espaço de endereços IP do cluster do GKE está oculto do resto da rede. Esta abordagem expõe apenas um único endereço IP por serviço à rede VPC de consumo.
• A proteção do cluster é mais fácil porque este modelo define claramente os serviços expostos, e apenas esses serviços expostos podem ser alcançados a partir do resto da rede VPC.

No entanto, a utilização do Private Service Connect para ocultar endereços IP de pods tem as seguintes desvantagens:

• Os pods no interior do cluster não podem estabelecer comunicação privada fora do cluster. Os pods só podem comunicar com serviços públicos (quando os pods têm ligação à Internet) ou APIs Google (através do acesso privado à Google). Se os serviços fora do cluster estiverem expostos através do Private Service Connect, os pods também podem aceder a esses serviços. No entanto, nem todos os fornecedores de serviços internos criam associações de serviços. Assim, a utilização do Private Service Connect só funciona quando o número destes serviços está limitado aos fornecedores que disponibilizam anexos.
• Só é possível aceder aos pontos finais a partir da mesma região em que o serviço se encontra. Além disso, só é possível aceder a estes pontos finais a partir da própria rede VPC ligada e não a partir de redes VPC com intercâmbio ou redes ligadas através do Cloud VPN ou do Cloud Interconnect.

Oculte os endereços IP dos pods através da VPN do Google Cloud

Este padrão de arquitetura usa a Cloud VPN para criar uma separação entre os clusters do GKE e a rede VPC principal. Quando cria esta separação, a rede resultante funciona de forma semelhante ao modelo de rede no modo isolado. Tal como o modelo de modo isolado, este padrão oferece-lhe a vantagem de reutilizar intervalos de endereços IP de pods e serviços entre clusters. A reutilização é possível porque a comunicação com aplicações fora do cluster usa SNAT. Os nós usam SNAT para mapear os endereços IP dos pods para o seu próprio endereço IP do nó antes de o tráfego sair do nó.

Os passos seguintes descrevem como configurar este modelo:

1. Numa rede VPC separada, crie um cluster do GKE. A rede VPC deve conter apenas esse cluster.

   Para o cluster, use a parte não usada da atribuição do seu endereço IP público para definir dois intervalos de endereços IP: um para Pods e outro para Serviços. Dimensionar estes intervalos de endereços IP com base nas necessidades do maior cluster do GKE que espera usar. Reserve cada um destes intervalos para utilização exclusiva no GKE. Também reutiliza estes intervalos para todos os clusters do GKE na sua organização.

   Por vezes, não é possível reservar um intervalo tão grande de endereços IP. A sua organização pode já usar um ou ambos os intervalos de endereços IP de pods e serviços para outras aplicações. Se o intervalo de endereços IP estiver em utilização e não puder ser reservado, certifique-se de que as aplicações que usam esses endereços IP não precisam de comunicar com o cluster do GKE.

2. Para o cluster que acabou de criar, configure a lista nonMasqueradeCIDRs no agente de mascaramento para uma lista que contenha os intervalos de endereços IP dos nós e dos pods do cluster. Esta lista faz com que o GKE mascare sempre o tráfego que sai do cluster para o endereço IP do nó, mesmo dentro deGoogle Cloud.

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

4. Use rotas anunciadas personalizadas para impedir que a rede VPC do cluster anuncie os intervalos de endereços IP dos pods e dos serviços que são direcionados para a sua rede VPC principal.

5. Repita os passos 1 a 4 para os outros clusters do GKE de que precisa. 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 tiver conetividade com redes nas instalações através da Cloud VPN ou do Cloud Interconnect, use rotas anunciadas personalizadas para anunciar manualmente os intervalos de IP dos nós.

7. Se tiver outras redes ligadas à sua rede VPC principal através do intercâmbio das redes da VPC, exporte rotas personalizadas nestes intercâmbios para garantir que os nós do cluster do GKE podem alcançar as redes em intercâmbio.

O diagrama seguinte mostra uma implementação da utilização da Cloud VPN para ocultar endereços IP de pods:

O diagrama anterior mostra como ocultar endereços IP de pods através da VPN na nuvem, que cria uma abordagem semelhante ao modelo de rede no modo isolado. Conforme mostrado no diagrama, cada cluster do GKE tem a sua própria rede VPC separada. Cada rede tem um espaço de endereços IP de nós distinto, mas usa o mesmo espaço de endereços IP de pods. Os túneis da Cloud VPN ligam estas redes VPC entre si e à rede empresarial. Além disso, o espaço de endereços IP dos pods não é anunciado a partir das redes VPC que contêm clusters.

Repare no diagrama que apenas os pods num cluster podem comunicar diretamente entre si. O nó usa o SNAT para ocultar o espaço de endereços IP do pod quando comunica fora do cluster com outro cluster, com a rede corporativa ou com uma rede no local ligada. Não é possível aceder diretamente aos pods a partir de outros clusters ou da rede corporativa. Só é possível aceder aos serviços de cluster expostos com um balanceador de carga interno através das ligações da Cloud VPN.

A utilização da VPN do Google Cloud para ocultar os endereços IP dos pods tem as seguintes vantagens:

• Conforme descrito no modelo de rede de modo isolado, pode reutilizar intervalos de endereços IP de pods e serviços entre clusters.
• As firewalls podem precisar de menos configuração porque não é possível aceder diretamente aos endereços IP dos pods a partir da rede VPC principal e das redes ligadas. Por conseguinte, não precisa de configurar regras de firewall explícitas para bloquear a comunicação com os Pods.

No entanto, a utilização da Cloud VPN para ocultar os endereços IP dos pods tem as seguintes desvantagens:

• Aplicam-se as mesmas desvantagens mencionadas no modelo de rede no modo isolado. Por exemplo, não pode definir regras de firewall ao nível do pod. Também não pode recolher dados de telemetria ao nível do pod na rede VPC principal ou na rede ligada.
• Em comparação com o modelo de rede do GKE predefinido, este padrão gera custos adicionais provenientes dos custos associados aos túneis da VPN Cloud e das taxas de transferência de dados.
• O Cloud VPN tem um limite de largura de banda por túnel de VPN. Se atingir este limite de largura de banda, pode configurar vários túneis de VPN na nuvem e distribuir o tráfego através do caminho múltiplo de custo igual (ECMP). No entanto, a execução destas ações aumenta a complexidade da configuração e manutenção da sua implementação do GKE.
• Manter os anúncios de rotas sincronizados adiciona complexidade à criação de clusters. Sempre que criar novos clusters do GKE, tem de configurar túneis da Cloud VPN e criar rotas anunciadas personalizadas nesses túneis e para aplicações no local.

Oculte os endereços IP dos pods através de endereços IP públicos usados internamente e da interligação de redes VPC

Se a sua organização tiver endereços IP públicos não usados, pode usar este padrão de arquitetura que se assemelha a um modelo de rede no modo isolado, mas através da utilização privada deste espaço de endereços IP públicos. Esta arquitetura é semelhante ao modelo que usa a Cloud VPN mas, em vez disso, usa o VPC Network Peering para criar a separação entre o cluster do GKE e a rede principal.

Os passos seguintes descrevem como configurar este padrão de arquitetura:

1. Numa rede VPC separada, crie um cluster do GKE. A rede VPC deve conter apenas esse cluster.

   Para o cluster, use a parte não usada da atribuição do seu endereço IP público para definir dois intervalos de endereços IP: um para Pods e outro para Serviços. Dimensionar estes intervalos de endereços IP com base nas necessidades do maior cluster do GKE que espera usar. Reserve cada um destes intervalos para utilização exclusiva no GKE. Também reutiliza estes intervalos para todos os clusters do GKE na sua organização.

   Em vez de usar a sua atribuição de endereço IP público, é teoricamente possível usar os blocos de endereços IP públicos maiores e não usados que são propriedade de terceiros. No entanto, desaconselhamos vivamente esta configuração, uma vez que estes endereços IP podem ser vendidos ou usados publicamente em qualquer altura. A venda ou a utilização de endereços originou problemas de segurança e de conetividade quando se utilizam serviços públicos na Internet.

2. Para o cluster que acabou de criar, configure a lista nonMasqueradeCIDRs no agente de mascaramento para uma lista que contenha os intervalos de endereços IP dos nós e dos pods do cluster. Esta lista faz com que o GKE faça sempre o mascaramento do tráfego que sai do cluster para o endereço IP do nó, mesmo dentro do Google Cloud.

3. Use o peering de redes VPC para ligar a rede VPC que contém o cluster do GKE à rede VPC existente (principal). Uma vez que não quer que os endereços PUPI sejam trocados neste modelo, defina a flag --no-export-subnet-routes-with-public-ip ao configurar a interligação.

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

5. Se tiver conetividade com redes nas instalações através da Cloud VPN ou do Cloud Interconnect, use anúncios de rotas personalizadas para anunciar manualmente os intervalos de endereços IP dos nós.

O diagrama seguinte mostra uma implementação deste padrão de arquitetura:

O diagrama anterior mostra como ocultar endereços IP através da interligação de redes VPC. Conforme mostrado no diagrama, cada cluster do GKE tem a sua própria rede VPC separada. Cada nó tem um espaço de endereços IP de nó distinto, mas usa o mesmo espaço de endereços IP de pod que foi definido a partir do espaço de endereços PUPI da sua organização. As redes da VPC ligam-se entre si e a aplicações não Kubernetes emGoogle Cloud através do intercâmbio das redes da VPC. O espaço de endereços PUPI não é anunciado entre os pares. As redes VPC ligam-se à rede empresarial através de túneis do Cloud VPN.

Apenas os pods num cluster podem comunicar diretamente entre si. O nó usa SNAT para ocultar o espaço de IP do pod quando comunica fora do cluster com outro cluster, com a rede corporativa ou com uma rede no local ligada. Não é possível aceder diretamente aos pods a partir de outros clusters ou da rede corporativa. Só é possível aceder aos serviços expostos com um balanceador de carga interno através das ligações de interligação de redes VPC.

Este padrão de arquitetura é semelhante à abordagem da VPN na nuvem descrita anteriormente, mas tem as seguintes vantagens em relação a esse padrão:

• Ao contrário do padrão de arquitetura da VPN na nuvem,o intercâmbio da rede da VPC não acarreta custos adicionais para túneis da VPN na nuvem nem largura de banda entre ambientes.
• O peering de redes VPC não tem limitações de largura de banda e está totalmente integrado nas redes definidas por software da Google. Assim, o peering de redes VPC pode oferecer uma latência ligeiramente inferior à da VPN do Google Cloud, uma vez que o peering não requer os gateways nem o processamento necessários pela VPN do Google Cloud.

No entanto, o modelo de intercâmbio da rede da VPC também tem as seguintes desvantagens em relação ao modelo de Cloud VPN:

• A sua organização requer um espaço de endereços IP públicos que não seja usado e que seja suficientemente grande para o espaço de endereços IP de agrupamentos necessário para o maior cluster do GKE que espera ter.
• O intercâmbio das redes da VPC não é transitivo. Assim, os clusters do GKE ligados através do intercâmbio de redes da VPC à rede da VPC principal não podem comunicar diretamente entre si nem com as aplicações nas redes da VPC que estão em intercâmbio com a VPC principal. Tem de ligar diretamente essas redes através da interligação de redes VPC para ativar essa comunicação ou usar uma VM proxy na rede VPC principal.

Use instâncias com várias NICs para ocultar endereços de clusters

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

• Usa instâncias do Compute Engine com vários cartões de interface de rede (multi-NIC) para criar uma camada de separação entre clusters do GKE e a rede VPC principal.
• Usa NAT em endereços IP enviados entre esses ambientes.

Pode usar este padrão quando precisar de inspecionar, transformar ou filtrar tráfego específico que entra ou sai dos clusters do GKE. Se precisar de fazer este tipo de inspeção, transformação ou filtragem, use as instâncias do Compute Engine implementadas para realizar estas tarefas.

A utilização de instâncias com várias NICs para ocultar endereços de clusters tem as seguintes vantagens:

• O espaço de endereços IP do cluster do GKE está oculto do resto da rede. Apenas um único endereço IP por serviço é exposto à rede VPC de consumo.
• Os serviços podem ser acedidos globalmente a partir de redes locais ligadas e de redes com peering.

No entanto, a utilização de instâncias com várias NICs para ocultar endereços de clusters tem as seguintes desvantagens:

• Este 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 da monitorização e do registo para as instâncias com várias NICs.
• As instâncias com várias NICs têm limitações de largura de banda e estão sujeitas aos preços das instâncias de VM.
• Tem de gerir e atualizar as instâncias com várias NICs.

O que se segue?

• Documento complementar: Comparação dos modelos de rede usados pelo GKE e outras implementações do Kubernetes
• Práticas recomendadas de redes do GKE
• Compare os serviços da AWS e do Azure para Google Cloud
• Migrar contentores para Google Cloud: migrar o Kubernetes para o GKE