Como configurar clusters com a VPC compartilhada

Nesta página, mostramos como criar dois clusters do Google Kubernetes Engine em projetos separados que usam uma nuvem privada virtual (VPC, na sigla em inglês) compartilhada. Para informações gerais sobre a rede do GKE, veja 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 regionais e zonais. Os clusters que usam a VPC compartilhada não podem utilizar redes legadas e precisam ter IPs do alias ativados.

É possível configurar a VPC compartilhada ao criar um novo cluster. O Google Kubernetes Engine não aceita a conversão de clusters atuais para o 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 ver mais detalhes, consulte Cotas e limites.

Os exemplos neste tópico configuram a infraestrutura para um aplicativo da Web de dois níveis, conforme descrito em Visão geral da VPC compartilhada.

Nos exemplos desta página, usamos nomes e intervalos de endereços específicos para ilustrar procedimentos gerais. Se quiser, é possível alterá-los para atender às suas necessidades. Além disso, os exercícios usam a região us-central1 e a zona us-central1-a. Se preferir, é possível alterar a região e a zona de acordo com as suas necessidades.

Antes de começar

Para realizar esta tarefa, é preciso ter uma organização do Cloud Platform com três projetos.

Na organização, você precisa receber o papel de Administrador de VPC compartilhada do Compute.

Antes de fazer os exercícios neste tópico, escolha um dos projetos para ser o projeto host e dois para serem projetos de serviço. Cada projeto tem um nome, um código e um número. Em alguns casos, o nome e o código são iguais. Este tópico usa os seguintes nomes amigáveis ​​para se referir aos projetos:

  • seu projeto host
  • seu primeiro projeto de serviço
  • seu segundo projeto de serviço

Neste tópico, usamos os seguintes marcadores para fazer referência aos códigos e números do projeto.

  • [HOST_PROJECT_ID] é o código do projeto host.
  • [HOST_PROJECT_NUM] é o número do projeto host.
  • [SERVICE_PROJECT_1_ID] é o código do primeiro projeto de serviço.
  • [SERVICE_PROJECT_1_NUM] é o número do primeiro projeto de serviço.
  • [SERVICE_PROJECT_2_ID] é o código do segundo projeto de serviço.
  • [SERVICE_PROJECT_2_NUM] é o número do segundo projeto de serviço.

Como encontrar os códigos e números de projetos

gcloud

Liste os projetos:

gcloud projects list

A saída mostra os nomes, códigos e números dos projetos. Anote o código 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

Console

  1. Acesse a página inicial no Console do Google Cloud Platform.
    Acesse a 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 código e o número do projeto. Anote o código 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.

Como ativar a API Google Kubernetes Engine nos projetos

Antes de continuar com os exercícios deste tópico, verifique se a API Google Kubernetes Engine 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 etapas restantes neste tópico, cada um dos seus projetos precisa ter uma conta de serviço do GKE.

gcloud

Ative a API Google Kubernetes Engine nos 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]

Console

  1. Acesse o painel APIs e serviços no Console do GCP.
    Acesse o painel de APIs
  2. No seletor de projeto, selecione aquele que você escolheu para ser o host.
  3. 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 Kubernetes Engine API. Clique no card API Kubernetes Engine e em Ativar.
  4. Repita essas etapas para cada projeto que você escolheu para ser um projeto de serviço.

Como criar uma rede e duas sub-redes

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

gcloud

No projeto host, crie uma rede com o nome shared-net.

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

Na nova rede, crie uma sub-rede com o nome tier-1:

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

Crie outra sub-rede com o nome tier-2:

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

Console

  1. Acesse a página Redes VPC no Console do GCP.
    Acesse a página 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.
  6. Na caixa Nova sub-rede, insira tier-1 em Nome.
  7. Em Região, selecione us-central1.
  8. Em Intervalo de endereços IP, insira 10.0.4.0/22.
  9. Clique em Criar intervalo de IP secundário. Em Nome do intervalo de sub-rede, insira tier-1-services. Em Intervalo de IPs secundário, insira 10.0.32.0/20.
  10. Clique em Adicionar intervalo de IPs. Em Nome do intervalo de sub-rede, insira tier-1-pods. Em Intervalo de IPs secundário, insira 10.4.0.0/14.
  11. Clique em + Adicionar sub-rede.
  12. Em Nome, insira tier-2.
  13. Em Região, selecione us-central1.
  14. Em Intervalo de endereços IP, insira 172.16.4.0/22.
  15. Clique em Criar intervalo de IP secundário. Em Nome do intervalo de sub-rede, insira tier-2-services. Em Intervalo de IPs secundário, insira 172.16.16.0/20.
  16. Clique em Adicionar intervalo de IPs. Em Nome do intervalo de sub-rede, insira tier-2-pods. Em Intervalo de IPs secundário, insira 172.20.0.0/14.
  17. Clique em Criar.

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.

