Configurar clusters com a VPC compartilhada

Autopilot Standard

Neste guia, você verá como criar dois clusters do Google Kubernetes Engine (GKE) em projetos separados que usam uma VPC compartilhada. Para ver informações gerais sobre a rede do GKE, acesse a Visão geral da rede.

Nos exemplos deste guia, configuramos a infraestrutura para um aplicativo da Web de dois níveis, conforme descrito em Visão geral da VPC compartilhada.

Por que usar a VPC compartilhada com o GKE

Com a VPC compartilhada, você designa um projeto como host e pode anexar outros a ele, os chamados projetos de serviço. É preciso criar redes, sub-redes, intervalos de endereços secundários, regras de firewall e outros recursos de rede no projeto host. Em seguida, você compartilhará as sub-redes selecionadas, incluindo intervalos secundários, com os projetos de serviço. Os componentes em execução em um projeto de serviço podem usar a VPC compartilhada para se comunicar com componentes em execução nos outros projetos de serviço.

É possível usar a VPC compartilhada com clusters do Autopilot e com os clusters padrão zonal e regional.

Os clusters padrão que usam a VPC compartilhada não podem usar redes legadas e precisam ter o roteamento de tráfego nativo de VPC ativado. Os clusters do Autopilot sempre ativam o roteamento de tráfego nativo da VPC.

É possível configurar a VPC compartilhada ao criar um novo cluster. O GKE não é compatível com a conversão de clusters atuais no modelo de VPC compartilhada.

Com a VPC compartilhada, aplicam-se determinadas cotas e limites. Por exemplo, há uma cota para o número de redes em um projeto e há um limite para o número de projetos de serviço que podem ser anexados a um projeto host. Para detalhes, consulte Cotas e limites.

Antes de começar

Antes de começar a configurar um cluster com a VPC compartilhada:

• Verifique se você tem uma organização doGoogle Cloud .
• Verifique se sua organização tem três Google Cloud projetos.
• Confira se você conhece os conceitos de VPC compartilhada incluindo os vários papéis do Identity and Access Management (IAM) usados pela VPC compartilhada. As tarefas deste guia precisam ser realizadas por um administrador de VPC compartilhada.
• Verifique se você conhece as restrições de políticas da organização aplicáveis organização, pasta ou projetos. Um administrador de política da organização pode ter restrições definidas que limitam quais projetos podem ser host da VPC compartilhada ou que limitam quais sub-redes podem ser compartilhadas. Consulte as restrições da política da organização para mais informações.

Antes de executar os exercícios neste guia:

• Escolha um dos seus projetos para ser o projeto host.
• Escolha dois projetos para serem de serviço.

Cada projeto tem um nome, um ID e um número. Em alguns casos, o nome e o ID são iguais. Neste guia, são usados os seguintes nomes intuitivos e marcadores para se referir aos projetos:

Nome amigável	Marcador do ID do projeto	Marcador do número do projeto
Seu projeto host	HOST_PROJECT_ID	HOST_PROJECT_NUM
Seu primeiro projeto de serviço	SERVICE_PROJECT_1_ID	SERVICE_PROJECT_1_NUM
Seu segundo projeto de serviço	SERVICE_PROJECT_2_ID	SERVICE_PROJECT_2_NUM

Observação: o primeiro e o segundo projetos de serviço não designam uma ordem. Os termos "primeiro" e "segundo" são usados apenas para distinguir um projeto do outro.

Encontrar os números e IDs de projetos

Encontre o ID e os números do projeto usando a CLI gcloud ou o console Google Cloud .

Console

1. Acesse a página Início do console do Google Cloud .

   Voltar à página inicial

2. No seletor de projeto, selecione aquele que você escolheu para ser o host.

3. Em Informações do projeto, você verá o nome, o ID e o número do projeto. Anote o ID e o número para mais tarde.

4. Faça o mesmo para cada um dos projetos que você escolheu como projetos de serviço.

gcloud

Liste seus projetos com o seguinte comando:

gcloud projects list

A saída mostra os nomes, IDs e números dos projetos. Anote o ID e o número para mais tarde:

PROJECT_ID        NAME        PROJECT_NUMBER
host-123          host        1027xxxxxxxx
srv-1-456         srv-1       4964xxxxxxxx
srv-2-789         srv-2       4559xxxxxxxx

Ative a API GKE nos seus projetos

Antes de continuar com os exercícios deste guia, verifique se a API GKE está ativada em todos os três projetos. Ativar a API em um projeto cria uma conta de serviço do GKE para o projeto. Para executar as tarefas restantes neste guia, cada um dos seus projetos precisa ter uma conta de serviço do GKE.

É possível ativar a API do GKE usando o console Google Cloud ou a Google Cloud CLI.

Console

1. Acesse a página APIs e serviços no console Google Cloud .

   Acessar APIs e serviços

2. No seletor de projeto, selecione aquele que você escolheu para ser o host.

3. Se a Kubernetes Engine API estiver na lista de APIs, ela já está ativada e você não precisa fazer nada. Caso contrário, clique em Ativar APIs e serviços. Pesquise por Kubernetes Engine API. Clique no cartão API Kubernetes Engine e em Ativar.

4. Repita essas etapas para cada projeto que você escolheu para ser um projeto de serviço. Cada operação pode levar algum tempo para ser concluída:

gcloud

Ative a API do GKE para os três projetos. Cada operação pode levar algum tempo para ser concluída:

gcloud services enable container.googleapis.com --project HOST_PROJECT_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_1_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_2_ID

Criar uma rede e duas sub-redes

Nesta seção, você realizará as seguintes tarefas:

