Como criar um cluster nativo de VPC

Nesta página, você aprende a configurar clusters nativos de VPC no Google Kubernetes Engine.

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. O cluster que usa intervalos de IP de alias é chamado de cluster nativo de VPC. Um cluster que usa o Google Cloud Routes é chamado de cluster baseado em rotas .

Benefícios de 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 IPs de 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 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 IP do pod em vez de qualquer endereço de IP nos nós do cluster.
  • Os nós em um cluster nativo de VPC têm o anti-spoofing ativado. A rede VPC realiza verificações anti-spoofing que impedem que os nós enviem pacotes com endereços de IP de origem arbitrários. (O recurso anti-spoofing está desativado para clusters com base em rotas.)
  • Os intervalos de IP do pod e os intervalos de IP secundários da sub-rede, em geral, podem ser compartilhados com redes locais conectadas com o Cloud VPN ou com Cloud Interconnect usando roteadores Cloud.
  • Os intervalos de IP do alias permitem que os pods acessem os serviços hospedados de forma direta, sem usar um gateway NAT.

Restrições

  • Não é possível converter um cluster nativo de VPC em um cluster baseado em rotas, assim como não é possível converter um cluster baseado em rotas em um cluster nativo de VPC.

  • Os clusters nativos de VPC exigem redes VPC. Redes legadas não são compatíveis.

  • Como acontece com qualquer cluster do GKE, os endereços do Serviço (IP do cluster) só estão disponíveis no cluster. Se você precisar acessar um Serviço Kubernetes a partir de instâncias de VM fora do cluster, mas dentro da rede e região de VPC do cluster, crie um balanceador de carga TCP/UDP interno.

Intervalos de 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 IP de sub-rede exclusivos:

  • Ele usa o intervalo de IP primário da sub-rede para todos os endereços de IP dos nós.
  • Ele usa um intervalo de IP secundário para todos os endereços de IP do pod.
  • Ele usa outro intervalo de 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:

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 de IP dos nós e o tamanho do intervalo de IPs 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.

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

É possível atribuir intervalos de IP do pod e intervalos de endereços do Service (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 IP do Serviço e do pod serão gerenciados pelo GKE.

Gerenciado pelo usuário

É possível criar os intervalos de IP secundários da sub-rede e, em seguida, criar um cluster que use esses intervalos. Se você criar manualmente os intervalos secundários, gerencie-os manualmente.

Diferenças de clusters com base 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 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 membro IAM com função 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 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 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 IP

Use as informações nas seções a seguir para calcular os tamanhos dos intervalos de 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 de 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, com intervalo válido entre 8 e 29, inclusive.

    N = 2(32 -S) - 4

  • Calcule o tamanho da máscara de rede S necessária para suportar 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 IPs secundário para pods. Embora seja possível substituir o intervalo de endereços de IP secundários de uma sub-rede, isso não é compatível porque pode colocar o cluster em um estado instável.

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
O maior intervalo possível de endereços de pod
2.097.152 endereços 8.192 nós 901.120 pods

Se você alterou o número máximo de pods por nó, pode usar as seguintes fórmulas para calcular o número máximo de nós e pods compatíveis com o intervalo de IP secundário de uma sub-rede para pods:

  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 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 IP do alias de cada nó para pods, calculado na primeira etapa
    • S é o tamanho da máscara de sub-rede do intervalo de IP secundário da sub-rede
  3. Calcule o número máximo de pods, P, que o intervalo de 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 IP secundário para Serviços. Como esse também é um intervalo de IP secundário da sub-rede, 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).

Ao contrário dos intervalos de IP do nó e do pod, cada cluster precisa ter um intervalo de IP de sub-rede secundário exclusivo para os 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

Antes de começar