Estes são os nomes das contas de serviço do GKE nos seus dois projetos de serviço:

  • service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com
  • service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com

Estes são os nomes das contas de serviço das APIs do Google nos dois projetos de serviço:

  • [SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com
  • [SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com

Como ativar a VPC compartilhada e conceder papéis

No projeto host, ative a VPC compartilhada e anexe os dois projetos de serviço ao projeto host. Em seguida, conceda os papéis apropriados para as contas de serviço que pertencem aos projetos de serviço.

gcloud

Ative a VPC compartilhada no projeto host:

gcloud 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]

Receba a política do IAM para a sub-rede da tier-1:

gcloud beta compute networks subnets get-iam-policy tier-1 \
   --project [HOST_PROJECT_ID] \
   --region us-central1

A saída contém um campo etag. Anote o valor de etag.

Crie um arquivo chamado tier-1-policy.yaml com este 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]

em que [ETAG_STRING] é o valor de etag que você anotou anteriormente.

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

gcloud beta compute networks subnets set-iam-policy tier-1 \
    tier-1-policy.yaml \
    --project [HOST_PROJECT_ID] \
    --region us-central1

Em seguida, receba a política do IAM para a sub-rede tier-2:

gcloud beta compute networks subnets get-iam-policy tier-2 \
   --project [HOST_PROJECT_ID] \
   --region us-central1

A saída contém um campo etag. Anote o valor de etag.

Crie um arquivo chamado tier-2-policy.yaml com este 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]

em que [ETAG_STRING] é o valor de etag que você anotou anteriormente.

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

gcloud beta compute networks subnets set-iam-policy tier-2 \
    tier-2-policy.yaml \
    --project [HOST_PROJECT_ID] \
    --region us-central1

Console

Siga estas etapas para ativar a VPC compartilhada, anexar projetos de serviço e conceder papéis:

  1. Acesse a página VPC compartilhada no Console do GCP.
    Acesse a página VPC compartilhada
  2. No seletor de projeto, selecione o projeto host.
  3. Clique em Configurar VPC compartilhada.
    A tela Ativar projeto host é exibida.
  4. Clique em Salvar e continuar.
    A página Selecionar sub-redes é exibida.
  5. Em Modo de compartilhamento, selecione Sub-redes individuais.
  6. Em Sub-redes para compartilhar, marque tier-1 e tier-2. Limpe todas as outras caixas de seleção.
  7. Clique em Continuar.
    A página Dar permissões é exibida.
  8. 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.
  9. Em Acesso ao Kubernetes Engine, marque a opção Ativado.
  10. Clique em Salvar.
    Uma nova página é exibida.
  11. Em Permissões de sub-rede individuais, marque tier-1.
  12. 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].
  13. 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.
  14. No painel central, em Permissões de sub-rede individuais, marque tier- 2 e desmarque a tier-1.
  15. 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].
  16. 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.

A finalidade das etapas anteriores é conceder o papel apropriado do Cloud IAM a quatro contas de serviço. Duas contas de serviço no primeiro projeto de serviço recebem o papel de usuário da rede do Compute na sub-rede tier-1 do projeto host e duas contas de serviço no segundo projeto de serviço recebem o papel de usuário da rede do Compute na sub-rede tier-2 do projeto host.

