Clusters nativos de VPC (original) (raw)

Nesta página, você encontra uma visão geral dos clusters nativos de VPC no Google Kubernetes Engine (GKE).

Esta página é destinada a arquitetos de nuvem e especialistas em redes que projetam e arquitetam a rede para a organização. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulteTarefas e funções de usuário comuns do GKE.

Visão geral

No GKE, os clusters podem ser diferenciados de acordo com a maneira como direcionam o tráfego de um pod para outro.

Um cluster que usa intervalos de endereços IP de alias é chamado de_cluster nativo de VPC_. Um cluster que usa rotas estáticas personalizadas em uma rede VPC é chamado de cluster baseado em rotas.

Prática recomendada:

Planeje e projete a configuração do cluster com arquitetos de rede, administradores de rede ou qualquer outra equipe de engenheiros de rede da organização responsável por definir, implementar e manter a arquitetura de rede.

Benefícios dos clusters nativos de VPC

Os clusters nativos de VPC têm vários benefícios:

• Os endereços IP do pod são nativamente roteáveis na rede VPC do cluster e em outras redes VPC conectadas a ele por peering de rede VPC.
• Os endereços IP do pod são reservados na rede VPC antes de os pods serem criados no cluster. Isso evita conflitos com outros recursos na rede VPC e permite planejar melhor as alocações de endereços IP.
• Os intervalos de endereços IP do pod não dependem de rotas estáticas personalizadas. Eles não consomem a cota de rotas estáticas personalizadas geradas pelo sistema. Em vez disso, as rotas de sub-rede geradas automaticamente gerenciam o roteamento para os clusters nativos de VPC.
• É possível criar regras de firewall que se aplicam apenas aos intervalos de endereços IP do pod em vez de qualquer endereço de IP nos nós do cluster.
• Os intervalos de endereços IP do pod e os intervalos de endereços IP secundários da sub-rede são acessíveis, em geral, em redes locais conectadas com o Cloud VPN ou com o Cloud Interconnect usandoroteadores Cloud.
• Alguns recursos, como grupos de endpoints de rede (NEGs), só funcionam com clusters nativos de VPC.

Modo de rede padrão do cluster

O modo de rede padrão para todos os novos clusters em qualquer versão disponível e criados por qualquer interface, incluindo a Google Cloud CLI,o console Google Cloud ou a API GKE, é o nativo de VPC. Para mais informações sobre as versões disponíveis, consulte Versões atuais.

Se você não quiser usar o modo de rede nativo de VPC recomendado, consulte Como criar um cluster baseado em rotas.

Intervalos de endereços IP para clusters nativos de VPC

Ao criar um cluster nativo de VPC, você especifica uma sub-rede em uma rede VPC. O cluster usa os seguintes intervalos de endereços IP de sub-rede:

Alocação de endereços IPv4

Os clusters nativos de VPC alocam endereços IPv4 para nós, pods e serviços da seguinte maneira.

• Endereços IPv4 do nó: o cluster usa o intervalo de endereços IPv4 principal da sub-rede para atribuir endereços IP a todos os nós.
• Endereços IPv4 do pod: o cluster usa um ou mais intervalos de endereços IPv4 secundários da sub-rede para todos os endereços IPv4 do pod. Esta página se concentra no uso de um único intervalo de endereços IPv4 secundário da sub-rede. Para informações sobre como usar vários intervalos, consulte Adicionar intervalos de endereços IPv4 de pods.
• Endereços IPv4 de serviço: há duas opções disponíveis:
  • Endereços IPv4 de serviço de 34.118.224.0/20: os clusters do GKE Autopilot que executam a versão 1.27 e mais recentes e os clusters do GKE Standard que executam a versão 1.29 e mais recentes usam o intervalo de endereços IPv4 34.118.224.0/20 para serviços. OGoogle Cloud usa o intervalo de endereços 34.118.224.0/20 para fins particulares e não publica rotas na Internet pública para esse intervalo. Não é possível usar esse intervalo para endereços IPv4 externos dos seus recursos.
  • Endereços IPv4 de serviço de um intervalo de endereços IPv4 secundário da sub-rede: para todos os endereços de serviço (ClusterIP), o cluster usa um intervalo de endereços IPv4 secundário da sub-rede diferente dos intervalos usados pelos pods.

Alocação de endereços IPv6 (rede de pilha dupla)

• Endereços IPv6 de nó e pod: em clusters ativados para rede de pilha dupla, o endereço IPv6 do nó e todos os endereços IPv6 do pod são originados do intervalo de endereços IPv6 /96 designado do nó. O endereço IP do nó é o primeiro /128 (endereço IPv6 único) nesse intervalo. Para mais informações, consulte a rede de pilha dupla.
• Endereços IPv6 de serviço: os clusters do GKE usam o intervalo de endereços IPv6 2600:2D00:0:4::0:0/64 para serviços.O Google Cloud usa o intervalo de endereços 2600:2D00:0:4::0:0/64 para fins particulares e não publica rotas na Internet pública para esse intervalo. Não é possível usar esse intervalo para endereços IPv6 externos dos seus recursos.

A tabela a seguir mostra um resumo dos intervalos de endereços IP para nós, pods e serviços:

Endereços IPv4 internos

Os endereços IPv4 que você usa para as sub-redes do cluster nativo de VPC precisam vir de um intervalo de sub-rede válido. Os intervalos válidos incluem endereços IPv4 particulares, como RFC 1918, e endereços IP públicos utilizados de forma particular. Consulte Intervalos válidos eIntervalos restritos na documentação da VPC para mais informações sobre intervalos IPv4 de sub-rede válidos.

Para informações importantes sobre o uso de endereços particulares que não são RFC 1918, consulte Como usar intervalos de endereços IPv4 particulares não RFC 1918.

Para informações importantes sobre o uso de intervalos de endereços IPv4 públicos usados de modo particular, consulte Ativar intervalos de endereços IP públicos usados de modo particular.

Métodos de atribuição de intervalo IPv4 secundário da sub-rede

É possível atribuir intervalos de endereços IP de pod e intervalos de endereços de serviço (ClusterIP) a um cluster nativo de VPC. Esses intervalos de endereços IP podem ser gerenciados pelo GKE ou gerenciados pelo usuário.

Você precisa entender os seguintes termos-chave para entender os métodos de atribuição de intervalo secundário.

Atribuição: a atribuição de intervalos de endereços IP refere-se ao processo de alocação de um intervalo de sub-rede específico para um cluster nativo de VPC. Isso estabelece um pool de endereços IP que os componentes podem usar no cluster, como pods e serviços.

Gerenciamento: gerenciar o intervalo de endereços IP refere-se às operações CRUD contínuas (criação, atualização, exclusão, leitura) no cluster, pool de nós ou pod, relacionadas aos intervalos de sub-rede e à alocação de recursos no cluster nativo de VPC.

Intervalos secundários gerenciados pelo GKE (padrão)

Para clusters do GKE Autopilot que executam a versão 1.27 e mais recentes e clusters do GKE Standard que executam as versões 1.29 e mais recentes, o GKE atribui endereços IP para serviços de um intervalo gerenciado pelo GKE por padrão: 34.118.224.0/20. Isso elimina a necessidade de especificar seu próprio intervalo de endereços IP para serviços. As seguintes considerações se aplicam:

• Opcionalmente, é possível especificar intervalos personalizados para serviços usando a sinalização --services-ipv4-cidr.
• Se você especificar apenas um tamanho usando a sinalização --services-ipv4-cidr (por exemplo, /22), o GKE ainda usará o intervalo gerenciado pelo GKE para obter o subintervalo de endereços.
• Se você especificar apenas um tamanho para o intervalo de endereços IP do pod, por exemplo, --cluster-ipv4-cidr=/17, o GKE selecionará automaticamente um intervalo de endereços IP secundário disponível na sua rede VPC.
• O GKE não cria um intervalo de endereços IP secundário separado para serviços quando o intervalo gerenciado pelo GKE é usado.

Gerenciado pelo usuário

Para controle total sobre a alocação de endereços IP, gerencie manualmente as sub-redes do cluster nativo de VPC.

É possível criar os intervalos de endereços IP secundários da sub-rede e, em seguida, criar um cluster que use esses intervalos. Durante a criação do cluster, especifique o nome do intervalo de sub-rede para pods e serviços. Se você criar manualmente os intervalos secundários, é necessário gerenciá-los manualmente.

O menor intervalo de endereços IP que pode ser criado sem usar o CIDR descontínuo de vários podsé /28, mas esse intervalo só permite criar um nó com no máximo 8 pods. Use um intervalo grande o suficiente para o número máximo de nós necessários.

O intervalo mínimo utilizável depende do número máximo de pods por nó.

Consulte a tabela em Intervalos CIDR de pods em clusters padrão para ver o intervalo utilizável mínimo de CIDR para diferentes valores de pods máximos por nó.

Se você esgotar seu intervalo de endereços IP para pods, será necessário realizar uma das ações a seguir:

• Criar um novo cluster com um intervalo de endereços de pods maior.
• Recrie os pools de nós depois de diminuir o --max-pods-per-nodedos pools de nós.
• Expanda o intervalo de endereços IP secundário do pod usando oCIDR descontínuo de vários pods.

Diferenças de clusters baseados em rotas

O esquema de alocação para endereços de Pod e Serviço (IP do cluster) é diferente do esquema usado por um cluster baseado em rotas. Em vez de especificar um único CIDR para pods e serviços juntos, escolha ou crie dois intervalos de endereços IP secundários na sub-rede do cluster: um para pods e outro para serviços.

Considerações sobre VPC compartilhada

Ao criar um cluster nativo de VPC em um ambiente de VPC compartilhada, um proprietário, editor ou principal do Identity and Access Management (IAM) com a função de administrador de rede no projeto host da VPC compartilhada precisa criar manualmente a sub-rede e os intervalos de endereços IP secundários do cluster. Um administrador de projeto de serviços que cria um cluster precisa ter permissões de nível de sub-rede para a sub-rede no projeto host da rede VPC compartilhada.

Em um ambiente de VPC compartilhada, os intervalos de endereços IP secundários não podem ser gerenciados pelo GKE. Um administrador de rede no projeto de host da VPC compartilhada precisa criar a sub-rede e intervalos de endereços IP secundários antes de criar o cluster. Para ver um exemplo de como configurar um cluster nativo de VPC em uma rede VPC compartilhada, consulte Como configurar clusters com VPC compartilhada.

Planejamento de intervalo de endereços IP

Use as informações nas seções a seguir para calcular os tamanhos dos intervalos de endereços IP primário e secundário da sub-rede usada pelo cluster.

Calculadora de endereços IP do GKE

Use esta calculadora para planejar a alocação de endereços IP para seus clusters nativos de VPC. É possível inserir o número de nós e pods para determinar os tamanhos de prefixo de sub-rede adequados ou inserir os tamanhos de sub-rede para ver o número máximo de nós e pods compatíveis. Essa calculadora aloca intervalos de endereços IP suficientes para evitar o esgotamento à medida que o cluster é dimensionado.

Intervalo de endereços IPv4 principal da sub-rede

Considere o seguinte ao planejar o intervalo de endereços IPv4 principal de uma sub-rede de cluster:

• Cada sub-rede precisa ter um intervalo de endereços IP primário. Esse é o intervalo de endereços IP usado pelo GKE para alocar endereços IP para nodes e balanceadores de carga internos.
• Não é possível reduzir ou alterar o intervalo de endereços IP primário de uma sub-rede após a criação da sub-rede.
• Depois de criar uma sub-rede, é possível expandir o intervalo de endereços IP principal dela, mas não reduzi-lo. Se você expandir uma sub-rede usada por um cluster com redes autorizadas, adicione o intervalo de endereços IP expandido àlista de redes autorizadas do plano de controle. Antes de expandir um intervalo, consulte as limitações e recomendações em Expandir um intervalo IPv4 principal.
• Os dois primeiros e os dois últimos endereços IP de um intervalo de endereços IP primário são reservados para o Google Cloud.
• Os clusters com o Private Service Connect usam o intervalo de sub-rede principal para provisionar o endereço IP interno atribuído ao endpoint do plano de controle. No entanto, é possível substituir esse provisionamento de endereço IP com a flag private-endpoint-subnetwork. Para saber mais, consulte Criar um cluster e selecionar o intervalo de endereço IP do plano de controle.

A tabela a seguir mostra o número máximo de nós que podem ser criados, considerando o tamanho do intervalo de endereços IPv4 primário da sub-rede e a configuração do cluster:

• Cenário 1:número máximo de nós em um cluster que usa a sub-rede padrão.
• Cenário 2:número máximo de nós em um cluster do Private Service Connect que não usa a flag private-endpoint-subnetwork.

Expanda o intervalo de endereços IP primário

Se você ficar sem endereços IP no intervalo de endereços IP principal, será possível expandir o intervalo de endereços IP principal a qualquer momento, mesmo quando os recursos do Google Cloud , como balanceadores de carga e grupos de endpoints de rede, usarem a sub-rede.

Antes de expandir o intervalo de endereços IP primário, considere o seguinte:

• Não pode haver intervalos de endereços IP sobrepostos na sub-rede.
• O GKE usa o intervalo de endereços IP primário para alocar endereços IP para nós e balanceadores de carga internos.
• Se o cluster usar redes autorizadas, adicione o intervalo de endereços IP principal expandido à lista de redes autorizadas.

Fórmulas úteis

É possível usar as seguintes fórmulas para:

• Calcule o número máximo de nós, N, que uma determinada máscara de rede pode suportar em clusters que usam a sub-rede padrão. Use S para o tamanho da máscara de rede, com intervalo válido entre 9 e 29, inclusive.
  N = 2(32 -S) - 4
• Calcule o tamanho da máscara de rede, S, necessária para aceitar um máximo de N nós:
  S = 32 - ⌈log2(N + 4)⌉
  ⌈⌉ é a função teto (mínimo de número inteiro), o que significa arredondar para o próximo número inteiro. O intervalo válido para o tamanho da máscara de rede, S, é entre 9 e 29, inclusive.

Em clusters do Private Service Connect que não usam a flagprivate-endpoint-subnetwork, é possível usar as fórmulas anteriores, mas reduzir o valor de N em 1.

Considerações sobre o dimensionamento do cluster para o intervalo de endereços IP secundário para pods

Para calcular o número máximo de pods que seu cluster pode oferecer suporte, considere o tamanho da sub-rede de pods e o número máximo de pods por nó. O número máximo de pods depende da máscara de sub-rede e do número máximo de pods por nó. Além disso, lembre-se de que alguns endereços IP são reservados no intervalo principal.

Variáveis principais

• Q: o número máximo de pods por nó.
• DS: o tamanho do bloco CIDR selecionado para a sub-rede do pod (por exemplo, /17).
• M: o tamanho da máscara de rede para o intervalo de pod de cada nó.
• HM: o número de bits de host para a máscara de rede do intervalo de pods do nó.
• HD: o número de bits de host para o bloco CIDR da sub-rede do pod.
• MN: o número máximo de nós que podem ser aceitos.
• MP: o número máximo de pods que podem ser compatíveis.
• S: o tamanho do prefixo do intervalo de endereços IP principal da sub-rede.
• N: o número de endereços IP utilizáveis no intervalo de endereços IP principal da sub-rede.

Etapas para calcular o número máximo de pods

1. Determine o número máximo de pods por nó (Q):
   • Para clusters do Autopilot, o valor de Q é fixo em 32.
   • Para clusters padrão, é possível configurar o Q.
2. Defina o tamanho do bloco CIDR para a sub-rede de pods (DS):
   • Determine o tamanho do bloco CIDR selecionado para a sub-rede de pods (por exemplo, /17).
3. Calcule o tamanho da máscara de rede (M):

M = 31 - ⌈log₂(Q)⌉  

Substitua Q pelo valor máximo de pods por nó. Use a função teto (⌈ ⌉) para arredondar para o número inteiro mais próximo. 4. Calcule os bits de host para o intervalo de pods (HM):

HM = 32 - M  

1. Calcule os bits de host para o bloco CIDR selecionado (HD):

HD = 32 - DS  

1. Calcule o número máximo de nós (MN):

MN = 2<sup>(HD - HM)</sup>  

O resultado desse cálculo é o número máximo de nós que a sub-rede de pods selecionada pode suportar. 7. Calcule o número máximo de pods (MP):

MP = MN * Q  

O resultado desse cálculo é o número máximo de pods que o cluster pode suportar. 8. Calcule o número de endereços IP utilizáveis no intervalo principal (N): none N = 2<sup>(32-S)</sup> - 4em que S é o comprimento do prefixo do intervalo CIDR principal da sub-rede.

Observações importantes

• Todos os endereços IP no intervalo secundário podem ser usados para pods.
• Esses cálculos fornecem os máximos teóricos. O desempenho no mundo real pode ser afetado por outros fatores.

Exemplo

Imagine que você esteja criando um cluster do GKE Autopilot com o seguinte:

• Um bloco CIDR de sub-rede de pod de /17 (DS = 17).
• No máximo 32 pods por nó (Q = 32).

Calcule o número máximo de pods:

1. M = 31 - ⌈log₂(32)⌉ = 26
2. HM = 32 - 26 = 6
3. HD = 32 - 17 = 15
4. MN = 2(15 - 6) = 512
5. MP = 512 * 32 = 16,384

Esse cluster pode aceitar no máximo 512 nós e 16.384 pods.

É possível adicionar mais endereços IPv4 para pods adicionando intervalos de endereços IPv4 de pods ou adicionando sub-redes a clusters.

Intervalo do endereço de IP secundário da sub-rede para Serviços

Planeje cuidadosamente seu intervalo de endereços IP secundário para Serviços. Como esse também é um intervalo de endereços IP secundário da sub-rede, ele não pode ser alterado depois da criação do cluster.

Se você usar serviços de vários clusters, o objeto ServiceImport usará endereços IP do intervalo de endereços IP secundários para serviços.

Nos clusters do Autopilot do GKE que executam a versão 1.27 e mais recentes e nos clusters do GKE Standard que executam as versões 1.29 e mais recentes, o GKE atribui endereços IP para serviços de um intervalo gerenciado pelo GKE por padrão: 34.118.224.0/20. Isso reduz a necessidade de especificar seu próprio intervalo de endereços IP para serviços. As seguintes considerações se aplicam:

• Opcionalmente, é possível especificar intervalos personalizados para os serviços usando a sinalização --services-ipv4-cidr ou --services-secondary-range-name.
• Se você especificar apenas um tamanho usando a sinalização --services-ipv4-cidr (por exemplo, /22), o GKE ainda usará o intervalo gerenciado pelo GKE para obter o subintervalo de endereços.
• O GKE não cria um intervalo de endereços IP secundário separado para serviços quando o intervalo gerenciado pelo Google é usado. O intervalo gerenciado pelo GKE não usa a cota do intervalo de endereços IP secundário para sua sub-rede.

A tabela a seguir mostra o número máximo de Serviços que podem ser criados em um único cluster usando a sub-rede, considerando o tamanho do intervalo de endereços de IP secundário da sub-rede para Serviços.

Compartilhamento de intervalos de endereços IP entre clusters do GKE

É possível compartilhar o intervalo primário, o intervalo de endereços IP secundário para pods e o intervalo de endereços IP secundário para Serviços entre clusters na mesma sub-rede. Esse comportamento está disponível para clusters Padrão e Autopilot.

Convém compartilhar intervalos de endereços IP se você tem uma equipe centralizada que gerencia a infraestrutura dos clusters. É possível reduzir a sobrecarga criando três intervalos para pods, Serviços e nós e reutilizando ou compartilhando-os, especialmente em um modelo de VPC compartilhada. Além disso, os administradores de rede podem gerenciar endereços IP mais facilmente, já que não precisam criar sub-redes específicas para cada cluster.

Compartilhamento do intervalo de sub-rede personalizado para o plano de controle

Por padrão, o GKE usa o intervalo de sub-rede principal para provisionar o endpoint interno do plano de controle. No entanto, em clusters com Private Service Connect, é possível configurar o GKE para provisionar o endpoint interno de uma sub-rede diferente que você criou. É possível compartilhar essa sub-rede entre outros clusters ou projetos se você estiver usando a VPC compartilhada.

Compartilhamento do intervalo de endereços IP primário para nós

Se você criar mais de um cluster na sub-rede, o intervalo de endereços IP primário para nós será compartilhado por padrão.

O compartilhamento do endereço IP principal para nós tem estas limitações:

• Se você compartilhar o intervalo de endereços IP primário para nós com dois ou mais clusters nativos de VPC, um cluster poderá usar uma grande parte do intervalo de endereços IP compartilhado, deixando os outros clusters sem endereços IP suficientes para se expandir.

Quando você compartilha o intervalo secundário para pods, cada pod ainda recebe um endereço IP exclusivo.

O compartilhamento do intervalo de endereços IP secundário para pods tem estas limitações:

• Se você compartilhar o intervalo de endereços IP secundário para pods com dois ou mais clusters nativos de VPC, um cluster poderá usar uma grande parte do intervalo de endereços IP compartilhado, deixando os outros clusters sem endereços IP suficientes para se expandir.
• Entre os diferentes tipos de intervalos secundários, os gerenciados pelo GKE e outros intervalos do pod não são compartilháveis entre clusters.
• Para compartilhar um intervalo de endereços IP secundários, transmita-o na linha de comando com--cluster-secondary-range. Não é possível usar um intervalo secundário compartilhado ao criar clusters na UI.

Dois ou mais clusters podem usar simultaneamente o mesmo intervalo de endereços IPv4 secundário da sub-rede para serviços quando você usa intervalos secundários gerenciados pelo usuário.

Para configurar dois ou mais clusters para compartilhar um intervalo de endereços IPv4 secundário comum da sub-rede para serviços, use o mesmo intervalo de endereços IPv4 secundário da sub-rede ao criar cada cluster. Não é necessário um sinalizador de configuração separado para compartilhar um intervalo de endereços IPv4 comum para serviços.

Ao compartilhar um intervalo de endereços IPv4 comum para serviços, cada cluster usa o intervalo de endereços IPv4 secundário da sub-rede para serviços internamente. Os endereços IP para serviços são programados no nó de cada cluster, mas não são atribuídos à interface de rede de nenhum nó. Os endereços IP de serviço não podem ser roteados na rede VPC do cluster. Os endereços IP de serviço só podem ser usados por pods de cliente no mesmo cluster do serviço.

Quando um pod envia um pacote para um endereço IP de serviço, a configuração iptables ou eBPF no nó executa a conversão de endereços de rede (NAT, na sigla em inglês) de destino, alterando o endereço IP de destino do pacote do endereço IP de serviço para um endereço IP de pod de serviço. O pacote é roteado com base no endereço IP do pod de destino.

O compartilhamento do intervalo de endereços IP secundário para Serviços oferece estes benefícios:

• Reduzir o número de intervalos de endereços IP secundários exclusivos para Serviços criados em uma sub-rede
• Usar menos endereços IP

O compartilhamento do intervalo de endereços IP secundário para Serviços tem estas limitações:

• O compartilhamento do intervalo de endereços IP secundário para Serviços não é compatível com o Cloud DNS com escopo da VPC para GKE.
• Não é possível compartilhar intervalos que correspondam à seguinte expressão regular:

^gke-.*-services-[abcdef0-9]{8}  

• Para compartilhar um intervalo de endereços IP secundário para serviços, transmita-o na linha de comando com --cluster-secondary-range. Não é possível usar um intervalo secundário compartilhado para serviços ao criar clusters na UI.

Intervalos de limitação de nós

O número máximo de pods e serviços para um determinado cluster do GKE é limitado pelo tamanho dos intervalos secundários do cluster. O número máximo de nós no cluster é limitado pelo tamanho do intervalo de endereços IP primário da sub-rede do cluster e do intervalo de endereços do pod do cluster.

A mensagem de erro a seguir indica que o intervalo de endereços IP principal da sub-rede ou o intervalo de endereços IP do pod do cluster (o intervalo de endereços IP secundário da sub-rede para pods) foi esgotado:

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

Adicione mais endereços IP para nós expandindo a sub-rede principal ou adicione novos endereços IP para pods usando CIDR de vários pods descontínuos. Para mais informações, consulte Não há espaço de endereço IP livre suficiente para pods.

Rede de pilha dupla IPv4/IPv6

Com a rede de pilha dupla IPv4/IPv6, é possível definir como o GKE aloca endereços IP (ipFamilies) para os seguintes objetos:

• Para pods e nós, o GKE aloca os endereços IPv4 e IPv6.
• Para os serviços, o GKE aloca endereços de pilha única (somente IPv4 ou IPv6) ou de pilha dupla.

Na versão 1.24 do GKE ou posterior, é possível ativar a rede de pilha dupla para novos clusters do GKE em redes VPC independentes e compartilhadas. Também é possível aplicar políticas de rede com rede de pilha dupla ativada. Se você encontrar erros de validação ao ativar a rede de pilha dupla nos clusters do GKE que foram atualizados das versões 1.24 para 1.25 ou 1.26, entre em contato com a Google Cloud equipe de suporte.

