Clusters nativos de VPC

Nesta página, você encontra uma visão geral dos clusters nativos de VPC no Google Kubernetes Engine (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.

Benefícios dos clusters nativos de VPC

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

  • Os endereços de IP do pod são nativamente acessíveis dentro da rede VPC do cluster e 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 usando roteadores Cloud.

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 Cloud SDK Cluster nativo de VPC
Anterior a 1.21.0-gke.1500 API Kubernetes Engine ou Cloud SDK Baseado em rotas

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 três intervalos de endereços IP de sub-rede exclusivos:

  • Ele usa o intervalo de endereços IP primário da sub-rede para todos os endereços IP dos nós.
  • Ele usa um intervalo de endereços IP secundário para todos os endereços IP do pod.
  • Ele usa outro intervalo de endereços IP secundário para todos os endereços de serviço (IP do cluster).

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

Range 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 porque quatro 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 e Intervalo 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) = 2 18 = 262.144 endereços de 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.

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 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. Consulte Intervalos válidos e Intervalos restritos na documentação da nuvem privada virtual para mais informações sobre intervalos de sub-rede válidos.

Consulte Como usar intervalos de endereços IP particulares não RFC 1918 para instruções sobre como ativar o uso desses intervalos.

Consulte Ativar intervalos públicos de endereços IP utilizados de modo particular para instruções sobre o uso desses intervalos em clusters particulares.

Métodos de atribuição de intervalo secundário

É possível atribuir intervalos de endereços IP do pod e intervalos de endereços do Serviço (ClusterIP) a um cluster nativo de VPC usando um destes métodos:

Gerenciado pelo GKE (padrão)

O GKE pode criar e gerenciar os intervalos secundários da sub-rede para você. Ao criar o cluster, você especifica um intervalo CIDR completo ou o tamanho de uma máscara de rede para os pods e Serviços. Por exemplo, é possível especificar 10.1.0.0/16 para pods e 10.2.0.0/20 para Serviços, ou também é possível especificar /16 para pods e /20 para Serviços.

Se você criar o cluster e a sub-rede simultaneamente, os intervalos de endereços IP do pod e do serviço serão gerenciados pelo GKE.

.

Gerenciado pelo usuário

É possível criar os intervalos de endereços IP secundários da sub-rede e, em seguida, criar um cluster que use esses intervalos. Se você criar manualmente os intervalos secundários, é necessário gerenciá-los manualmente.

O menor intervalo de endereços IP que você pode criar é um /28. No entanto, é necessário usar um intervalo grande o suficiente para permitir a criação de pelo menos um nó. 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 de diferentes valores de pods máximos por nó.

Se você esgotar os intervalos de endereços IP dos pods, é necessário criar um novo cluster com intervalos maiores ou recriar os pools de nós depois de diminuir o --max-pods-per-node dos pools de nós.

Como compartilhar intervalos de endereços IP

O intervalo primário, o intervalo secundário do pod e o intervalo secundário dos serviços podem ser compartilhados entre clusters, mas essa não é uma configuração recomendada pelos seguintes motivos:

  • Se você compartilhar o intervalo secundário do pod para dois ou mais clusters nativos de VPC, um cluster poderá usar uma grande parte do intervalo de endereços IP do pod compartilhado, deixando os outros clusters sem IPs suficientes para se expandir.
  • Se você compartilhar o intervalo secundário dos Serviços, os endereços IP do Serviço para clusters poderão se sobrepor. O compartilhamento do intervalo secundário para Serviços não é compatível com o escopo de VPC do Cloud DNS para GKE.

Cada cluster nativo de VPC precisa receber um intervalo de endereços IP secundário para os serviços (intervalo de endereços IP do cluster). Como prática recomendada, crie intervalos de IP secundários em sub-redes, de modo que cada cluster tenha uso exclusivo de dois intervalos secundários: um para seus pods e outro para os Serviços.

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 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 desejada 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

Cada sub-rede precisa ter um intervalo de endereços IP primário. É possível expandir o intervalo de endereços IP primário a qualquer momento, mesmo quando os recursos do Google Cloud usarem a sub-rede. entretanto, não é possível reduzir ou alterar o esquema de endereço de 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.

A tabela a seguir mostra o número máximo de nós que podem ser criados em todos os clusters que usam a sub-rede, considerando o tamanho do intervalo de endereços IP primário da sub-rede.

Intervalo de IP primário da sub-rede Máximo de nós
/29
Tamanho mínimo do intervalo de IP primário de uma sub-rede
4 nós
/28 12 nós
/27 28 nós
/26 60 nós
/25 124 nós
/24 252 nós
/23 508 nós
/22 1.020 nós
/21 2.044 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
/19 8.188 nós
/8
Tamanho máximo do intervalo de IP primário de uma sub-rede
16.777.212 nós

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. Use S para o tamanho da máscara de rede, cujo intervalo válido está entre 8 e 29, inclusive.

    N = 2(32 -S) - 4

  • Calcule o tamanho da máscara de rede, S, necessária para aceitar no máximo 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 8 e 29, inclusive.

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

Planeje cuidadosamente seu intervalo de endereços IP secundário para pods. Embora seja possível substituir o intervalo de endereços IP secundário de uma sub-rede, isso não é compatível porque pode tornar o cluster instável.

No entanto, é possível criar outros intervalos de endereços IP de pod usando CIDR de vários pods descontínuos.

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 considera um número máximo de pods por nó é 110 (o padrão e a maior densidade possível de 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ó 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 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 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 880 pods
/20 4.096 endereços 16 nós 1.760 pods
/19 8.192 endereços 32 nós 3.520 pods
/18 16.384 endereços 64 nós 7.040 pods
/17 32.768 endereços 128 nós 14.080 pods
/16 65.536 endereços 256 nós 28.160 pods
/15 131.072 endereços 512 nós 56.320 pods
/14
é o tamanho padrão do intervalo de IP secundário 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 112.640 pods
/13 524.288 endereços 2.048 nós 225.280 pods
/12 1.048.576 endereços 4.096 nós 450.560 pods
/11
2.097.152 endereços 8.192 nós 901.120 pods
/10
4.194.304 endereços 16.384 nós 1.802.240 pods
/9
O maior intervalo possível de endereços de pod
8.388.608 endereços 32.768 nós 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 que um intervalo de endereços IP secundário de uma sub-rede para pods pode ser compatível:

  1. 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
  2. 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.
  3. 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 × Q em que:

    • N é o número máximo de nós, calculado na etapa anterior;
    • Q é o número de pods por nó.

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 de sub-rede secundário, só é possível substituí-lo quando nenhum recurso do Google Cloud o utiliza. Este intervalo não pode ser alterado, desde que um cluster o use para Serviços (endereços de IP do cluster).

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

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
/27
Menor intervalo de endereços de Serviço possível
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

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.

O Console do Cloud mostra mensagens de erro como as listadas abaixo para indicar que o intervalo dos endereços de IP primários da sub-rede ou o intervalo de endereços de IP do cluster do pod (o endereço de 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 IP livre suficiente para pods.

A seguir