Resumo dos papéis concedidos em sub-redes

  • A conta de serviço service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com recebe o papel de Usuário da rede do Compute na sub-rede tier-1.

  • A conta de serviço [SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com recebe o papel de Usuário da rede do Compute na sub-rede tier-1.

  • A conta de serviço service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com recebe o papel de Usuário da rede do Compute na sub-rede tier-2.

  • A conta de serviço [SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com recebe o papel de Usuário da rede do Compute na sub-rede tier-2.

Como conceder o papel de usuário do agente de serviço de host

Em cada projeto de serviço, você precisa conceder a função de usuário do agente do serviço de host à conta de serviço do GKE. Isso permite que essa conta no projeto de serviço use a conta de serviço do GKE do projeto host para configurar recursos de rede compartilhados.

A função de usuário do agente do serviço de host é concedida apenas à conta de serviço do projeto de serviço. Ela não pode ser concedida a usuários.

gcloud

Conceda a função de usuário do agente do serviço de host à conta de serviço do GKE do seu primeiro projeto de serviço. 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

Conceda a função de usuário do agente do serviço de host à conta de serviço do GKE do seu segundo projeto de serviço. 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

Console

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

Como verificar sub-redes utilizáveis e intervalos de IP secundários

Ao criar um cluster, é preciso especificar uma sub-rede e os intervalos IP secundários a serem usados para os pods e serviços do cluster. Há vários motivos pelos quais um intervalo de IP pode não estar disponível para uso. Independentemente de você estar criando o cluster com o Console do GCP ou a ferramenta de linha de comando gcloud, especifique os intervalos de IP utilizáveis.

Também é possível listar as sub-redes utilizáveis e os intervalos de IP secundários de um projeto na linha de comando:

gcloud

gcloud beta container subnets list-usable \
    --project [SERVICE_PROJECT_ID] \
    --network-project [HOST_PROJECT_ID]

Se você omitir a opção --project ou --network-project, o comando gcloud usará o projeto padrão da configuração ativa. Como o projeto host e o projeto de rede são distintos, é necessário especificar um destes ou ambos: --project e --network-project.

A saída do comando é semelhante a esta:

PROJECT   REGION       NETWORK      SUBNET          RANGE
xpn-host  us-central1  empty-vpc    empty-subnet    10.0.0.0/21
xpn-host  us-east1     some-vpc     some-subnet     10.0.0.0/19
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ pods-range           │ 10.2.0.0/21   │ usable for pods or services │
    │ svc-range            │ 10.1.0.0/21   │ usable for pods or services │
    └──────────────────────┴───────────────┴─────────────────────────────┘
xpn-host  us-central1  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 │
    └──────────────────────┴────────────────┴─────────────────────────────┘
xpn-host  us-central1  shared-net   tier-1          10.0.4.0/22
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ tier-1-services      │ 10.0.32.0/20  │ unusable                    │
    │ tier-1-pods          │ 10.4.0.0/14   │ usable for pods             │
    │ tier-1-extra         │ 10.8.0.0/14   │ usable for pods or services │
    └──────────────────────┴───────────────┴─────────────────────────────┘

Um intervalo de IP será utilizável para os serviços do novo cluster se ele ainda não estiver em uso. O intervalo 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 IP criados e gerenciados pelo GKE não podem ser usados por seu cluster.

Como criar um cluster no primeiro projeto de serviço

gcloud

Crie um cluster no primeiro projeto de serviço:

gcloud container clusters create tier-1-cluster \
    --project [SERVICE_PROJECT_1_ID] \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/[HOST_PROJECT_ID]/global/networks/shared-net \
    --subnetwork projects/[HOST_PROJECT_ID]/regions/us-central1/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 saída mostra os endereços IP internos dos nós:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.2
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.3
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.4

Console

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

    Acesse o menu do Google Kubernetes Engine

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

  3. Clique em Criar cluster.

  4. Em Nome do cluster, insira tier-1-cluster

  5. Em Tipo de localização, selecione Zonal.

  6. Em Zona, selecione us-central1-a.

  7. Na parte inferior da página, clique em Opções avançadas.

  8. Na seção Nativo de VPC, selecione Ativar nativo de VPC (usando IP do alias).

  9. Desmarque a opção Criar automaticamente intervalos secundários.

  10. Selecione Redes compartilhadas comigo (do projeto host: ...).

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

  12. Em Intervalo CIDR secundário do pod, selecione tier-1-pods.

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

  14. Clique em Criar.

  15. Quando a criação estiver concluída, na lista de clusters, clique em tier-1-cluster.

  16. Em Pools de nós, clique no nome do grupo de instâncias. Por exemplo, gke-tier-1-cluster-default-pool-5c5add1f-grp.

  17. 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.

Como criar um cluster no segundo projeto de serviço

gcloud

Crie um cluster no segundo projeto de serviço:

gcloud container clusters create tier-2-cluster \
    --project [SERVICE_PROJECT_2_ID] \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/[HOST_PROJECT_ID]/global/networks/shared-net \
    --subnetwork projects/[HOST_PROJECT_ID]/regions/us-central1/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 saída mostra os endereços IP internos dos nós:

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.2
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.3
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.4

Console

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

    Acesse o menu do Google Kubernetes Engine

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

  3. Clique em Criar cluster.

  4. Em Nome do cluster, insira tier-2-cluster.

  5. Em Tipo de localização, selecione Zonal.

  6. Em Zona, selecione us-central1-a.

  7. Na parte inferior da página, clique em Opções avançadas.

  8. Na seção Nativo de VPC, selecione Ativar nativo de VPC (usando IP do alias).

  9. Desmarque a opção Criar automaticamente intervalos secundários.

  10. Selecione Redes compartilhadas comigo (do projeto host: ...).

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

  12. Em Intervalo CIDR secundário do pod, selecione tier-2-pods.

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

  14. Clique em Criar.

  15. Quando a criação estiver concluída, na lista de clusters, clique em tier-2-cluster.

  16. Em Pools de nós, clique no nome do grupo de instâncias. Por exemplo, gke-tier-2-cluster-default-pool-5c5add1f-grp.

  17. 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.

Como criar regras de firewall

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

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

Console

  1. Acesse a página Firewalls no Console do GCP.

    Acesse a página Regras de 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 IPs.

  10. Em Intervalos de IPs 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.

Como se conectar a um nó usando o SSH

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 seus nós com SSH:

gcloud compute ssh [NODE_NAME] \
    --project [SERVICE_PROJECT_1_ID] \
    --zone us-central1-a \

em que [NODE_NAME] é o nome de um dos nós.

Console

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

    Acesse a página Regras de firewall

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

  3. Clique em tier-1-cluster.

  4. Em Pools de nós, clique no nome do grupo de instâncias. Por exemplo, gke-tier-1-cluster-default-pool-faf87d48-grp.

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

  6. 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.

Como dar um 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 será bem-sucedido porque os dois nós estão no intervalo 10.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 falhará, porque a regra de firewall não permite o tráfego do Internet Control Message Protocol (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 será 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 em qualquer nó, pod ou serviço no 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

Esta regra permite que o tráfego entre em qualquer nó, pod ou serviço no 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 problemas de permissão, um evento do Kubernetes será gerado para orientar você sobre como fazer as alterações.

Se você quer conceder permissão ao Kubernetes para alterar as regras de firewall, acesse o projeto de host e conceda o papel Compute Security Admin. Se preferir, conceda um papel personalizado com as permissões compute.firewalls.* e compute.networks.updatePolicy à conta de serviço do GKE referente ao projeto de serviço.

Para os balanceadores de carga de entrada, se o Kubernetes não puder alterar as regras do firewall devido à permissão insuficiente, um evento firewallXPNError será emitido em intervalos de alguns minutos. No GLBC 1.4 e superior, é possível silenciar o evento firewallXPNError adicionando a anotação networking.gke.io/suppress-firewall-xpn-error: "true" ao recurso de entrada. 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. Não há configuração especial necessária. No entanto, é preciso garantir que o intervalo do CIDR mestre não se sobreponha a outros intervalos reservados na rede compartilhada.

O número de clusters privados em uma VPC compartilhada é limitado a 25.

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

gcloud

O comando a seguir cria um cluster, private-cluster-vpc, em uma VPC compartilhada predefinida:

gcloud container clusters create private-cluster-vpc \
    --project [PROJECT_ID] \
    --enable-ip-alias \
    --network projects/[HOST_PROJECT]/global/networks/shared-net \
    --subnetwork [SHARED_SUBNETWORK] \
    --cluster-secondary-range-name c0-pods \
    --services-secondary-range-name c0-services \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.0/28

Console

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

    Acesse o menu do GKE

  2. Clique em Criar cluster.

  3. Em Nome do cluster, insira private-cluster-vpc.

  4. Clique em Opções avançadas na parte inferior do menu.

  5. Em Cluster nativo de VPC, marque a caixa de seleção Ativar o cluster nativo de VPC (usando o IP de alias).

  6. No menu suspenso Rede, selecione a rede VPC que você criou anteriormente.

  7. No menu suspenso Sub-rede do nó, selecione a sub-rede compartilhada que você criou anteriormente.

  8. Em Segurança de rede, marque a caixa de seleção cluster particular.

  9. Verifique se a caixa de seleção Acessar mestre usando o endereço IP externo está marcada.

  10. Defina Intervalo de IPs mestre como 172.16.0.16/28.

  11. Configure o cluster como quiser. Em seguida, clique em Criar.

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, você precisa fornecer a sub-rede em que eles estão incluídos. Para reservar um endereço IP nos projetos, use o URL completo do recurso para identificarmos a sub-rede. É possível utilizar o comando a seguir na ferramenta de linha de comando gcloud para reservar um endereço IP interno:

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

Para chamar esse comando, você precisa conceder a permissão compute.subnetworks.use à sub-rede. Conceda ao autor da chamada um papel compute.networkUser na sub-rede ou um papel personalizado com a permissão compute.subnetworks.use no nível do projeto.

Observações sobre intervalos secundários

É possível criar cinco 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. Isso significa que é possível criar apenas dois clusters que usam uma determinada sub-rede.

Problemas conhecidos

Intervalos secundários do CIDR podem estar em uso por outros clusters

Ao criar um cluster VPC compartilhado com o Console do Google Cloud Platform, os intervalos secundários sugeridos para pods e serviços já podem estar em uso por outros clusters. Se um cluster for criado com esses intervalos CIDR, a operação de criação do cluster falhará no estado de erro.

Se você encontrar esse problema, exclua o cluster no estado de erro. Antes de criar o cluster novamente, verifique se os intervalos secundários são utilizáveis pelo novo cluster.

Esse problema será corrigido em versões futuras.

Eventos de firewall para criação do balanceador de carga

Se a conta de serviço do Kubernetes não tiver recebido permissões de gerenciamento de firewall, o controlador de serviço do Kubernetes poderá não criar eventos para as alterações de firewall necessárias. Isso ocorre devido a um problema de permissões do RBAC no Kubernetes versão 1.9 e anteriores. O controlador de serviço não tem a capacidade de gerar eventos.

Para corrigir esse problema, aplique estes arquivos YAML, que contêm políticas de RBAC que permitem que os eventos sejam criados.

Clusters baseados no Kubernetes 1.10 e posteriores já têm essas políticas de RBAC aplicadas.

Como fazer a limpeza

Depois de concluir os exercícios nesta página, siga as etapas a seguir para remover os recursos visando evitar cobranças indesejadas na conta:

Como excluir os clusters

gcloud

gcloud container clusters delete tier-1-cluster \
    --project [SERVICE_PROJECT_1_ID] \
    --zone us-central1-a

gcloud container clusters delete tier-2-cluster \
    --project [SERVICE_PROJECT_2_ID] \
    --zone us-central1-a

Console

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

    Acesse o menu do Google Kubernetes Engine

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

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

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

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

Como desativar a VPC compartilhada

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]

Console

  1. Acesse a página VPC compartilhada no Console do GCP.
    Acesse a página VPC compartilhada
  2. No seletor de projeto, selecione o projeto host.
  3. Clique em Desativar VPC compartilhada.
  4. Digite [HOST_PROJECT_ID] na caixa de texto e clique em Desativar.

Como excluir suas regras de firewall

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]

Console

  1. Acesse a página Firewalls no Console do GCP.

    Acesse a página Regras de firewall

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

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

  4. Clique em Excluir.

Como excluir a rede compartilhada

gcloud

gcloud compute networks subnets delete tier-1 \
    --project [HOST_PROJECT_ID] \
    --region us-central1

gcloud compute networks subnets delete tier-2 \
    --project [HOST_PROJECT_ID] \
    --region us-central1

gcloud compute networks delete shared-net --project [HOST_PROJECT_ID]

Console

  1. Acesse a página Redes VPC no Console do GCP.
    Acesse a página Redes VPC
  2. No seletor de projeto, selecione o projeto host.
  3. Na lista de redes, clique shared-net.
  4. Clique em Excluir rede VPC.

Como remover o papel de Usuário do agente de serviço de host

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

Console

  1. Acesse a página "IAM" no Console do GCP.
    Acessar a página "IAM"
  2. No seletor de projeto, selecione o projeto host.
  3. Na lista de membros, marque 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.
  4. Marque também 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.
  5. Clique em Remover.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine