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. Um cluster que usa intervalos de IP de alias é chamado de cluster nativo de VPC. Um cluster que usa rotas no Google Cloud é 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 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 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 gerenciam 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 antispoofing ativado. A rede VPC realiza verificações antispoofing que impedem que os nós enviem pacotes com endereços IP de origem arbitrários. O recurso antispoofing está desativado para clusters com base em rotas.
  • Os intervalos de IP do pod e os intervalos de IP secundário da sub-rede, em geral, podem ser compartilhados com redes locais conectadas com o Cloud VPN ou com Cloud Interconnect usando roteadores do Cloud Router.
  • 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 objeto Service (ClusterIP) só estão disponíveis no cluster. Se você precisar acessar um Service do 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 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 Service (IP do cluster).

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

Intervalo Explicação Exemplo
Nós

Endereços IP de nós são atribuídos a partir do intervalo de endereços IP primário da sub-rede associada ao seu cluster.

Os endereços IP dos nós e o tamanho do intervalo de IPs secundário da sub-rede para pods limitam o número de nós que um cluster pode suportar. Consulte intervalos de limitação de nós para mais informações.

Se você planeja criar um cluster de 900 nós, o intervalo de endereços 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 IP primários.

Consulte Intervalo de endereços IP primário de sub-rede e Intervalo de endereços IP secundário de sub-redes para pods para mais informações.

Pods

Os endereços IP do pod são extraídos do intervalo de endereços IP secundário 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 intervalo de IP de alias /24 (256 endereços) para cada nó dos pods executados nele. Em cada nó, esses 256 endereços IP de alias são usados para dar suporte a até 110 pods.

Para um cluster de 900 nós, que dá suporte a até 110 pods por nó, você precisa de 900 × 256 = 230.400 endereços 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 menor ou igual a /14. Esse intervalo de IP secundário fornece 2(32-14) = 218 = 262.144 endereços IP para pods.

Consulte Intervalo de endereços IP secundário da sub-rede para pods para mais informações.

Services

Endereços de Services (IP de cluster) são extraídos do intervalo de endereços IP secundário da sub-rede do cluster para Services. Certifique-se de que esse intervalo seja grande o suficiente para fornecer endereços para todos os Services do Kubernetes hospedados no seu cluster.

Para um cluster que executa até três mil Services, você precisa de três mil endereços IP de cluster. Você precisa de um intervalo secundário de tamanho /20 ou maior. Um intervalo de endereços IP /20 resulta em 2 (32-20) = 212 = 4.096 endereços IP.

Consulte Intervalo secundário de endereços IP da sub-rede para Services para 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 de CIDR completo ou o tamanho de uma máscara de rede para os pods e Services. Por exemplo, é possível especificar 10.1.0.0/16 para pods e 10.2.0.0/20 para Services. Também é possível especificar /16 para pods e /20 para Services.

Se você criar o cluster e a sub-rede simultaneamente, os intervalos de IP do Service 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 criar manualmente os intervalos secundários, você precisará gerenciá-los.

Diferenças de clusters baseados em rotas

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

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 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 pretendida 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 Como configurar 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 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. No entanto, 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 dela. Os dois primeiros e os dois últimos 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 fazer o seguinte:

  • Calcular 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

  • Calcular 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) (em inglês), 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 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 IP secundário de uma sub-rede, isso não é compatível porque pode tornar o cluster 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 que o 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
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
Possível somente quando o método de atribuição do intervalo secundário é gerenciado pelo usuário
512 endereços 2 nós 220 pods
/22
Possível somente 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
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
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
Maior intervalo possível de intervalo 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ó, use 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 Services. 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 objetos Service (endereços 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 esses objetos.

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

Intervalo de IP secundário para Services Número máximo de Services
/27
Menor intervalo de endereços de Service possível
32 Services
/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
Tamanho padrão para o intervalo de IP secundário da sub-rede para Services 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
Maior intervalo de endereços de Service possível
65.536 Serviços

Intervalos de limitação de nós

O número máximo de pods e Services 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.

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

Antes de começar, veja se você realizou as seguintes tarefas:

Defina configurações gcloud padrão usando um dos métodos a seguir:

  • Use gcloud init se você quiser ser orientado sobre como definir padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine.

Como usar o gcloud config

  • 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 Service.

Como criar um cluster em uma sub-rede atual

As instruções a seguir demonstram como criar um cluster nativo de VPC do GKE em uma sub-rede atual 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 outros recursos.

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

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

  6. Escolha uma sub-rede para o cluster no botão pop upSub-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 Service com o intervalo de serviço. Por exemplo, 10.4.0.0/19.

  10. Termine de configurar seu cluster e clique em Criar.

gcloud

  • Para usar um método de atribuição de intervalo secundário de gerenciado 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 gerenciado 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 atual. 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 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 IP secundário da sub-rede para pods.
    • services-ip-range é um intervalo de endereços 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ário da sub-rede para Services.
  • 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 IP secundário atual 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 atual na subnet-name específica. O GKE usa todo o intervalo secundário de IP da sub-rede para os objetos Service 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 atuais 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 quiser 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 de CIDR para pods. Ele 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 de CIDR para objetos Service. 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 Services. 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 estas 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 atual.

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
    

em que:

  • 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 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 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 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 IP secundário 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 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ário da sub-rede para Services. Se omitido, o GKE usa /20, o tamanho padrão do intervalo de IP para Services.

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
      },
      ...
    }
    

O campo createSubnetwork cria e provisiona automaticamente uma sub-rede para o cluster. O campo subnetworkName é opcional. Se for deixado em branco, um nome será automaticamente escolhido para a sub-rede.

Como verificar intervalos de pod e Service

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

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

Como solucionar 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 aparecer novamente 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 o máximo de pods por nó for 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, será possível solucionar o problema se você 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 detalhes sobre os cálculos.

A seguir