Como configurar clusters com a VPC compartilhada

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 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 no modelo de VPC compartilhada.

Com a VPC compartilhada, determinadas cotas e limites são aplicados. 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.

Nos exemplos deste guia, usamos nomes e intervalos de endereços específicos para ilustrar procedimentos gerais. Se quiser, você pode 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

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

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 ferramenta gcloud ou o Console do Google Cloud.

Console

  1. Acesse a Página inicial no Console do Google Cloud.

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

Como ativar a API Google Kubernetes Engine nos projetos

Antes de continuar com os exercícios deste guia, 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 tarefas restantes neste guia, cada um dos seus projetos precisa ter uma conta de serviço do GKE.

Ative a API Google Kubernetes Engine usando o Console do Google Cloud ou a ferramenta gcloud.

Console

  1. Acesse o painel APIs e serviços no Console do Cloud.
    Acessar 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 por Kubernetes Engine API. Clique no cartão API do Kubernetes Engine e clique 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 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

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

Console

  1. Acesse a página "Redes VPC" no Console do Cloud.
    Acessar a página "Redes VPC"
  2. No seletor de projeto, escolha 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, para Nome, digite tier-1.
  7. Em Região, selecione us-central1.
  8. Em Intervalo de endereços IP, insira 10.0.4.0/22.
  9. Clique em Criar um intervalo de IP secundário. Digite tier-1-services em Nome do intervalo da sub-rede e 10.0.32.0/20 em Intervalo de IP secundário.
  10. Clique em Adicionar intervalo de IP. Digite tier-1-pods em Nome do intervalo da sub-rede e 10.4.0.0/14 em Intervalo de IP secundário.
  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 um intervalo de IP secundário. Digite tier-2-services em Nome do intervalo da sub-rede e 172.16.16.0/20 em Intervalo de IP secundário.
  16. Clique em Adicionar intervalo de IP. Digite tier-2-pods em Nome do intervalo da sub-rede e 172.20.0.0/14 em Intervalo de IP secundário.
  17. 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 us-central1 \
    --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 us-central1 \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

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:

  1. No projeto host, ative a VPC compartilhada.
  2. Anexe seus dois projetos de serviço ao projeto host.
  3. 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-rede tier-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-rede tier-2 do projeto host.

Console

Execute 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 Cloud.

    Acessar a página "VPC compartilhada"

  2. No seletor de projeto, escolha 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 Conceder 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 individual, 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-project2-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.

gcloud

  1. Ative a VPC compartilhada no projeto host:

    gcloud 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 us-central1
    

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

  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 us-central1
    
  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 us-central1
    

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

  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 us-central1
    

Se você quiser que o cluster do GKE crie e gerencie os recursos de firewall no projeto host, execute uma das seguintes tarefas:

  • No projeto host, conceda o papel Compute Security Admin.
  • Conceda um papel personalizado com as permissões compute.firewalls.* e compute.networks.updatePolicy à conta de serviço do GKE do projeto de serviço. Para saber mais, consulte a seção Como criar regras de firewall adicionais.

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 de rede 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, em que service-project-num é o número do projeto de serviço:

service-service-project-num@container-engine-robot.iam.gserviceaccount.com

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 Cloud, não precisará conceder a função de Usuário do agente de serviço de host explicitamente. Isso foi feito automaticamente quando você usou o Console do 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 à 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
    
  2. 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 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 para um intervalo de IPs não estar disponível para uso. Se você está criando o cluster com o Console do Cloud ou a ferramenta de linha de comando gcloud, especifique intervalos de IPs utilizáveis.

Um intervalo de IP será utilizável para os serviços do novo cluster se esse intervalo 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.

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

gcloud

gcloud 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 sua configuração ativa. Como o projeto host e o projeto de rede são distintos, especifique --project e/ou --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 │
    └──────────────────────┴───────────────┴─────────────────────────────┘

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 o gcloud ou o Console do Google Cloud.

