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.
Visão geral
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.
Sobre os exemplos
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.
Antes de começar
Antes de começar a configurar um cluster com a VPC compartilhada:
- Verifique se você tem uma organização do Google Cloud.
- Verifique se sua organização tem três projetos do Google Cloud.
- Familiarize-se com os conceitos de VPC compartilhada, incluindo os diversos papéis de gerenciamento de identidade e acesso (IAM) usados pela VPC compartilhada. As tarefas neste guia precisam ser executadas por um Administrador de VPC compartilhada.
- Certifique-se de entender todas as restrições da política da organização aplicáveis à sua 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 |
Como encontrar os números e IDs de projetos
Encontre o ID e os números do projeto usando a gcloud CLI ou o console do Google Cloud.
Console
Acesse a página inicial no Console do Google Cloud.
No seletor de projeto, selecione aquele que você escolheu para ser o host.
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.
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
Como ativar a API do 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 do Cloud ou a Google Cloud CLI.
Console
Acesse a página APIs e serviços no Console do Google Cloud.
No seletor de projeto, selecione aquele que você escolheu para ser o host.
Se a API Kubernetes Engine estiver na lista de APIs, ela já está ativada e você não precisará fazer nada. Caso contrário, clique em Ativar APIs e serviços. Pesquise por
Kubernetes Engine API
. Clique no cartão API do Kubernetes Engine e clique em Ativar.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
Como criar uma rede e duas sub-redes
Nesta seção, você realizará as seguintes tarefas:
- No projeto host, crie uma rede chamada
shared-net
. - Crie duas sub-redes chamadas
tier-1
etier-2
. - Para cada sub-rede, crie dois intervalos de endereços secundários: um para serviços e outro para pods.
Console
Acesse a página Redes VPC no Console do Google Cloud.
No seletor de projeto, selecione o projeto host.
Clique em add_box Criar rede VPC.
Em Nome, insira
shared-net
.Em Modo de criação de sub-rede, selecione Personalizado.
Na caixa Nova sub-rede, para Nome, digite
tier-1
.Em Região, selecione uma região.
Em Tipo de pilha de IP, selecione IPv4 (pilha única).
Em Intervalo IPv4, insira
10.0.4.0/22
.Clique em Criar intervalo IPv4 secundário. Digite
tier-1-services
em Nome do intervalo da sub-rede e10.0.32.0/20
em Intervalo de IPv4 secundário.Clique em Adicionar intervalo de IP. Digite
tier-1-pods
em Nome do intervalo da sub-rede e10.4.0.0/14
em Intervalo de IPv4 secundário.Clique em Add subnet.
Em Nome, insira
tier-2
.Em Região, selecione a mesma região selecionada para a sub-rede anterior.
Em Intervalo IPv4, insira
172.16.4.0/22
.Clique em Criar intervalo IPv4 secundário. Digite
tier-2-services
em Nome do intervalo da sub-rede e172.16.16.0/20
em Intervalo de IPv4 secundário.Clique em Adicionar intervalo de IP. Digite
tier-2-pods
em Nome do intervalo da sub-rede e172.20.0.0/14
em Intervalo de IPv4 secundário.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.
Como 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 | service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com |
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com | |
APIs do Google | SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com |
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com |
Como ativar a VPC compartilhada e conceder papéis
Para executar as tarefas nesta seção, verifique se sua organização definiu um papel Administrador da VPC compartilhada.
Nesta seção, você realizará as seguintes tarefas:
- No projeto host, ative a VPC compartilhada.
- Anexe seus dois projetos de serviço ao projeto host.
- Conceda os papéis apropriados do IAM às contas de serviço que
pertencem aos seus projetos de serviço:
- No primeiro projeto de serviço, conceda a duas contas de serviço o
papel
Compute Network User
na sub-redetier-1
do seu projeto host. - No segundo projeto de serviço, conceda a dois projetos de serviço o
papel
Compute Network User
na sub-redetier-2
do projeto host.
- No primeiro projeto de serviço, conceda a duas contas de serviço o
papel
Console
Execute estas etapas para ativar a VPC compartilhada, anexar projetos de serviço e conceder papéis:
Acesse a página VPC compartilhada no Console do Google Cloud.
No seletor de projeto, selecione o projeto host.
Clique em Configurar VPC compartilhada. A tela Ativar projeto host é exibida.
Clique em Salvar e continuar. A página Selecionar sub-redes é exibida.
Em Modo de compartilhamento, selecione Sub-redes individuais.
Em Sub-redes para compartilhar, marque tier-1 e tier-2. Limpe todas as outras caixas de seleção.
Clique em Continuar. A página Conceder permissões é exibida.
Em Anexar projetos de serviço, marque o primeiro e o segundo projetos de serviço. Desmarque todas as outras caixas de seleção em Anexar projetos de serviço.
Em Acesso ao Kubernetes Engine, marque a opção Ativado.
Clique em Salvar. Uma nova página é exibida.
Em Permissões de sub-rede individual, marque tier-1.
No painel direito, exclua todas as contas de serviço que pertencem ao segundo projeto de serviço. Ou seja, exclua todas as contas de serviço que contenham
SERVICE_PROJECT_2_NUM
.No painel direito, procure os nomes das contas de serviço do Kubernetes Engine e das APIs do Google que pertencem ao primeiro projeto de serviço. Esses dois nomes de conta de serviço precisam estar na lista. Se algum deles não estiver na lista, insira o nome da conta de serviço em Adicionar membros e clique em Adicionar.
No painel central, em Permissões de sub-rede individuais, marque tier-2 e desmarque tier-1.
No painel direito, 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
.No painel direito, procure os nomes das contas de serviço do Kubernetes Engine e das APIs do Google que pertencem ao segundo projeto de serviço. Esses dois nomes de conta de serviço precisam estar na lista. Se algum deles não estiver na lista, insira o nome da conta de serviço em Adicionar membros e clique em Adicionar.
gcloud
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
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
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
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 valoretag
.Crie um arquivo chamado
tier-1-policy.yaml
que tenha o seguinte conteúdo:bindings: - members: - serviceAccount:SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com role: roles/compute.networkUser etag: ETAG_STRING
Substitua
ETAG_STRING
pelo valor deetag
que você anotou anteriormente.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
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 valoretag
.Crie um arquivo chamado
tier-2-policy.yaml
que tenha o seguinte conteúdo:bindings: - members: - serviceAccount:SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com role: roles/compute.networkUser etag: ETAG_STRING
Substitua
ETAG_STRING
pelo valor deetag
que você anotou anteriormente.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
Como 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:
Conceda à conta de serviço do GKE do projeto de serviço o papel
Compute Security Admin
para o projeto host.
Console
No console do Google Cloud, abra a página IAM.
Selecione o projeto host.
Clique em
Conceder acesso e insira o principal da conta de serviço do GKE do projeto de serviço,service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
.Selecione o papel
Compute Security Admin
na lista suspensa.Clique em Save.
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:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
--role=roles/compute.securityAdmin
Substitua:
HOST_PROJECT_ID
: o ID do projeto host da VPC compartilhadaSERVICE_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
ecompute.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:
No console do Google Cloud, abra a página Papéis.
Usando a lista suspensa na parte superior da página, selecione o projeto host.
Clique em Criar papel.
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.
Clique em Adicionar permissões.
Filtre por
compute.networks
e selecione as permissões do IAM mencionadas acima.Depois de selecionar todas as permissões necessárias, clique em Adicionar.
Clique em Criar.
Conceda à conta de serviço do GKE do projeto de serviço o papel personalizado recém-criado no projeto host:
No console do Google Cloud, abra a página IAM.
Selecione o projeto host.
Clique em
Conceder acesso e insira o principal da conta de serviço do GKE do projeto de serviço,service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
.Filtre e selecione o Título do papel personalizado recém-criado.
Clique em Save.
gcloud
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
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:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \ --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
Substitua:
ROLE_ID
: o nome do papel, comogkeFirewallAdmin
ROLE_TITLE
: um título intuitivo para o papel, comoGKE Firewall Admin
ROLE_DESCRIPTION
: uma breve descrição do papel, comoGKE service account FW permissions
LAUNCH_STAGE
: a fase de lançamento do papel no ciclo de vida, comoALPHA
,BETA
ouGA
HOST_PROJECT_ID
: o ID do projeto host da VPC compartilhadaSERVICE_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.
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 |
---|---|---|
service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com | Usuário da rede do Compute | tier-1 |
SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com | Usuário da rede do Compute | tier-1 |
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com | Usuário da rede do Compute | tier-2 |
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com | Usuário da rede do Compute | tier-2 |
Acesso do Kubernetes Engine
Ao anexar um projeto de serviço, a ativação do acesso do Kubernetes Engine concede à conta de serviço do GKE do projeto as permissões para executar operações de gerenciamento de rede no projeto host.
Se um projeto de serviço foi anexado sem ativar o acesso do Kubernetes Engine, supondo que a API Kubernetes Engine já tenha sido ativada nos dois projetos host e de serviço, será possível atribuir manualmente as permissões à conta de serviço do GKE adicionando as seguintes vinculações de papel do IAM ao projeto host:
Membro | Papel | Recurso |
---|---|---|
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com | Usuário da rede do Compute | Sub-rede específica ou projeto host inteiro |
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com | Usuário do agente de serviço de host | Conta de serviço do GKE no projeto host |
Como conceder o papel de usuário do agente de serviço de host
A conta de serviço do GKE de cada projeto de serviço precisa ter uma vinculação com o papel Usuário do agente de serviço de host no projeto host. A conta de serviço do GKE tem o seguinte formato:
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
SERVICE_PROJECT_NUM
é o número do
projeto de serviço.
Essa vinculação permite que a conta de serviço do GKE do projeto de serviço realize operações de gerenciamento de rede no projeto host, como se fosse a conta de serviço do GKE do projeto host. Só é possível atribuir esse papel a uma conta de serviço do GKE de um projeto de serviço.
Console
Se você estiver usando o Console do 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
Para o primeiro projeto, conceda o papel de usuário do agente de serviço de host à conta de serviço do GKE do projeto. Esse papel é concedido no projeto host:
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \ --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \ --role roles/container.hostServiceAgentUser
Para o segundo projeto, conceda o papel de usuário do agente de serviço de host à conta de serviço do GKE do projeto. Esse papel é concedido no projeto host:
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \ --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \ --role roles/container.hostServiceAgentUser
Como verificar sub-redes utilizáveis e intervalos de endereços de 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 do Google Cloud ou a gcloud CLI, especifique intervalos de endereços de IPs 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: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-2
RANGE: 172.16.4.0/22
SECONDARY_RANGE_NAME: tier-2-services
IP_CIDR_RANGE: 172.20.0.0/14
STATUS: usable for pods or services
SECONDARY_RANGE_NAME: tier-2-pods
IP_CIDR_RANGE: 172.16.16.0/20
STATUS: usable for pods or services
PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-1
RANGE: 10.0.4.0/22
SECONDARY_RANGE_NAME: tier-1-services
IP_CIDR_RANGE: 10.0.32.0/20
STATUS: usable for pods or services
SECONDARY_RANGE_NAME: tier-1-pods
IP_CIDR_RANGE: 10.4.0.0/14
STATUS: usable for pods or services
O comando list-usable
retorna uma lista vazia nas seguintes situações:
- Quando a conta de serviço do Kubernetes Engine 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 Kubernetes Engine no projeto host não existe. Por exemplo, se você tiver excluído essa conta acidentalmente.
- Quando a API Kubernetes Engine não está ativada no projeto host, o que significa que não há conta de serviço do Kubernetes Engine no projeto host.
Para mais informações, consulte a seção de solução de problemas.
Observações sobre intervalos 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.
Como 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 gcloud CLI ou o console do Google Cloud.
Console
Acesse a página Google Kubernetes Engine no console do Google Cloud.
No seletor de projeto, selecione o primeiro projeto de serviço.
Clique em add_box Criar.
No Autopilot ou na seção Padrão, clique em Configurar.
Em Nome, insira
tier-1-cluster
.Na lista suspensa Região, selecione a mesma região usada para as sub-redes.
No painel de navegação, clique em Rede.
Selecione Redes compartilhadas comigo (do projeto host).
Em Rede, selecione shared-net.
Em Sub-rede do nó, selecione tier-1.
Em Intervalo CIDR secundário do pod, selecione tier-1-pods.
Em Intervalo CIDR secundário de serviços, selecione tier-1-services.
Clique em Criar.
Quando a criação estiver concluída, na lista de clusters, clique em tier-1-cluster.
Na página Detalhes do cluster, clique na guia Nós
Em Pools de nós, clique no nome do pool que você quer inspecionar.
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.
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=COMPUTE_REGION \
--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
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
Como 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 gcloud CLI ou o console do Google Cloud.
Console
Acesse a página Google Kubernetes Engine no console do Google Cloud.
No seletor de projeto, selecione o segundo projeto de serviço.
Clique em add_box Criar.
Na seção Padrão ou Autopilot, clique em Configurar.
Em Nome, insira
tier-2-cluster
.Na lista suspensa Região, selecione a mesma região usada para as sub-redes.
No painel de navegação, clique em Rede.
Em Rede, selecione shared-net.
Em Sub-rede do nó, selecione tier-2.
Em Intervalo CIDR secundário do pod, selecione tier-2-pods.
Em Intervalo CIDR secundário de serviços, selecione tier-2-services.
Clique em Criar.
Quando a criação estiver concluída, na lista de clusters, clique em tier-2-cluster.
Na página Detalhes do cluster, clique na guia Nós
Em Pools de nós, clique no nome do pool que você quer inspecionar.
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
.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=COMPUTE_REGION \
--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
Criar 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.
Como 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
Acesse a página Firewall no Console do Google Cloud.
No seletor de projeto, selecione o projeto host.
No menu Rede VPC, clique em Criar regra de firewall.
Em Nome, insira
my-shared-net-rule
.Em Rede, selecione shared-net.
Em Direção de tráfego, selecione Entrada.
Em Ação se houver correspondência, selecione Permitir.
Em Destinos, selecione Todas as instâncias na rede.
Em Filtro de origem, selecione Intervalos de IP.
Em Intervalos de IP de origem, insira
0.0.0.0/0
.Em Protocolos e portas, selecione Protocolos e portas especificados. Na caixa, digite
tcp:22
.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
Como se conectar a um nó usando o SSH
Depois de criar o firewall que permite o tráfego de entrada na porta TCP 22
, conecte-se ao nó usando SSH.
Console
Acesse a página Google Kubernetes Engine no console do Google Cloud.
No seletor de projeto, selecione o primeiro projeto de serviço.
Clique em tier-1-cluster.
Na página Detalhes do cluster, clique na guia Nós.
Em Pool de nós, clique no nome do pool.
Em Grupos de instâncias, clique no nome do grupo. Por exemplo, gke-tier-1-cluster-default-pool-faf87d48-grp.
Na lista de nós, anote os endereços IP internos deles. Esses endereços estão no intervalo
10.0.4.0/22
.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.
Como atualizar a regra de firewall para dar ping entre nós
Na janela de linha de comando do SSH, inicie a caixa de ferramentas CoreOS:
/usr/bin/toolbox
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 intervalo10.0.4.0/22
.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.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
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.
Como criar outras regras 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 Como 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.
Como criar um cluster particular em uma VPC compartilhada
É possível usar a VPC compartilhada com clusters particulares.
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.
Para clusters particulares criados antes de 15 de janeiro de 2020, o número máximo de clusters particulares do GKE possíveis por rede VPC é limitado ao número de conexões de peering de uma única rede VPC. Os novos clusters particulares reutilizam conexões de peering de rede VPC, o que remove essa limitação. Para ativar a reutilização do peering da rede VPC em clusters particulares mais antigos, é possível excluir um cluster e recriá-lo. Fazer o upgrade de um cluster não faz com que ele reutilize uma conexão atual do peering da rede VPC.
Nesta seção, você criará um cluster nativo de VPC, private-cluster-vpc
, em uma rede VPC compartilhada predefinida.
Console
Acesse a página Google Kubernetes Engine no console do Google Cloud.
Clique em add_box Criar.
No Autopilot ou na seção Padrão, clique em Configurar.
Em Nome, insira
private-cluster-vpc
.No painel de navegação, clique em Rede.
Selecione Cluster particular.
Opcional para o Autopilot: defina o Intervalo de IP do plano de controle para
172.16.0.16/28
.Na lista suspensa Rede, selecione a rede VPC criada anteriormente.
Na lista suspensa Sub-rede do nó, selecione a sub-rede compartilhada criada anteriormente.
Configure o cluster conforme necessário.
Clique em Criar.
gcloud
Execute o seguinte comando para criar um cluster chamado private-cluster-vpc
em uma VPC compartilhada predefinida:
gcloud container clusters create-auto private-cluster-vpc \
--project=PROJECT_ID \
--location=COMPUTE_REGION \
--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
Como 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:
Como excluir os clusters
Exclua os dois clusters criados.
Console
Acesse a página Google Kubernetes Engine no console do Google Cloud.
No seletor de projeto, selecione o primeiro projeto de serviço.
Selecione o tier-1-cluster e clique em Excluir.
No seletor de projeto, selecione o segundo projeto de serviço.
Selecione o tier-2-cluster e clique em Excluir.
gcloud
gcloud container clusters delete tier-1-cluster \
--project SERVICE_PROJECT_1_ID \
--zone COMPUTE_ZONE
gcloud container clusters delete tier-2-cluster \
--project SERVICE_PROJECT_2_ID \
--zone COMPUTE_ZONE
Como desativar a VPC compartilhada
Desative a VPC compartilhada no projeto host.
Console
Acesse a página VPC compartilhada no Console do Google Cloud.
No seletor de projeto, selecione o projeto host.
Clique em Desativar VPC compartilhada.
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
Como excluir suas regras de firewall
Remova as regras de firewall criadas.
Console
Acesse a página Firewall no Console do Google Cloud.
No seletor de projeto, selecione o projeto host.
Na lista de regras, selecione my-shared-net-rule, my-shared-net-rule-2 e my-shared-net-rule-3.
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
Como excluir a rede compartilhada
Exclua a rede compartilhada criada.
Console
Acesse a página Redes VPC no Console do Google Cloud.
No seletor de projeto, selecione o projeto host.
Na lista de redes, selecione shared-net.
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
Como 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
Acesse a página IAM no Console do Google Cloud.
No seletor de projeto, selecione o projeto host.
Na lista de membros, selecione a linha que mostra que
service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com
recebeu o papel de usuário do agente de serviço de host do Kubernetes Engine.Selecione a linha que mostra que
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com
recebeu o papel de usuário do agente de serviço de host do Kubernetes Engine.Clique em Remover acesso.
gcloud
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:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \ --role roles/container.hostServiceAgentUser
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:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \ --role roles/container.hostServiceAgentUser
Solução de problemas
Permissão recusada
Sintoma:
Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google Compute Engine: Required 'compute.projects.get' permission for 'projects/HOST_PROJECT_ID
A API Kubernetes Engine 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 corrigir o problema: determine se a conta de serviço do GKE do projeto host existe. Se você não a encontrar, faça o seguinte:
Se a API Kubernetes Engine 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 Kubernetes Engine 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 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 Kubernetes Engine. Para mais informações, consulte Solução de problemas do Google Kubernetes Engine.
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.