1. No projeto host, crie uma rede chamada shared-net.
2. Crie duas sub-redes chamadas tier-1 e tier-2.
3. Para cada sub-rede, crie dois intervalos de endereços secundários: um para serviços e outro para pods.

Observação: os intervalos de endereços secundários para pods, serviços e nós não podem se sobrepor a 172.17.0.0/16 e precisam seguir os padrões e limites para tamanhos de intervalos.

Console

1. Acesse a página Redes VPC no console do Google Cloud .

   Acessar redes VPC

2. No seletor de projeto, selecione o projeto host.

3. Clique em Criar rede VPC.

4. Em Nome, insira shared-net.

5. Em Modo de criação de sub-rede, selecione Personalizado.

Adicionar tier-1

1. Em Sub-redes na caixa Nova sub-rede, em Nome, insira tier-1.
2. Em Região, selecione uma região.
3. Em Tipo de pilha de IP, selecione IPv4 (pilha única).
4. Em Intervalo IPv4, insira 10.0.4.0/22 como o intervalo de endereços principal da sub-rede.

5. Clique em Adicionar um intervalo de IPv4 secundário.

   • Em Nome do intervalo da sub-rede, insira tier-1-services.
   • Em Intervalo IPv4 secundário, insira 10.0.32.0/20.

6. Clique em Concluído.

7. Clique em Adicionar um intervalo de IPv4 secundário.

   • Em Nome do intervalo da sub-rede, insira tier-1-pods.
   • Em Intervalo IPv4 secundário, insira 10.4.0.0/14.

8. Clique em Concluído.

Adicionar tier-2

1. Clique em Add subnet.
2. Em Nome, insira tier-2.
3. Em Região, selecione a mesma região selecionada para a sub-rede anterior.
4. Em Intervalo IPv4, insira 172.16.4.0/22 como o intervalo de endereços principal da sub-rede.

5. Clique em Adicionar um intervalo de IPv4 secundário.

   • Em Nome do intervalo da sub-rede, insira tier-2-services.
   • Em Intervalo IPv4 secundário, insira 172.16.16.0/20.

6. Clique em Concluído.

7. Clique em Adicionar um intervalo de IPv4 secundário.

   • Em Nome do intervalo da sub-rede, insira tier-2-pods.
   • Em Intervalo IPv4 secundário, insira 172.20.0.0/14.

8. Clique em Concluído.

9. Role até a parte de baixo da página e clique em Criar.

gcloud

No projeto host, crie uma rede chamada shared-net:

gcloud compute networks create shared-net \
    --subnet-mode custom \
    --project HOST_PROJECT_ID

Na sua nova rede, crie uma sub-rede chamada tier-1:

gcloud compute networks subnets create tier-1 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 10.0.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-1-services=10.0.32.0/20,tier-1-pods=10.4.0.0/14

Crie outra sub-rede chamada tier-2:

gcloud compute networks subnets create tier-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 172.16.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

Substitua COMPUTE_REGION por uma região do Compute Engine.

Determinar os nomes das contas de serviço nos projetos de serviço

Você tem dois projetos de serviço, cada um com várias contas de serviço. Esta seção está relacionada às suas contas de serviço do GKE e às suas contas de serviço das APIs do Google. Você precisa dos nomes dessas contas de serviço para a próxima seção.

Na tabela a seguir, listamos os nomes das contas de serviço do GKE e das APIs do Google nos dois projetos de serviço:

Tipo de conta de serviço	Nome da conta de serviço
GKE	[e-mail]
	[e-mail]
APIs do Google	[e-mail]
	[e-mail]

Ativar a VPC compartilhada e conceder papéis

Para realizar as tarefas nesta seção, você precisa ser um administrador de VPC compartilhada. Se você não for um administrador de VPC compartilhada, peça a um administrador da organização que conceda a você os papéis de administrador de VPC compartilhada do Compute (compute.xpnAdmin) e administrador de IAM do projeto (resourcemanager.projectIamAdmin) na organização ou em uma ou mais pastas.

Nesta seção, você realizará as seguintes tarefas:

1. No projeto host, ative a VPC compartilhada.
2. Anexe seus dois projetos de serviço ao projeto host.
3. Remova ou conceda o papel Compute Network User às contas de serviço que pertencem aos seus projetos de serviço. Se você estiver usando o console Google Cloud , remova a função. Se estiver usando a CLI gcloud, conceda a função.

Console

1. Acesse a página VPC compartilhada no console do Google Cloud .

   Acessar VPC compartilhada

2. No seletor de projeto, selecione o projeto host.

3. Clique em Configurar VPC compartilhada. A tela Ativar projeto host será exibida.

4. Clique em Ativar e continuar. A seção Anexar projetos de serviço e selecionar principais é exibida.

5. Em Acesso ao Kubernetes Engine, selecione Ativado.

6. Em Selecionar projetos para anexar, clique em Adicionar item.

7. No campo Selecionar projeto, clique em Selecionar e escolha seu primeiro projeto de serviço.

8. Clique em Adicionar item novamente e selecione o segundo projeto de serviço.

9. Clique em Continuar. A seção Conceder acesso é exibida.

10. Em Modo de acesso, selecione Acesso individual à sub-rede.

11. Em Sub-redes com acesso individual, role a lista e selecione tier-1 e tier-2.

12. Clique em Salvar. Uma nova página é exibida.

13. Selecione Mostrar apenas sub-redes com políticas individuais do IAM.

Remover contas de serviço de tier-1