Console

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

    Acessar o menu do Google Kubernetes Engine

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

  3. Clique no botão Criar cluster.

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

  5. Em Tipo de local, selecione Zonal.

  6. Na lista suspensa Zona, selecione us-central1-a.

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

  8. Selecione Ativar roteamento de tráfego nativo de VPC (usa IP do alias).

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

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

  11. Em Rede, selecione shared-net.

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

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

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

  15. Clique em Criar.

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

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

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

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 ferramenta gcloud ou o Console do Google Cloud.

Console

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

    Acessar o menu do Google Kubernetes Engine

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

  3. Clique no botão Criar cluster.

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

  5. Em Tipo de local, selecione Zonal.

  6. Na lista suspensa Zona, selecione us-central1-a.

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

  8. Selecione Ativar roteamento de tráfego nativo de VPC (usa IP do alias).

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

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

  11. Em Rede, selecione shared-net.

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

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

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

  15. Clique em Criar.

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

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

  18. 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 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 resposta 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

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ó

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 de firewalls no Console do Cloud.

    Acessar a página "Regras de firewall"

  2. No seletor de projeto, escolha 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

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

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

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

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.

Como atualizar a regra de firewall para dar ping 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.

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 (em inglês) 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, execute uma das seguintes ações:

  • No projeto host, conceda o papel Compute Security Admin.
  • Conceda um papel personalizado com as permissões compute.firewalls.* e compute.networks.updatePolicy à conta de serviço do GKE do projeto de serviço.

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. Não há configuração especial necessária. No entanto, é preciso garantir que o intervalo de CIDR do plano de controle (mestre) não se sobreponha 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

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

    Acessar o menu do Google Kubernetes Engine

  2. Clique no botão Criar cluster.

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

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

  5. Clique em Cluster particular.

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

  7. Defina Intervalo de IP principal como 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. Verifique se a caixa de seleção Ativar roteamento de tráfego nativo de VPC (usa IP do alias) está marcada.

  11. Configure o cluster como quiser.

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

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 identificar a sub-rede.

Para reservar um endereço IP interno, use o comando a seguir na ferramenta de linha de comando gcloud:

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

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

    Acessar o menu do 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 \
    --zone us-central1-a

gcloud container clusters delete tier-2-cluster \
    --project service-project-2-id \
    --zone us-central1-a

Como desativar a VPC compartilhada

Desative a VPC compartilhada no projeto host.

Console

  1. Acesse a página "VPC compartilhada" no Console do Cloud.

    Acessar a página "VPC compartilhada"

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

  3. Clique em Desativar VPC compartilhada.

  4. Digite o host-project-id na caixa de texto 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

  1. Acesse a página de firewalls no Console do Cloud.

    Acessar a página "Regras de firewall"

  2. No seletor de projeto, escolha 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

Como excluir a rede compartilhada

Exclua a rede compartilhada criada.

Console

  1. Acesse a página "Redes VPC" no Console do Cloud.

    Acessar a página "Redes VPC"

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

  3. Na lista de redes, selecione shared-net.

  4. Clique em Excluir rede VPC.

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

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

  1. Acesse a página "IAM" no Console do Cloud.

    Acessar a página "IAM"

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

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

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

  5. Clique em Remover.

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:service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com \
       --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:service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com \
       --role roles/container.hostServiceAgentUser
    

Problemas conhecidos

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 consegue gerar eventos.

Para corrigir esse problema, aplique estes arquivos YAML (em inglês). Eles contêm políticas de RBAC que permitem a criação dos eventos.

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

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
Motivos possíveis:

  • 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 Google Kubernetes Engine 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 Google Kubernetes Engine do projeto de serviço não tem o papel de usuário de agente de serviço de host no projeto host.

Para corrigir o problema: determine se a conta de serviço do Google Kubernetes Engine 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 Google Kubernetes Engine do projeto host e concede à conta de serviço do Google Kubernetes Engine do projeto host 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 Google Kubernetes Engine 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 ou a vinculação de papel do Google Kubernetes Engine, desative e reative a API Kubernetes Engine. Para mais informações, consulte Solução de problemas do Google Kubernetes Engine.

A seguir