Prepare-se para a tarefa seguindo essas etapas:

  • Verifique se você ativou a API do Google Kubernetes Engine.
  • Ativar a API do Google Kubernetes Engine
  • Verifique se o SDK do Cloud está instalado.
  • Defina o ID do projeto padrão:
    gcloud config set project [PROJECT_ID]
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão:
    gcloud config set compute/region [COMPUTE_REGION]
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Procedimentos

Use os procedimentos a seguir para criar um cluster nativo de VPC e verificar os intervalos de IP do pod e do Serviço.

Como criar um cluster em uma sub-rede existente

As instruções a seguir demonstram como criar um cluster nativo de VPC do GKE em uma sub-rede existente com a opção do método de atribuição de intervalo secundário.

Console

As etapas a seguir criam um cluster usando o console do Cloud.

  1. Acesse o menu do Google Kubernetes Engine no console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Clique em Criar cluster.

  3. Configure o cluster como quiser. Em seguida, clique em disponibilidade, rede, segurança e recursos adicionais.

  4. Na seção VPC nativo, verifique se Ativar VPC-nativo (usando IP de alias) está selecionado.

  5. Escolha um VPC no botão pop-up de Rede.

  6. Escolha uma sub-rede para o cluster no botão pop up da sub-rede do nó.

  7. Marque Criar intervalos secundários automaticamente se quiser que o método de atribuição do intervalo secundário seja gerenciado pelo GKE. Desmarque essa caixa se já tiver criado intervalos secundários para a sub-rede escolhida e quiser que o método de atribuição do intervalo secundário seja gerenciado pelo usuário.

  8. Preencha o campo Intervalo de endereços do pod com o intervalo de pod (por exemplo: 10.0.0.0/14).

  9. Preencha o campo Intervalo de endereços do serviço com o intervalo de serviço. (por exemplo: 10.4.0.0/19).

  10. Faça outras seleções de configuração para seu cluster e clique em Criar.

gcloud

  • Para usar um método de atribuição de intervalo secundário degerenciado pelo GKE:

    gcloud container clusters create CLUSTER_NAME \
      --region=REGION \
      --enable-ip-alias \
      --subnetwork=SUBNET_NAME \
      --cluster-ipv4-cidr=POD_IP_RANGE \
      --services-ipv4-cidr=SERVICES_IP_RANGE
    
  • Para usar um método de atribuição de intervalo secundário de gerenciados pelo usuário:

    gcloud container clusters create CLUSTER_NAME \
      --region=REGION \
      --enable-ip-alias \
      --subnetwork=SUBNET_NAME \
      --cluster-secondary-range-name=SECONDARY_RANGE_PODS \
      --services-secondary-range-name=SECONDARY_RANGE_SERVICES
    

Substitua os marcadores por valores válidos:

  • CLUSTER_NAME é o nome do cluster do GKE
  • REGION é a região em que o cluster foi criado. Para criar um cluster zonal, substitua essa sinalização por --zone=ZONE, em que ZONE é uma zona do Google Cloud.
  • SUBNET_NAME é o nome de uma sub-rede existente. O intervalo de IP primário da sub-rede é usado para os nós. A sub-rede precisa estar na mesma região utilizada pelo cluster. Se omitido, o GKE tentará usar uma sub-rede na rede VPC default na região do cluster.
  • Se o método de atribuição do intervalo secundário for gerenciado pelo GKE:
    • POD_IP_RANGE é um intervalo de endereços de IP na notação CIDR (por exemplo, 10.0.0.0/14) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /14). Isso é usado para criar o intervalo de endereços de IP secundários da sub-rede para pods.
    • SERVICES_IP_RANGE é um intervalo de endereços de IP na notação CIDR (por exemplo, 10.4.0.0/19) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /19). Isso é usado para criar o intervalo de endereços IP secundários da sub-rede para Serviços.
  • Se o método de atribuição do intervalo secundário for gerenciado pelo usuário:
    • SECONDARY_RANGE_PODS é o nome de um intervalo de endereços de IP secundário existente na SUBNET_NAME específica. O GKE usa todo o intervalo secundário de IP da sub-rede para os pods do cluster.
    • SECONDARY_RANGE_SERVICES é o nome de um intervalo de endereços IP secundário existente na SUBNET_NAME específica. O GKE usa todo o intervalo secundário de IP da sub-rede para os Serviços do cluster.

API

Ao criar um cluster nativo de VPC, você define um objeto IPAllocationPolicy. É possível se referir a intervalos de IP secundários de sub-redes existentes ou especificar blocos CIDR. Refira-se a intervalos de IP secundários da sub-rede existente para criar um cluster com método de atribuição de intervalo secundário que seja gerenciado pelo usuário. Forneça blocos CIDR se desejar que o método de atribuição de intervalos seja gerenciado pelo GKE.

{
  "name": [CLUSTER_NAME],
  "description": [DESCRIPTION],
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

Em que:

  • "clusterIpv4CidrBlock" é o tamanho/local do intervalo CIDR para pods. Determina o tamanho do intervalo secundário de pods e pode ser IP/tamanho em notação CIDR (como 10.0.0.0/14) ou /tamanho (como /14). Um espaço vazio com o tamanho especificado é escolhido do espaço disponível na VPC. Se deixado em branco, um intervalo válido será encontrado e criado com um tamanho padrão;
  • "servicesIpv4CidrBlock" é o tamanho/local do intervalo CIDR para Serviços. Veja a descrição de "clusterIpv4CidrBlock";
  • "clusterSecondaryRangeName" é o nome do intervalo secundário de pods. É obrigatório que o intervalo secundário já exista e pertença à sub-rede associada ao cluster (como a sub-rede especificada com a sinalização --subnetwork);
  • "serviceSecondaryRangeName" é o nome do intervalo secundário para Serviços. O intervalo secundário já precisa existir e pertencer à sub-rede associada ao cluster (como a sub-rede especificada pela sinalização --subnetwork).

Como criar um cluster e uma sub-rede simultaneamente

As instruções a seguir demonstram como criar um cluster e uma sub-rede do GKE nativo de VPC ao mesmo tempo. O método de atribuição de intervalo secundário é gerenciado pelo GKE quando você executa essas duas etapas com um comando.

Console

Não é possível criar um cluster e uma sub-rede simultaneamente usando o Console do Cloud. Em vez disso, primeiro crie uma sub-rede e depois crie o cluster em uma sub-rede existente.

gcloud

Para criar um cluster nativo e uma sub-rede VPC simultaneamente:

gcloud container clusters create CLUSTER_NAME \
    --region=REGION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

--create-subnetwork name=my-subnet,range=/21

  • CLUSTER_NAME é o nome do cluster do GKE
  • REGION é a região em que o cluster foi criado. Para criar um cluster zonal, substitua essa sinalização por --zone=ZONE, em que ZONE é uma zona do GKE.
  • SUBNET_NAME é o nome da sub-rede a ser criada. A região da sub-rede é a mesma região do cluster (ou a região que contém o cluster zonal). Use uma string vazia (name="") se quiser que o GKE gere um nome para você.
  • NODE_IP_RANGE é um intervalo de endereços de IP na notação CIDR (por exemplo, 10.5.0.0/20) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /20). Isso é usado para criar o intervalo de endereços de IP principais da sub-rede para nós. Se omitido, o GKE escolhe um intervalo de IP disponível na VPC com um tamanho de /20.
  • POD_IP_RANGE é um intervalo de endereços de IP na notação CIDR (por exemplo, 10.0.0.0/14) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /14). Isso é usado para criar o intervalo de endereços de IP secundários da sub-rede para pods. Se omitido, o GKE usa /14, o tamanho padrão do intervalo de IP para pod.
  • SERVICES_IP_RANGE é um intervalo de endereços de IP na notação CIDR (por exemplo, 10.4.0.0/19) ou o tamanho da máscara de sub-rede de um bloco CIDR (por exemplo, /19). Isso é usado para criar o intervalo de endereços IP secundários da sub-rede para Serviços. Se omitido, o GKE usa /20, o tamanho padrão do intervalo de IP para Serviços.