1. Em Acesso individual à sub-rede, selecione tier-1 e clique em Mostrar painel de permissões.
2. No painel de permissões, em Função/principal, expanda Usuário de rede do Compute.
3. Pesquisar por SERVICE_PROJECT_2_NUM.
4. Exclua todas as contas de serviço que pertencem ao segundo projeto de serviço. Ou seja, exclua as contas de serviço que contenham SERVICE_PROJECT_2_NUM.

5. Confirme se as seguintes contas de serviço do seu primeiro projeto de serviço estão na lista com o papel Usuário da rede do Compute:

   • [e-mail]
   • [e-mail]
   • [e-mail]

   Se uma conta de serviço não estiver na lista, faça o seguinte para adicioná-la:

   1. Clique em Adicionar principal.
   2. No campo Novos principais, insira o nome da conta de serviço.
   3. Em Atribuir papéis, selecione Usuário da rede do Compute.
   4. Clique em Salvar.

6. Em Acesso individual à sub-rede, desmarque a caixa de seleção tier-1.

Remover contas de serviço de tier-2

1. Em Acesso individual à sub-rede, selecione tier-2.
2. No painel de permissões, em Função/principal, expanda Usuário de rede do Compute.
3. Pesquisar por SERVICE_PROJECT_1_NUM.
4. Exclua todas as contas de serviço que pertencem ao primeiro projeto de serviço. Ou seja, exclua todas as contas de serviço que contenham SERVICE_PROJECT_1_NUM.

5. Confirme se as seguintes contas de serviço do segundo projeto de serviço estão na lista com o papel Usuário da rede do Compute:

   • [e-mail]
   • [e-mail]
   • [e-mail]

   Se uma conta de serviço não estiver na lista, faça o seguinte para adicioná-la:

   1. Clique em Adicionar principal.
   2. Digite o nome da conta de serviço no campo Novos principais.
   3. Em Atribuir papéis, selecione Usuário da rede do Compute.
   4. Clique em Salvar.

gcloud

1. Ative a VPC compartilhada no projeto host. O comando usado depende do papel administrativo necessário que você tem.

   Se você tiver o papel Administrador de VPC compartilhada no nível da organização:

   gcloud compute shared-vpc enable HOST_PROJECT_ID
   

   Se você tiver o papel de Administrador de VPC compartilhada no nível da pasta:

   gcloud beta compute shared-vpc enable HOST_PROJECT_ID
   

2. Anexe o primeiro projeto de serviço ao projeto host:

   gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \
       --host-project HOST_PROJECT_ID
   

3. Anexe o segundo projeto de serviço ao projeto host:

   gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \
       --host-project HOST_PROJECT_ID
   

4. Consiga a política do IAM para a sub-rede tier-1:

   gcloud compute networks subnets get-iam-policy tier-1 \
      --project HOST_PROJECT_ID \
      --region COMPUTE_REGION
   

   A resposta contém um campo etag. Anote o valor etag.

5. Crie um arquivo chamado tier-1-policy.yaml que tenha o seguinte conteúdo:

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

   Substitua ETAG_STRING pelo valor de etag que você anotou anteriormente.

6. Defina a política do IAM para a sub-rede tier-1:

   gcloud compute networks subnets set-iam-policy tier-1 \
       tier-1-policy.yaml \
       --project HOST_PROJECT_ID \
       --region COMPUTE_REGION
   

7. Consiga a política do IAM para a sub-rede tier-2:

   gcloud compute networks subnets get-iam-policy tier-2 \
       --project HOST_PROJECT_ID \
       --region COMPUTE_REGION
   

   A resposta contém um campo etag. Anote o valor etag.

8. Crie um arquivo chamado tier-2-policy.yaml que tenha o seguinte conteúdo:

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

   Substitua ETAG_STRING pelo valor de etag que você anotou anteriormente.

9. Defina a política do IAM para a sub-rede tier-2:

   gcloud compute networks subnets set-iam-policy tier-2 \
       tier-2-policy.yaml \
       --project HOST_PROJECT_ID \
       --region COMPUTE_REGION
   

Gerenciar recursos de firewall

Se você quer que um cluster do GKE em um projeto de serviço crie e gerencie os recursos de firewall no seu projeto host, a conta de serviço do GKE do projeto de serviço precisa receber as permissões de IAM apropriadas usando uma das estratégias a seguir:

Observação: para seguir as práticas recomendadas de segurança, escolha a abordagem mais refinada. Para os fins deste guia, o papel Administrador de segurança do Compute vai conceder mais permissões do IAM que o necessário à conta de serviço do GKE do projeto de serviço.

• Conceda à conta de serviço do GKE do projeto de serviço o papel Compute Security Admin para o projeto host.

Console

1. No console do Google Cloud , acesse a página IAM.

   Acessar o IAM

2. Selecione o projeto host.

3. Clique em Conceder acesso e insira o principal da conta de serviço do GKE do projeto de serviço, [e-mail].

4. Selecione o papel Compute Security Admin na lista suspensa.

5. Clique em Salvar.

gcloud

Conceda à conta de serviço do GKE do projeto de serviço o papel Compute Security Admin no projeto host:

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:[e-mail] \
    --role=roles/compute.securityAdmin

Substitua:

• HOST_PROJECT_ID: o ID do projeto host da VPC compartilhada
• SERVICE_PROJECT_NUM: o ID do projeto de serviço que contém a conta de serviço do GKE

• Para uma abordagem mais precisa, crie um papel de IAM personalizado que inclua apenas as seguintes permissões: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update e compute.firewalls.delete. Conceda à conta de serviço do GKE do projeto de serviço que atribui o papel personalizado ao projeto host.

Console

Crie um papel personalizado no projeto host que tenha as permissões do IAM mencionadas anteriormente:

1. No Google Cloud console, acesse a página Papéis.

   Acessar a página "Papéis"

2. Usando a lista suspensa na parte superior da página, selecione o projeto host.

3. Clique em Criar papel.

4. Insira um Título, uma Descrição, um ID e a Fase de lançamento do papel para o papel. Após a criação do papel, não é possível alterar o nome dele.

5. Clique em Adicionar permissões.

6. Filtre por compute.networks e selecione as permissões do IAM mencionadas acima.

7. Depois de selecionar todas as permissões necessárias, clique em Adicionar.

8. Clique em Criar.

Conceda à conta de serviço do GKE do projeto de serviço o papel personalizado recém-criado no projeto host:

1. No console do Google Cloud , acesse a página IAM.

   Acessar o IAM

2. Selecione o projeto host.

3. Clique em Conceder acesso e insira o principal da conta de serviço do GKE do projeto de serviço, [e-mail].

4. Filtre e selecione o Título do papel personalizado recém-criado.

5. Clique em Salvar.

gcloud

1. Crie um papel personalizado no projeto host que tenha as permissões do IAM mencionadas anteriormente:

   gcloud iam roles create ROLE_ID \
       --title="ROLE_TITLE" \
       --description="ROLE_DESCRIPTION" \
       --stage=LAUNCH_STAGE \
       --permissions=compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete \
       --project=HOST_PROJECT_ID
   

2. Conceda à conta de serviço do GKE do projeto de serviço o papel personalizado recém-criado no projeto host:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
   

   Substitua:

   • ROLE_ID: o nome do papel, como gkeFirewallAdmin
   • ROLE_TITLE: um título intuitivo para o papel, como GKE Firewall Admin
   • ROLE_DESCRIPTION: uma breve descrição do papel, como GKE service account FW permissions
   • LAUNCH_STAGE: a fase de lançamento do papel no ciclo de vida, como ALPHA, BETA ou GA
   • HOST_PROJECT_ID: o ID do projeto host da VPC compartilhada
   • SERVICE_PROJECT_NUM: o ID do projeto de serviço que contém a conta de serviço do GKE

Se você tiver clusters em mais de um projeto de serviço, precisará escolher uma das estratégias e repeti-la para cada conta de serviço do GKE do projeto de serviço.

Observação: se você estiver usando o Ingress para balanceadores de carga de aplicativo internos, o controlador do Ingress não criará uma regra de firewall para permitir conexões dos proxies do balanceador de carga na sub-rede proxy. Crie essa regra de firewall manualmente. No entanto, o controlador de entrada cria regras de firewall para permitir a entrada nas verificações de integridade do Google Cloud .

Resumo dos papéis concedidos em sub-redes

Veja um resumo dos papéis concedidos nas sub-redes:

Conta de serviço	Papel	Sub-rede
[e-mail]	Usuário da rede do Compute	tier-1
[e-mail]	Usuário da rede do Compute	tier-1
[e-mail]	Usuário da rede do Compute	tier-2
[e-mail]	Usuário da rede do Compute	tier-2

Verificar o acesso ao GKE

Ao anexar um projeto de serviço, a ativação do acesso do GKE concede à conta de serviço do GKE do projeto as permissões para executar operações de gerenciamento de rede no projeto host.

O GKE atribui o seguinte papel automaticamente no projeto host ao ativar o acesso ao GKE:

Participante	Papel	Recurso
[e-mail]	Usuário do agente de serviço de host	Conta de serviço do GKE no projeto host

No entanto, é necessário adicionar a permissão Compute Network User do IAM manualmente à conta de serviço do GKE do projeto de serviço para acessar a rede host.

Participante	Papel	Recurso
[e-mail]	Usuário da rede do Compute	Sub-rede específica ou projeto host inteiro

Se um projeto de serviço foi anexado sem ativar o acesso ao GKE, supondo que a API GKE já esteja ativada no projeto host e de serviço, é possível atribuir manualmente as permissões à conta de serviço do GKE do projeto de serviço adicionando as seguintes vinculações de função do IAM no projeto host:

Participante	Papel	Recurso
[e-mail]	Usuário da rede do Compute	Sub-rede específica ou projeto host inteiro
[e-mail]	Usuário do agente de serviço de host	Agente de serviço do GKE no projeto host

Conceder o papel de usuário do agente de serviço de host

O agente de serviço do GKE de cada projeto de serviço precisa ter uma vinculação com o papel de Usuário do agente de serviço de host (roles/container.hostServiceAgentUser) no projeto host. O agente de serviço do GKE tem o seguinte formato:

[e-mail]

SERVICE_PROJECT_NUM é o número do projeto de serviço.

Essa vinculação permite que o agente de serviço do GKE do projeto de serviço realize operações de gerenciamento de rede no projeto host, como se fosse o agente de serviço do GKE do projeto host. Só é possível atribuir esse papel a um agente de serviço do GKE de um projeto de serviço.

Console

Se você estiver usando o console Google Cloud , não precisará conceder o papel de usuário do agente de serviço de host explicitamente. Isso foi feito automaticamente quando você usou o console do Google Cloud para anexar projetos de serviço ao projeto host.

gcloud

1. Para o primeiro projeto, conceda o papel de usuário do agente de serviço de host ao agente de serviço do GKE do projeto. Esse papel é concedido no projeto host:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. Para o segundo projeto, conceda o papel de usuário do agente de serviço de host ao agente de serviço do GKE do projeto. Esse papel é concedido no projeto host:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

Verificar sub-redes utilizáveis e intervalos de endereços IP secundários