Vantagens

A rede de pilha dupla oferece os seguintes benefícios:

• Ativa a comunicação de IPv6 de ponta a ponta.
• Melhor desempenho em comparação com a conversão de endereços de rede (NAT) ou o encapsulamento de IP. Isso é possível porque não há conversão do IPv6 para o IPv4.

Disponibilidade

A rede de pilha dupla com o GKE tem as seguintes restrições:

• A rede de pilha dupla está disponível apenas para clusters nativos de VPC com o GKE Dataplane V2 ativado.
• A rede de pilha dupla é compatível apenas com sub-redes em VPCs de modo personalizado. Para mais informações, consulte Google Cloud tipos de redes VPC.
• Endereços IPv6 de pilha única para pods ou nós não são compatíveis.
• Os clusters de pilha dupla consomem mais memória por nó para aceitar IPv4 e IPv6 em comparação com clusters IPv4 apenas. Considere essa característica ao configurar clusters de grande escala.
• Os clusters de pilha dupla não são compatíveis com o Acesso privado do Google via IPv6.
• As versões 1.26.0-gke.2200 e posteriores do GKE são compatíveis com IPv6 (registros AAAA) com o Cloud DNS para operações internas do cluster e consultas DNS externas.
• Os serviços de pilha dupla são compatíveis com os serviços ClusterIP, NodePort e LoadBalancer.
• O IPv6 não é compatível com nós do Windows.

Considere as restrições anteriores antes de criar um cluster com rede de pilha dupla. Para mais informações, saiba como criar um cluster nativo de VPC com rede de pilha dupla.

Atribuição de endereços IPv6 públicos e privados

A tabela a seguir traz um resumo de endereços IPv6 público e particular com comportamento e configurações de rede de pilha dupla:

Para saber mais, consulte como usar uma rede de pilha dupla em um cluster nativo de VPC.

Arquitetura

Um cluster com rede de pilha dupla IPv4/IPv6 tem os seguintes intervalos alocados:

• Um intervalo /64 para cada sub-rede como um intervalo principal.
• Um intervalo /96 por nó do intervalo principal para usar como um intervalo de endereços IP do nó principal.
• Um intervalo /112 por nó do intervalo de endereços IP do nó principal para usar como intervalo de endereços IP do pod para esse nó. Com a rede de pilha dupla, os pods recebem os endereços IPv6 do intervalo de endereços IP geral do pod (semelhante aos nós), e não de um intervalo secundário para pods reservados para endereços IPv4.
  O intervalo geral de endereços IP do pod é composto por intervalos não sobrepostos do intervalo de endereços IP do nó principal. Portanto, esse intervalo de IP do pod é descontínuo.
• Um intervalo /112 para usar para serviços. Ele vem de um intervalo /64 do intervalo de endereços particulares do Google que foi reservado para o intervalo de endereços IP secundário dos serviços do GKE.

O diagrama a seguir mostra como o Google Cloud e o GKE alocam endereços IPv6:

Alocação de endereços IPv6 no GKE.

No diagrama, o intervalo principal da sub-rede VPC é 2600:1900:0:1::/64 e o intervalo reservado para os serviços do GKE é 2600:2D00:0:4::0:0/64. Cada nó no cluster tem um intervalo /96 para o intervalo de endereços IP do nó principal e um intervalo /112 para o intervalo de endereços IP do pod. O cluster também tem um intervalo de endereços IP secundário de /112 serviços.

Serviços

É possível criar um serviço de pilha dupla IPv4/IPv6 do tipo ClusterIP ou NodePort. Os novos clusters do GKE que executam a versão 1.29 ou mais recente são compatíveis com serviços de pilha dupla do tipoLoadBalancer.

É possível expor uma implantação com um serviço do tipo ClusterIP, NodePort ou LoadBalancer. Para cada um desses tipos de serviço, é possível definir os campos ipFamilies e ipFamilyPolicy como IPv4, IPv6 ou como um serviço de pilha dupla. Para mais informações, consulte um exemplo de como configurar uma implantação.

A seguir

• Saiba mais sobre o peering de rede VPC.
• Aprenda a criar um cluster nativo de VPC.
• Saiba mais sobre os insights de utilização de endereços IP do GKE.