API

Para criar um cluster nativo de VPC, defina um objeto IPAllocationPolicy no recurso do cluster:

{
  "name": [CLUSTER_NAME],
  "description": [DESCRIPTION],
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": [SUBNET_NAME]
  },
  ...
}

createSubnetwork cria e provisiona automaticamente uma sub-rede para o cluster. subnetworkName é opcional. Se ficar vazio, um nome será escolhido automaticamente para a sub-rede.

Verificação de intervalos de pod e Serviços

Depois de criar um cluster nativo de VPC, é possível verificar os intervalos de pod e Serviço.

gcloud

Para verificar o cluster, execute o seguinte comando:

gcloud container clusters describe [CLUSTER_NAME]

Na saída do comando, observe o campo ipAllocationPolicy:

  • clusterIpv4Cidr é o intervalo secundário de pods.
  • servicesIpv4Cidr é o intervalo secundário de serviços.

Console

Para verificar o cluster, siga estas etapas:

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Selecione o cluster pretendido.

Os intervalos secundários são exibidos na seção Cluster sob a guia Detalhes:

  • O intervalo de endereços do contêiner é o intervalo secundário dos pods
  • O intervalo de endereços de serviço é o intervalo secundário dos Serviços

Solução de problemas

Nesta seção há orientações para resolver problemas relacionados a clusters nativos de VPC.

O recurso "projects/[PROJECT_NAME]/regions/XXX/subnetworks/default" não está pronto

Causas possíveis
Há operações paralelas na mesma sub-rede. Por exemplo, outro cluster nativo de VPC está sendo criado ou um intervalo secundário está sendo adicionado ou excluído na sub-rede.
Resolução
Repetir o comando.

Valor inválido para o campo "resource.secondaryIpRanges [1].ipCidrRange": "XXX". IPCidrRange inválido: XXX está em conflito com a sub-rede "padrão" atual na região "XXX".

Causas possíveis

Outro cluster nativo de VPC está sendo criado ao mesmo tempo e está tentando alocar os mesmos intervalos.

O mesmo intervalo secundário está sendo adicionado à sub-rede.

Resolução

Se esse erro reaparecer na criação do cluster, quando nenhum intervalo secundário foi especificado, tente executar novamente o comando de criação do cluster.

Não há espaço de IP suficiente para os pods

Sintomas

O cluster está preso em um estado de provisionamento por um longo período de tempo

A criação de cluster retorna um erro do grupo de instâncias gerenciadas (MIG)

Novos nós não podem ser adicionados a um cluster existente

Causas possíveis

O espaço disponível no intervalo de IP do pod não é grande o suficiente para os nós solicitados no cluster. Por exemplo, se o intervalo de IP de um cluster tiver uma máscara de rede com tamanho de /23 (512 endereços) e pods máximos por nó de 110, você não poderá criar mais de dois nós. (Cada nó recebe um intervalo de IP do alias com uma máscara de rede com tamanho de /24.)

Soluções

Crie um cluster substituto depois de analisar e planejar os intervalos de IP primário e secundário de tamanho adequado. Consulte Intervalos de IP para clusters nativos de VPC e Planejamento de intervalo de IP.

Se não for possível substituir o cluster, você poderá solucionar o problema se criar um novo pool de nós com um número máximo de pods por nó. Se possível, transfira as cargas de trabalho para esse pool de nós e, em seguida, exclua o pool de nós anterior. Reduzir o número máximo de pods por nós permite suportar mais nós em um intervalo de IP secundário fixo para pods. Consulte Intervalo secundário de endereços IP da sub-rede para pods e Intervalos de limitação de nós para ver detalhes sobre os cálculos.

A seguir