Ao criar um cluster, é preciso especificar uma sub-rede e os intervalos de IPs secundários a serem usados para os pods e serviços do cluster. Há vários motivos pelos quais um intervalo de endereços de IP pode não estar disponível para uso. Se você estiver criando o cluster com o console Google Cloud ou a CLI gcloud, especifique intervalos de endereços IP utilizáveis.

Um intervalo de endereços de IP será utilizável para os serviços do novo cluster se ele ainda não estiver em uso. O intervalo de endereços de IP que você especifica para os novos pods do cluster pode ser um não usado ou um compartilhado com os pods em outros clusters. Os intervalos de enddereços de IP criados e gerenciados pelo GKE não podem ser usados por seu cluster.

É possível listar as sub-redes utilizáveis e os intervalos de endereços de IPs secundários de um projeto usando a gcloud CLI.

gcloud

gcloud container subnets list-usable \
    --project SERVICE_PROJECT_ID \
    --network-project HOST_PROJECT_ID

Substitua SERVICE_PROJECT_ID pelo ID do projeto de serviço.

Se você omitir a opção --project ou --network-project, o comando gcloud CLI usará o projeto padrão da sua configuração ativa. Como o projeto host e o projeto de rede são distintos, especifique --project e/ou --network-project.

O resultado será assim:

PROJECT               REGION    NETWORK     SUBNET  RANGE
example-host-project  us-west1  shared-net  tier-1  10.0.4.0/22
┌──────────────────────┬───────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
├──────────────────────┼───────────────┼─────────────────────────────┤
│ tier-1-services      │ 10.0.32.0/20  │ usable for pods or services │
│ tier-1-pods          │ 10.4.0.0/14   │ usable for pods or services │
└──────────────────────┴───────────────┴─────────────────────────────┘
example-host-project  us-west1  shared-net  tier-2  172.16.4.0/22
┌──────────────────────┬────────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE  │            STATUS           │
├──────────────────────┼────────────────┼─────────────────────────────┤
│ tier-2-services      │ 172.16.16.0/20 │ usable for pods or services │
│ tier-2-pods          │ 172.20.0.0/14  │ usable for pods or services │
└──────────────────────┴────────────────┴─────────────────────────────┘

O comando list-usable retorna uma lista vazia nas seguintes situações:

• Quando a conta de serviço do GKE do projeto de serviço não tem o papel de usuário do agente de serviço de host para o projeto host.
• Quando a conta de serviço do GKE no projeto host não existe. Por exemplo, se você tiver excluído essa conta acidentalmente.
• Quando a API GKE não está ativada no projeto host, o que significa que não há conta de serviço do GKE no projeto host.

Para mais informações, consulte a seção de solução de problemas.

Limites de intervalo de endereços IP secundários

É possível criar 30 intervalos secundários em uma determinada sub-rede. Em cada cluster, você precisa de dois intervalos secundários, um para pods e outro para serviços.

Observação: é possível compartilhar o intervalo principal e o secundário do pod entre clusters, mas essa não é uma configuração recomendada.

Criar um cluster no primeiro projeto de serviço

Para criar um cluster no primeiro projeto de serviço, execute as seguintes etapas usando a CLI gcloud ou o console Google Cloud .

Console

1. Acesse a página do Google Kubernetes Engine no Google Cloud console.

   Acessar o Google Kubernetes Engine

2. No seletor de projeto, selecione o primeiro projeto de serviço.

3. Clique em Criar.

4. No Autopilot ou na seção Padrão, clique em Configurar.

5. Em Nome, insira tier-1-cluster.

6. Na lista suspensa Região, selecione a mesma região usada para as sub-redes.

7. No painel de navegação, clique em Rede.

8. Em Rede de cluster, clique em Redes compartilhadas comigo.

9. No campo Rede, selecione shared-net.

10. Em Sub-rede do nó, selecione tier-1.

11. Em Opções de rede avançadas, em Intervalo CIDR secundário do pod, selecione tier-1-pods.

12. Em Intervalo CIDR secundário de serviços, selecione tier-1-services.

13. Clique em Criar.

Se você criou um cluster Standard, é possível verificar se os nós do cluster estão no intervalo de endereços principal da sub-rede tier-1 fazendo o seguinte:

1. Quando a criação for concluída, a página Detalhes do cluster será exibida.
2. Clique na guia Nós.
3. Em Pools de nós, clique em default-pool.
4. Em Grupos de instâncias, clique no nome do grupo de instâncias que você quer inspecionar. Por exemplo, gke-tier-1-cluster-default-pool-5c5add1f-grp.
5. Na lista de instâncias, verifique se os endereços IP internos dos nós estão no intervalo principal da sub-rede tier-1: 10.0.4.0/22.

gcloud

Crie um cluster tier-1-cluster no primeiro projeto de serviço:

gcloud container clusters create-auto tier-1-cluster \
    --project=SERVICE_PROJECT_1_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-1 \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services

Substitua CONTROL_PLANE_LOCATION pela região do Compute Engine do plano de controle do cluster.

Quando a criação estiver concluída, verifique se os nós do cluster estão no intervalo principal da sub-rede tier-1: 10.0.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_1_ID

A resposta mostra os endereços IP internos dos nós:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.2
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.3
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.4

Criar um cluster no segundo projeto de serviço

Para criar um cluster no segundo projeto de serviço, execute as seguintes etapas usando a CLI gcloud ou o console Google Cloud .

Console

1. Acesse a página do Google Kubernetes Engine no Google Cloud console.

   Acessar o Google Kubernetes Engine

2. No seletor de projeto, selecione o segundo projeto de serviço.

3. Clique em Criar.

4. Na seção Padrão ou Autopilot, clique em Configurar.

