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 tarefas de exemplo referenciados no conteúdo do Google Cloud, consulteTarefas e funções de usuário comuns do GKE Enterprise.
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 usaintervalos 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 os arquitetos de rede, administradores de rede ou qualquer outra equipe de engenheiros de rede responsáveis por definir, implementar e manter a arquitetura de rede da sua organização.
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 acessí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 em seu cluster. Isso evita conflito com outros recursos na rede VPC e permite planejar melhor as alocações dos endereços de 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, manipulam 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, na sigla em inglês), só funcionam com clusters nativos de VPC.
Modo de rede padrão do cluster
Nativo de VPC é o modo de rede padrão para todos os clusters nas versões 1.21.0-gke.1500 e posteriores do GKE. Para versões anteriores, o modo de rede padrão do cluster depende de como o cluster é criado.
A tabela a seguir lista o modo de rede padrão do cluster para versões de cluster do GKE e métodos de criação de cluster.
| Versões do GKE | Método de criação do cluster | Modo de rede do cluster |
|---|---|---|
| Todas as versões | Console do Google Cloud | Cluster nativo de VPC |
| 1.21.0-gke.1500 e posterior | API Kubernetes Engine ou Google Cloud CLI | Cluster nativo de VPC |
Também é possível criar um cluster baseado em rotas especificando a sinalização --no-enable-ip-alias ao criar o cluster.
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 usando intervalos distintos na sub-rede especificada, da seguinte maneira.
- Endereços IP 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 IP do pod: o cluster usa o intervalo de endereços IPv4 secundário na sub-rede para todos os endereços IPv4 do pod no cluster. Para maior flexibilidade, use intervalos de endereços IPv4 secundários de sub-rede adicionais ao configurar o CIDR de vários pods descontínuos.
- Endereços IP de serviço: o cluster usa um intervalo de endereços IP secundário separado para todos os endereços de serviço (IP do cluster). Para informações sobre como permitir que vários clusters compartilhem o mesmo intervalo IPv4 de serviços, consulteComo compartilhar intervalos de endereços IP entre clusters do GKE.
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
/96designado 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.
A tabela a seguir mostra um resumo dos intervalos de endereços IP para nós, pods e serviços:
| Intervalo | Explicação | Exemplo |
|---|---|---|
| Nós | Endereços IP de nós são atribuídos a partir do intervalo de endereços de IP primário da sub-rede associada ao seu cluster. Os endereços IP dos nós e o tamanho do intervalo de endereços IP secundários da sub-rede para pods limitam o número de nós que um cluster pode suportar. Consulte intervalos de limite de nós para ver mais informações. | Se você planeja criar um cluster de 900 nós, o intervalo de endereços de IP primário da sub-rede do cluster precisa ser de pelo menos /22 (2(32-22) = 210 = 1.024 endereços). Desses 1.024 endereços, 1.020 são utilizáveis porquequatro endereços IP estão reservados em todos os intervalos de endereços de IP primários. Consulte Intervalo de endereços de IP primários de sub-rede eIntervalo secundário de endereços de IP de sub-redes para pods para ver mais informações. |
| Pods | Os endereços de IP do pod são obtidos do intervalo de endereços de IP secundários da sub-rede do cluster para pods. A menos que você defina um número máximo de pods por nó, o GKE aloca um /24 intervalo de IP de alias com (256 endereços) para cada nó dos pods executados nele. Em cada nó, esses 256 endereços de IP de alias são usados para dar suporte a até 110 pods. | Para um cluster de 900 nós dando suporte a até 110 pods por nó, você precisa de 900 × 256 = 230.400 endereços de IP para pods. (Cada nó recebe um intervalo de IP do alias com tamanho da máscara de rede de /24.) Esse cluster requer uma sub-rede com intervalo de IP secundário para pods com uma máscara de sub-rede não maior que /14. Esse intervalo de IP secundário fornece 2(32-14) = 218 = 262.144 endereços IP para pods. Consulte Intervalo de endereços de IP secundários da sub-rede para pods para ver mais informações. |
| Serviços | Endereços de serviço (IP de cluster) são obtidos do intervalo de endereços de IP secundário da sub-rede do cluster para Serviços. Certifique-se de que esse intervalo seja grande o suficiente para fornecer endereços para todos os Serviços do Kubernetes hospedados no seu cluster. Em clusters do Autopilot do GKE que executam a versão 1.27 e mais recentes, e clusters do GKE Standard que executam a versão 1.29 e mais recentes, o GKE atribui endereços IP para serviços do GKE de um intervalo gerenciado pelo GKE: 34.118.224.0/20 por padrão. Isso elimina a necessidade de especificar seu próprio intervalo de endereços IP para serviços. Para detalhes, consulte Intervalo de endereços IP secundário da sub-rede para Serviços. | Para um cluster que executa até 3.000 Serviços, você precisa de 3.000 endereços de IP de cluster. Você precisa de um intervalo secundário de tamanho /20 ou maior. O intervalo A /20 de endereços de IP resulta em 2 (32-20) = 2 12 = 4.096 endereços de IP. Consulte Intervalo secundário de endereços de IP da sub-rede para Serviços para ver mais informações. |
Endereços IP internos
Os endereços IP 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 IP particulares (RFC 1918 e outros) e endereços IP públicos utilizados de forma particular. ConsulteIntervalos válidos eIntervalos restritos na documentação da VPC para mais informações sobre intervalos de sub-rede válidos.
ConsulteComo usar intervalos de endereços IP particulares não RFC 1918para instruções sobre como ativar o uso desses intervalos.
ConsulteAtivar intervalos de endereços IP públicos usados de modo particularpara instruções sobre o uso desses intervalos.
Métodos de atribuição de intervalo secundário
É 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 à 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 de intervalo usando a flag
--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 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 Como otimizar a alocação de endereços IP 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.
- Recriar os pools de nós depois de diminuir o--max-pods-per-node dos 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 VPC em um ambiente de VPC compartilhada, um proprietário, editor ou Identity and Access Management (IAM) principal com papel de administrador de rede no projeto de host da VPC compartilhada precisa criar sub-redes e intervalos secundários de IP manualmente. Um administrador de projeto de serviços que cria um cluster precisa ter permissão de nível de sub-rede para a sub-rede no projeto host da rede de 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 Configurando 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.
Intervalo do endereço IP primário da sub-rede
Considere as seguintes condições ao planejar o intervalo de endereços IP do nó principal:
- 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.
- Os dois primeiros e os últimos dois endereços IP de um intervalo de 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 essa 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 IP primário da sub-rede e a configuração do cluster:
- Cenário 1:nós máximos 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.
| Intervalo de IP primário da sub-rede | Cenário 1 | Cenário 2 |
|---|---|---|
| /29 Tamanho mínimo do intervalo de IP primário de uma sub-rede | 4 nós | 3 nós |
| /28 | 12 nós | 11 nós |
| /27 | 28 nós | 27 nós |
| /26 | 60 nós | 59 nós |
| /25 | 124 nós | 123 nós |
| /24 | 252 nós | 251 nós |
| /23 | 508 nós | 507 nós |
| /22 | 1.020 nós | 1.019 nós |
| /21 | 2.044 nós | 2.043 nós |
| /20 Tamanho padrão do intervalo de IP primário de uma sub-rede em redes de modo automático | 4.092 nós | 4.091 nós |
| /19 | 8.188 nós | 8.187 nós |
| /8 Tamanho máximo do intervalo de IP primário de uma sub-rede | 16.777.212 nós | 16.777.211 nós |
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ívelExpanda o intervalo de endereços IP primárioa 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 nodes e balanceadores de carga internos.
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, cujo intervalo válido está entre
8e29, inclusive.
N = 2(32 -S) - 4 - Calcule o tamanho da máscara de rede, S, necessária para aceitar no máximoN 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, é entre8e29, inclusive.
Em clusters do Private Service Connect que não usam a flag private-endpoint-subnetwork, é possível usar as fórmulas anteriores, mas reduzir o valor de N em 1.
Intervalo do endereço IP secundário da sub-rede para pods
Planeje cuidadosamente seu intervalo de endereços IP secundário para pods.
A tabela a seguir mostra o número máximo de nós e pods que podem ser criados em todos os clusters que usam a sub-rede, considerando o tamanho do intervalo de endereços IP secundário usado pelos pods.
Esta tabela pressupõe que onúmero máximo de pods por nóé 110, que é a densidade padrão dos pods.
| Intervalo secundário de IP da sub-rede para pods | Máximo de endereços de IP de pod | Máximo de nós | Máximo de pods |
|---|---|---|---|
| /24 é o menor intervalo de IP de pod possível quando o método de atribuição do intervalo secundário é gerenciado pelo usuário | 256 endereços | 1 nó | Autopilot: 32 pods Standard: 110 pods |
| /23 só é possível quando o método de atribuição do intervalo secundário é gerenciado pelo usuário | 512 endereços | 2 nós | Autopilot: 64 pods Standard: 220 pods |
| /22 só é possível quando o método de atribuição do intervalo secundário é gerenciado pelo usuário | 1.024 endereços | 4 nós | Autopilot: 128 pods Standard: 440 pods |
| /21 é o menor intervalo de IP do pod possível quando o método de atribuição do intervalo secundário é gerenciado pelo GKE | 2.048 endereços | 8 nós | Autopilot: 256 pods Standard: 880 pods |
| /20 | 4.096 endereços | 16 nós | Autopilot: 512 pods Standard: 1.760 pods |
| /19 | 8.192 endereços | 32 nós | Autopilot: 1.024 pods Standard: 3.520 pods |
| /18 | 16.384 endereços | 64 nós | Autopilot: 2.048 pods Standard: 7.040 pods |
| /17 | 32.768 endereços | 128 nós | Autopilot: 4.096 pods Standard: 14.080 pods |
| /16 | 65.536 endereços | 256 nós | Autopilot: 8.192 pods Standard: 28.160 pods |
| /15 | 131.072 endereços | 512 nós | Autopilot: 16.384 pods Standard: 56.320 pods |
| /14 é o tamanho padrão do intervalo de endereços IP secundários da sub-rede para pods quando o método de atribuição de intervalo secundário é gerenciado pelo GKE | 262.144 endereços | 1.024 nós | Autopilot: 32.768 pods Standard: 112.640 pods |
| /13 | 524.288 endereços | 2.048 nós | Autopilot: 65.536 pods Standard: 225.280 pods |
| /12 | 1.048.576 endereços | 4.096 nós | Autopilot: 131.072 pods Standard: 450.560 pods |
| /11 | 2.097.152 endereços | 8.192 nós | Autopilot: 262.144 pods Standard: 901.120 pods |
| /10 | 4.194.304 endereços | 16.384 nós | Autopilot: 524.288 pods Standard: 1.802.240 pods |
| /9 O maior intervalo possível de endereços de pod | 8.388.608 endereços | 32.768 nós | Autopilot: 1.048.576 pods Standard: 3.604.480 pods |
Se você alterou o número máximo de pods por nó, é possível usar as seguintes fórmulas para calcular o número máximo de nós e pods a que um intervalo de endereços IP secundário de uma sub-rede para pods pode suportar:
- Calcule o tamanho da máscara de rede do intervalo de pod de cada nó, M.
M = 31 - ⌈log2(Q)⌉em que:- Q é o número de pods por nó;
⌈⌉é a função teto (mínimo de número inteiro), o que significa arredondar para o próximo número inteiro- Por exemplo, se Q for 110,
M = 24
- Calcule o número máximo de nós, N, que o intervalo de endereços IP secundário da sub-rede para pods pode suportar:
N = 2(M - S)em que:- M é o tamanho da máscara de rede do intervalo de endereços IP do alias de cada nó para pods, calculado na primeira etapa.
- S é o tamanho da máscara de sub-rede do intervalo de endereços IP secundário da sub-rede.
- Por exemplo, se M for 24 e S for 20, então
N = 16
- Calcule o número máximo de pods, P, que o intervalo de endereços IP secundário da sub-rede para pods pode suportar:
P = N × Qem que:- N é o número máximo de nós, calculado na etapa anterior;
- Q é o número de pods por nó.
- Por exemplo, se N for 16 e Q for 110, então
P = 1760
É possível adicionar mais endereços IP para pods usando o CIDR de vários pods descontínuos.
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, esse intervalo 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.
Em clusters do Autopilot do GKE 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 os serviços usando a sinalização
--services-ipv4-cidrou--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.
| Intervalo de IP secundário para Serviços | Número máximo de Serviços |
|---|---|
| /28 é o menor intervalo de endereços do serviço possívelquando o método de atribuição do intervalo secundário é gerenciado pelo usuário | 16 serviços |
| /27 é o menor intervalo de endereços do serviço possívelquando o método de atribuição do intervalo secundário é gerenciado pelo GKE | 32 Serviços |
| /26 | 64 Serviços |
| /25 | 128 Serviços |
| /24 | 256 Serviços |
| /23 | 512 Serviços |
| /22 | 1.024 Serviços |
| /21 | 2.048 Serviços |
| /20 É o tamanho padrão para o intervalo de IP secundário da sub-rede para serviços quando o método de atribuição de intervalo secundário é gerenciado pelo GKE | 4.096 Serviços |
| /19 | 8.192 Serviços |
| /18 | 16.384 Serviços |
| /17 | 32.768 Serviços |
| /16 O maior intervalo de endereços de Serviço possível | 65.536 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 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 o GKE.
- Não é possível compartilhar intervalos que correspondam ao seguinte regex:
^gke-.*-services-[abcdef0-9]{8} - Para compartilhar um intervalo de endereços IP secundários 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 de IP primários 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.
Benefícios
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 de clusters nativos de VPC comGKE Dataplane V2 ativado.
- A rede de pilha dupla é compatível apenas com sub-redes em VPCs de modo personalizado. Para mais informações, consulte Tipos de redes VPC do Google Cloud.
- 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 na configuração de 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,NodePorteLoadBalancer. - 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:
| Sinalização ipv6-access-type | Atribuição de endereços IP | Intervalo da sub-rede |
|---|---|---|
| EXTERNAL | O GKE atribui endereços IPv6 externos que são roteáveis para a Internet. | De 2600:1900/28 |
| INTERNAL | O GKE atribui endereços IPv6 internos que não são roteáveis para a Internet. Clusters com tipo de acesso IPv6 INTERNAL não podem acessar a Internet por endereços IPv6. No entanto, o Cloud NAT não é compatível com endereços IPv6. | A partir de fd20::/20, que é um subconjunto do intervalo geral de ULA: fc00::/7. |
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 do 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 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:
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.