5. Em Nome, insira tier-2-cluster.

6. Na lista suspensa Região, selecione a mesma região usada para as sub-redes.

7. No painel de navegação, clique em Rede.

8. Em Rede de cluster, clique em Redes compartilhadas comigo.

9. No campo Rede, selecione shared-net.

10. Em Sub-rede do nó, selecione tier-2.

11. Em Opções de rede avançadas, em Intervalo CIDR secundário do pod, selecione tier-2-pods.

12. Em Intervalo CIDR secundário de serviços, selecione tier-2-services.

13. Clique em Criar.

Se você criou um cluster Standard, é possível verificar se os nós do cluster estão no intervalo de endereços principal da sub-rede tier-2 fazendo o seguinte:

1. Quando a criação for concluída, a página Detalhes do cluster será exibida.
2. Clique na guia Nós.
3. Em Pools de nós, clique em default-pool.
4. Em Grupos de instâncias, clique no nome do grupo de instâncias que você quer inspecionar. Por exemplo, gke-tier-2-cluster-default-pool-5c5add1f-grp.
5. Na lista de instâncias, verifique se os endereços IP internos dos nós estão no intervalo principal da sub-rede tier-2: 172.16.4.0/22.

gcloud

Crie um cluster tier-2-cluster no segundo projeto de serviço:

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-2 \
    --cluster-secondary-range-name=tier-2-pods \
    --services-secondary-range-name=tier-2-services

Quando a criação estiver concluída, verifique se os nós do cluster estão no intervalo principal da sub-rede tier-2: 172.16.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_2_ID

A resposta mostra os endereços IP internos dos nós:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.2
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.3
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.4

Observação: durante os upgrades de cluster do GKE, o GKE adiciona automaticamente entradas de metadados no nível do projeto, como google_compute_project_metadata, para rastrear o uso do intervalo de endereços IP secundários. Para mais detalhes e orientações sobre como gerenciar esses metadados com ferramentas de infraestrutura como código (IaC), consulte Metadados do projeto para intervalos de endereços IP secundários.

Crie regras de firewall

Para permitir o tráfego na rede e entre os clusters dentro da rede, você precisa criar firewalls. Nas seções a seguir, você verá como criar e atualizar regras de firewall:

• Como criar uma regra de firewall para ativar a conexão SSH com um nó: demonstra como criar uma regra de firewall que ativa o tráfego de fora dos clusters usando SSH.

• Como atualizar a regra de firewall para dar um ping entre nós: demonstra como atualizar a regra de firewall para permitir o tráfego ICMP entre os clusters.

  SSH e ICMP são usados como exemplos. É necessário criar regras de firewall que atendem aos requisitos de rede do seu aplicativo específico.

Observação: os Administradores da VPC compartilhada são responsáveis por criar regras de firewall na rede da VPC compartilhada.

Criar uma regra de firewall para ativar a conexão SSH com um nó

No projeto host, crie uma regra de firewall para a rede shared-net. Deixe que o tráfego entre na porta TCP 22, o que permite que você se conecte aos nós do cluster usando SSH.

Console

1. Acesse a página Firewall no console do Google Cloud .

   Acessar o Firewall

2. No seletor de projeto, selecione o projeto host.

3. No menu Rede VPC, clique em Criar regra de firewall.

4. Em Nome, insira my-shared-net-rule.

5. Em Rede, selecione shared-net.

6. Em Direção de tráfego, selecione Entrada.

7. Em Ação se houver correspondência, selecione Permitir.

8. Em Destinos, selecione Todas as instâncias na rede.

9. Em Filtro de origem, selecione Intervalos de IP.

10. Em Intervalos de IP de origem, insira 0.0.0.0/0.

11. Em Protocolos e portas, selecione Protocolos e portas especificados. Na caixa, digite tcp:22.

12. Clique em Criar.

gcloud

Crie uma regra de firewall para a rede compartilhada:

gcloud compute firewall-rules create my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --direction INGRESS \
    --allow tcp:22

Conectar-se a um nó usando SSH

Depois de criar o firewall que permite o tráfego de entrada na porta TCP 22, conecte-se ao nó usando SSH.

Console

1. Acesse a página do Google Kubernetes Engine no Google Cloud console.

   Acessar o Google Kubernetes Engine

2. No seletor de projeto, selecione o primeiro projeto de serviço.

3. Clique em tier-1-cluster.

4. Na página Detalhes do cluster, clique na guia Nós.

5. Em Pool de nós, clique no nome do pool.

6. Em Grupos de instâncias, clique no nome do grupo. Por exemplo, gke-tier-1-cluster-default-pool-faf87d48-grp.

7. Na lista de nós, anote os endereços IP internos deles. Esses endereços estão no intervalo 10.0.4.0/22.

8. Para um dos nós, clique em SSH. Essa ação será bem-sucedida porque o SSH usa a porta TCP 22, que é permitida pela regra de firewall.

gcloud

Liste os nós no primeiro projeto de serviço:

gcloud compute instances list --project SERVICE_PROJECT_1_ID

A saída inclui os nomes dos nós no cluster:

NAME                                           ...
gke-tier-1-cluster-default-pool-faf87d48-3mf8  ...
gke-tier-1-cluster-default-pool-faf87d48-q17k  ...
gke-tier-1-cluster-default-pool-faf87d48-x9rk  ...

Conecte-se a um dos nós usando SSH:

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

Substitua:

• NODE_NAME: o nome de um dos nós.
• COMPUTE_ZONE: o nome de uma zona do Compute Engine na região.

Atualizar a regra de firewall para permitir o tráfego entre nós

1. Na janela de linha de comando do SSH, inicie a caixa de ferramentas CoreOS:

   /usr/bin/toolbox
   

2. No shell da caixa de ferramentas, dê um ping em um dos outros nós no mesmo cluster. Exemplo:

   ping 10.0.4.4
   

   O comando ping é bem-sucedido porque seu nó e o outro nó estão no intervalo 10.0.4.0/22.

3. Agora dê um ping em um dos nós do cluster no outro projeto de serviço. Exemplo:

   ping 172.16.4.3
   

   Desta vez, o comando ping falha porque sua regra de firewall não permite o tráfego do ICMP.

4. Em um prompt de comando comum, e não no shell da caixa de ferramentas, atualize a regra de firewall para permitir o ICMP:

   gcloud compute firewall-rules update my-shared-net-rule \
       --project HOST_PROJECT_ID \
       --allow tcp:22,icmp
   

5. No shell da caixa de ferramentas, dê um ping no nó novamente. Exemplo:

   ping 172.16.4.3
   

   Desta vez, o comando ping é bem-sucedido.

Crie regras extras de firewall

É possível criar outras regras de firewall para permitir a comunicação entre nós, pods e serviços nos clusters.

Por exemplo, esta regra permite que o tráfego entre de qualquer nó, pod ou serviço em tier-1-cluster em qualquer porta TCP ou UDP:

gcloud compute firewall-rules create my-shared-net-rule-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

A regra a seguir permite que o tráfego entre de qualquer nó, pod ou serviço em tier-2-cluster em qualquer porta TCP ou UDP:

gcloud compute firewall-rules create my-shared-net-rule-3 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 172.16.4.0/22,172.20.0.0/14,172.16.16.0/20

O Kubernetes também tentará criar e gerenciar recursos de firewall quando necessário. Por exemplo, quando você criar um serviço de balanceador de carga. Se o Kubernetes não conseguir alterar as regras de firewall devido a um problema de permissão, um evento do Kubernetes será gerado para fornecer instruções sobre como fazer as alterações.

Se você quiser conceder ao Kubernetes permissão para alterar as regras de firewall, consulte Gerenciar recursos de firewall.

Para os balanceadores de carga de entrada, se o Kubernetes não puder alterar as regras de firewall devido à permissão insuficiente, um evento firewallXPNError será emitido em um intervalo de vários minutos. No GLBC 1.4 (em inglês) e posterior, adicione a anotação networking.gke.io/suppress-firewall-xpn-error: "true" ao recurso de entrada para desativar o som do evento firewallXPNError. Sempre é possível remover essa anotação para ativar o som.

Criar um cluster com base no peering de rede VPC em uma VPC compartilhada

É possível usar a VPC compartilhada com clusters baseados no peering de rede VPC.

Isso requer que você conceda as seguintes permissões no projeto host, seja para a conta de usuário ou para a conta de serviço, usada para criar o cluster:

• compute.networks.get

• compute.networks.updatePeering

Verifique também se o intervalo de endereços IP do plano de controle não se sobrepõe a outros intervalos reservados na rede compartilhada.

Nesta seção, você criará um cluster nativo de VPC, cluster-vpc, em uma rede VPC compartilhada predefinida.

Console

1. Acesse a página do Google Kubernetes Engine no Google Cloud console.

   Acessar o Google Kubernetes Engine

2. Clique em Criar.

3. No Autopilot ou na seção Padrão, clique em Configurar.

4. Em Nome, insira cluster-vpc.

5. No painel de navegação, clique em Rede.

6. Na seção Rede do cluster, marque a caixa de seleção Ativar nós particulares.

7. Opcional para o Autopilot: defina o Intervalo de IP do plano de controle para 172.16.0.16/28.

8. Na lista suspensa Rede, selecione a rede VPC criada anteriormente.

9. Na lista suspensa Sub-rede do nó, selecione a sub-rede compartilhada criada anteriormente.

10. Configure o cluster conforme necessário.

11. Clique em Criar.

gcloud

Execute o seguinte comando para criar um cluster chamado cluster-vpc em uma VPC compartilhada predefinida:

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork=SHARED_SUBNETWORK \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28

Reservar endereços IP

É possível reservar endereços IP externos e internos para os clusters de VPC compartilhada. Garanta que os endereços IP sejam reservados no projeto de serviço.

Para endereços IP internos, forneça a sub-rede a que o endereço IP pertence. Para reservar um endereço IP nos projetos, use o URL completo do recurso para identificar a sub-rede.

Use o comando a seguir na Google Cloud CLI para reservar um endereço IP interno:

gcloud compute addresses create RESERVED_IP_NAME \
    --region=COMPUTE_REGION \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNETWORK_NAME \
    --addresses=IP_ADDRESS \
    --project=SERVICE_PROJECT_ID

Para chamar esse comando, você precisa ter a permissão compute.subnetworks.use adicionada à sub-rede. Conceda ao autor da chamada um papel personalizado com permissão compute.subnetworks.use para envolvidos no projeto ou um papel compute.networkUser na sub-rede.

Limpar

Após concluir os exercícios deste guia, execute as seguintes tarefas para remover os recursos e evitar cobranças indesejadas na sua conta:

Excluir os clusters

Exclua os dois clusters criados.

Console

1. Acesse a página do Google Kubernetes Engine no Google Cloud console.

   Acessar o Google Kubernetes Engine

2. No seletor de projeto, selecione o primeiro projeto de serviço.

3. Selecione o tier-1-cluster e clique em Excluir.

4. No seletor de projeto, selecione o segundo projeto de serviço.

5. Selecione o tier-2-cluster e clique em Excluir.

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --location CONTROL_PLANE_LOCATION

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --location CONTROL_PLANE_LOCATION

Desativar a VPC compartilhada

Desative a VPC compartilhada no projeto host.

Console

1. Acesse a página VPC compartilhada no console do Google Cloud .

   Acessar VPC compartilhada

2. No seletor de projeto, selecione o projeto host.

3. Clique em Desativar VPC compartilhada.

4. Digite HOST_PROJECT_ID no campo e clique em Desativar.

gcloud

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc disable HOST_PROJECT_ID

Excluir regras de firewall

Remova as regras de firewall criadas.

Console

1. Acesse a página Firewall no console do Google Cloud .

   Acessar o Firewall

2. No seletor de projeto, selecione o projeto host.

3. Na lista de regras, selecione my-shared-net-rule, my-shared-net-rule-2 e my-shared-net-rule-3.

4. Clique em Excluir.

gcloud

Exclua as regras de firewall:

gcloud compute firewall-rules delete \
    my-shared-net-rule \
    my-shared-net-rule-2 \
    my-shared-net-rule-3 \
    --project HOST_PROJECT_ID

Excluir a rede compartilhada

Exclua a rede compartilhada criada.

Console

1. Acesse a página Redes VPC no console do Google Cloud .

   Acessar redes VPC

2. No seletor de projeto, selecione o projeto host.

3. Na lista de redes, clique no link shared-net.

4. Clique em Excluir rede VPC.

gcloud

gcloud compute networks subnets delete tier-1 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks subnets delete tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

Remover o papel de usuário do agente de serviço de host

Remova os papéis de usuário do agente de serviço de host dos dois projetos de serviço.

Console

1. Acesse a página IAM no console do Google Cloud .

   Acessar IAM

2. No seletor de projeto, selecione o projeto host.

3. Selecione Incluir concessões de papel fornecidas pelo Google.

4. Na lista de membros, selecione a linha que mostra que [e-mail] recebeu o papel de usuário do agente de serviço de host do Kubernetes Engine.

5. Clique em Editar principal.

6. Em Usuário do agente de serviço de host do Kubernetes Engine, clique no ícone para remover o papel.

7. Clique em Salvar.

8. Selecione a linha que mostra que [e-mail] recebeu o papel de usuário do agente de serviço de host do Kubernetes Engine.

9. Clique em Editar principal.

10. Em Usuário do agente de serviço de host do Kubernetes Engine, clique no ícone para remover o papel.

11. Clique em Salvar.

gcloud

1. Remova a função de usuário do agente do serviço de host da conta de serviço do GKE do seu primeiro projeto de serviço:

   gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. Remova o papel de usuário do agente de serviço de host da conta de serviço do GKE do segundo projeto de serviço:

   gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

Solução de problemas

As seções a seguir ajudam você a resolver problemas comuns com clusters da VPC compartilhada.

Erro: não foi possível receber metadados do projeto de rede

A mensagem a seguir é um erro comum ao trabalhar com clusters de VPC compartilhada:

Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google
Compute Engine: Required 'compute.projects.get' permission for
'projects/HOST_PROJECT_ID

Esse problema pode ocorrer pelos seguintes motivos:

• A API GKE não foi ativada no projeto host.

• A conta de serviço do GKE do projeto host não existe. Por exemplo, ela pode ter sido excluída.

• A conta de serviço do GKE do projeto host não tem o papel de agente de serviço do Kubernetes Engine (container.serviceAgent) no projeto host. A vinculação pode ter sido removida por engano.

• A conta de serviço do GKE do projeto de serviço não tem o papel de usuário do agente de serviço de host no projeto host.

Para resolver o problema, determine se a conta de serviço do GKE do projeto host existe.

Se a conta de serviço não existir, faça o seguinte:

• Se a API GKE não estiver ativada no projeto host, ative-a. Isso cria a conta de serviço do GKE do projeto host e concede a ela o papel de Agente de serviço do Kubernetes Engine (container.serviceAgent) no projeto host.

• Se a API GKE estiver ativada no projeto host, isso significa que a conta de serviço do GKE do projeto host foi excluída ou não tem o papel de agente de serviço do Kubernetes Engine (container.serviceAgent) no projeto host. Para restaurar a conta de serviço do GKE ou a vinculação de papel, desative e reative a API GKE. Para mais informações, consulte Erro 400/403: permissões de edição ausentes na conta.

  Observação: desativar e reativar a API GKE no projeto host não afetará a operação dos clusters atuais em projetos de serviço. No entanto, não é possível criar novos clusters que usem uma rede VPC compartilhada, em um projeto de serviço ou no projeto host, enquanto a API GKE está desativada.

Problema: conectividade

Se você estiver com problemas de conectividade entre as VMs do Compute Engine que estão na mesma rede de nuvem privada virtual (VPC) ou em duas redes VPC conectadas com o peering de rede VPC, consulte Como solucionar problemas de conectividade entre instâncias máquina virtual (VM) com endereços IP internos na documentação da nuvem privada virtual (VPC).

Problema: perda de pacote

Se você estiver enfrentando problemas de perda de pacotes ao enviar tráfego de um cluster para um endereço IP externo usando o Cloud NAT, clusters nativos de VPC ou Agente de mascaramento de IP, consulte Solucionar problemas de perda de pacotes do Cloud NAT em um cluster.

A seguir

• Leia a visão geral da VPC compartilhada.
• Saiba mais sobre como provisionar uma VPC compartilhada.
• Leia a visão geral da rede GKE.
• Leia sobre regras de firewall criadas automaticamente.
• Saiba como resolver problemas de conectividade entre instâncias de máquina virtual (VM) com endereços IP internos.