Como criar um cluster privado

Nesta página, você verá uma explicação sobre como criar um cluster privado no Google Kubernetes Engine (GKE). Em um cluster privado, os nós têm apenas endereços IP RFC 1918 internos. Isso garante que as cargas de trabalho fiquem isoladas da Internet pública. Para mais informações sobre como os clusters privados funcionam, consulte esta página.

Antes de começar

Familiarize-se com os requisitos, restrições e limitações antes de passar para a próxima etapa.

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

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

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

Como usar o gcloud init

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

    gcloud init

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

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

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão:
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Acesso ao mestre

Em clusters privados, o mestre tem um endpoint particular e público. Há três combinações de configuração para controlar o acesso aos endpoints do cluster.

  • Acesso ao endpoint público desativado: isso cria um cluster privado sem acesso de cliente ao endpoint público.
  • Acesso ao endpoint público ativado, redes mestres autorizadas ativadas: isso cria um cluster privado com acesso limitado ao endpoint público.
  • Acesso ao endpoint público ativado, redes mestres autorizadas desativadas: isso cria um cluster privado com acesso irrestrito ao endpoint público.

Consulte Acesso aos endpoints do cluster para uma visão geral das diferenças entre as opções de configuração acima.

Como criar um cluster privado sem acesso de cliente ao endpoint público

Nesta seção, você criará um cluster privado com nós particulares e sem acesso ao endpoint público.

gcloud

Execute este comando:

    gcloud container clusters create private-cluster-0 \
        --create-subnetwork name=my-subnet-0 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --enable-private-endpoint \
        --master-ipv4-cidr 172.16.0.32/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate
    

em que:

  • --enable-master-authorized-networks especifica que o acesso ao endpoint público é restrito aos intervalos de endereços IP que você autorizar;
  • --create-subnetwork name=my-subnet-0 faz com que o GKE crie automaticamente uma sub-rede denominada my-subnet-0;
  • --enable-ip-alias torna o cluster nativo de VPC;
  • --enable-private-nodes indica que os nós do cluster não têm endereços IP externos;
  • --master-ipv4-cidr 172.16.0.32/28 especifica um intervalo RFC 1918 para o mestre. Essa configuração é permanente para esse cluster.

Console

Siga as etapas abaixo:

  1. Acesse o menu do GKE no Console do Google Cloud.

    Acessar o menu do GKE

  2. Clique em Criar cluster.

  3. Escolha o Cluster padrão ou outro modelo apropriado para a carga de trabalho.

  4. Em Nome, insira my-subnet-0.

  5. Clique em Disponibilidade, rede, segurança e outros recursos na parte inferior do menu.

  6. Em Nativo de VPC, marque a caixa de seleção Ativar nativo de VPC (usando o IP de alias). Defina o menu suspenso Rede como default e Sub-rede de nós como default. Dessa forma, o GKE gera uma sub-rede para o cluster.

  7. Em Segurança de rede, marque a caixa de seleção Cluster privado.

  8. Desmarque a caixa de seleção Acessar mestre usando o endereço IP externo.

  9. Defina Intervalo de IP do mestre como 172.16.0.32/28.

  10. A caixa de seleção Ativar redes mestres autorizadas é marcada automaticamente.

  11. Desmarque a caixa de seleção Ativar painel do Kubernetes.

  12. Desmarque a caixa de seleção Emitir um certificado de cliente.

  13. Clique em Criar.

API

Para criar um cluster com um mestre que pode ser acessado publicamente, especifique o campo enablePrivateEndpoint: true no recurso privateClusterConfig.

Nesse momento, os únicos endereços IP que têm acesso ao mestre do cluster são estes:

  • O intervalo principal de my-subnet-0.
  • O intervalo secundário usado para os pods.

Por exemplo, suponha que você tenha criado uma VM no intervalo principal de my-subnet-0. Então, nessa VM, seria possível configurar kubectl para usar o endereço IP interno do mestre.

Se você quiser acessar o mestre do cluster de fora de my-subnet-0, precisará autorizar pelo menos um intervalo de endereços a ter acesso ao endpoint particular.

Suponha que você tenha uma VM na rede padrão, na mesma região que seu cluster, mas não em my-subnet-0.

Por exemplo:

  • my-subnet-0: 10.0.0.0/22
  • intervalo secundário de pods: 10.52.0.0/14
  • endereço da VM: 10.128.0.3

Para autorizar a VM a acessar o mestre, use este comando:

    gcloud container clusters update private-cluster-0 \
        --enable-master-authorized-networks \
        --master-authorized-networks 10.128.0.3/32
    

Como criar um cluster privado com acesso limitado ao endpoint público

Ao criar um cluster privado usando essa configuração, é possível optar por usar uma sub-rede gerada automaticamente ou uma sub-rede personalizada.

Como usar uma sub-rede gerada automaticamente

Nesta seção, você cria um cluster privado nomeado em que o GKE gera automaticamente uma sub-rede para os nós do cluster. Ela já tem o recurso “Acesso privado do Google” ativado. Na sub-rede, o GKE cria automaticamente dois intervalos secundários: um para os pods e outro para os Services.

gcloud

Execute este comando:

    gcloud container clusters create private-cluster-1 \
        --create-subnetwork name=my-subnet-1 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.0/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate
    

em que:

  • --enable-master-authorized-networks especifica que o acesso ao endpoint público é restrito aos intervalos de endereços IP que você autorizar;
  • --create-subnetwork name=my-subnet-1 faz com que o GKE crie automaticamente uma sub-rede denominada my-subnet-1;
  • --enable-ip-alias torna o cluster nativo de VPC;
  • --enable-private-nodes indica que os nós do cluster não têm endereços IP externos;
  • --master-ipv4-cidr 172.16.0.0/28 especifica um intervalo RFC 1918 para o mestre. Essa configuração é permanente para esse cluster.

Console

Siga as etapas abaixo:

  1. Acesse o menu do GKE no Console do Google Cloud.

    Acessar o menu do GKE

  2. Clique em Criar cluster.

  3. Escolha o Cluster padrão ou outro modelo apropriado para a carga de trabalho.

  4. Em Nome, insira my-subnet-1.

  5. Clique em Disponibilidade, rede, segurança e outros recursos na parte inferior do menu.

  6. Em Cluster nativo de VPC, deixe a caixa de seleção Ativar cluster nativo de VPC (usando o IP do alias) marcada. Defina o menu suspenso Rede como default e Sub-rede de nós como default. Dessa forma, o GKE gera uma sub-rede para o cluster.

  7. Em Segurança de rede, marque a caixa de seleção Cluster privado.

  8. Para criar um mestre que seja acessível a partir de intervalos de IP externos autorizados, mantenha a caixa de seleção Acessar mestre com endereço IP externo marcada.

  9. Defina Intervalo de IP do mestre como 172.16.0.0/28.

  10. Mantenha marcada a caixa de seleção Ativar redes mestres autorizadas.

  11. Desmarque a caixa de seleção Ativar painel do Kubernetes.

  12. Desmarque a caixa de seleção Emitir um certificado de cliente.

  13. Clique em Criar.

API

Especifique o campo privateClusterConfig no recurso Cluster da API:

{
      "name": "private-cluster-1",
      ...
      "ipAllocationPolicy": {
        "createSubnetwork": true,
      },
      ...
        "privateClusterConfig" {
          "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
          "enablePrivateEndpoint": boolean # false creates a cluster master with a publicly-reachable endpoint
          "masterIpv4CidrBlock": string # CIDR block for the cluster master
          "privateEndpoint": string # Output only
          "publicEndpoint": string # Output only
      }
    }

Nesse momento, os únicos endereços IP que têm acesso ao mestre do cluster são estes:

  • O intervalo principal de my-subnet-1.
  • O intervalo secundário usado para os pods.

Imagine que você tem um grupo de máquinas fora da sua rede VPC, com endereços no intervalo 203.0.113.0/29. Insira o comando abaixo para autorizar que essas máquinas acessem o endpoint público:

    gcloud container clusters update private-cluster-1 \
        --enable-master-authorized-networks \
        --master-authorized-networks 203.0.113.0/29
    

Agora, os únicos endereços IP com acesso ao mestre do cluster são estes:

  • O intervalo principal de my-subnet-1.
  • O intervalo secundário usado para os pods
  • Os intervalos autorizados, como 203.0.113.0/29

Como usar uma sub-rede personalizada

Nesta seção, você criará um cluster privado chamado private-cluster-2, uma rede denominada my-net-0 e uma sub-rede chamada my-subnet-2 com o intervalo principal 192.168.0.0/20 para os nós do cluster. Sua sub-rede tem dois intervalos de endereços secundários: my-pods-1 para os endereços IP de pods e my-services-1 para os endereços IP de Services.

gcloud

Criar uma rede

Primeiro, crie uma rede para o cluster. O comando a seguir cria uma rede, my-net-0:

    gcloud compute networks create my-net-0 \
        --subnet-mode custom
    

Criar uma sub-rede e intervalos secundários

Em seguida, crie uma sub-rede, my-subnet-2, na rede my-net-0, com intervalos secundários my-pods-2 para pods e my-services-2 para Services:

    gcloud compute networks subnets create my-subnet-2 \
        --network my-net-0\
        --region us-central1 \
        --range 192.168.0.0/20 \
        --secondary-range my-pods-2=10.4.0.0/14,my-services-2=10.0.32.0/20 \
        --enable-private-ip-google-access
    

Criar um cluster privado

Agora, crie um cluster privado, private-cluster-1, usando a rede, a sub-rede e os intervalos secundários criados.

    gcloud container clusters create private-cluster-1 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --network my-net-0 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods-2 \
        --services-secondary-range-name my-services-2 \
        --enable-private-nodes \
        --enable-ip-alias \
        --master-ipv4-cidr 172.16.0.16/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate
    

Console

Criar uma rede, sub-rede e intervalos secundários

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

    Acessar a página "Redes VPC"

  2. Clique em Criar rede VPC.

  3. Em Nome, insira my-net-0.

  4. Certifique-se de que o Modo de criação da sub-rede esteja configurado como Personalizado.

  5. Em Nome, insira my-subnet-2 em Nova sub-rede.

  6. No menu suspenso Região, selecione a região desejada.

  7. Em Intervalo de endereços IP, insira 192.168.0.0/20.

  8. Clique em Criar intervalo de IP secundário. Digite my-services-1 em Nome do intervalo da sub-rede e 10.0.32.0/20 em Intervalo de IP secundário.

  9. Clique em Adicionar intervalo de IP. Digite my-pods-1 em Nome do intervalo da sub-rede e 10.4.0.0/14 em Intervalo de IP secundário.

  10. Em Acesso privado do Google, clique em Ativar.

  11. Clique em Concluir.

  12. Clique em Criar.

Criar um cluster particular

Crie um cluster particular que usa a sub-rede:

  1. Acesse o menu do GKE no Console do Cloud.

    Acessar o menu do GKE

  2. Clique em Criar cluster.

  3. Escolha o Cluster padrão ou outro modelo apropriado para a carga de trabalho.

  4. Em Nome, insira private-cluster-2.

  5. Clique em Disponibilidade, rede, segurança e outros recursos na parte inferior do menu.

  6. Em Cluster nativo de VPC, deixe a caixa de seleção Ativar cluster nativo de VPC (usando o IP do alias) marcada. Caixa de seleção

  7. No menu suspenso Rede, selecione my-net-1.

  8. No menu suspenso Sub-rede de nós, selecione my-subnet-2.

  9. Desmarque a caixa de seleção Criar intervalos secundários automaticamente.

  10. No menu suspenso Intervalo de CIDR secundário do pod, selecione my-pods-1.

  11. No menu suspenso Intervalo de CIDR secundário de Services, selecione my-services-1.

  12. Em Segurança da rede, marque a caixa de seleção Cluster privado.

  13. Defina Intervalo de IP do mestre como 172.16.0.16/28.

  14. Mantenha marcada a caixa de seleção Ativar redes mestres autorizadas.

  15. Desmarque a caixa de seleção Ativar painel do Kubernetes.

  16. Desmarque a caixa de seleção Emitir um certificado de cliente.

  17. Clique em Criar.

Nesse momento, os únicos endereços IP que têm acesso ao mestre do cluster são estes:

  • O intervalo principal de my-subnet-2
  • O intervalo secundário my-pods-1

Suponha que você tenha um grupo de máquinas fora de my-net-1 que tenham endereços no intervalo 203.0.113.0/29. Digite o comando abaixo para autorizar que essas máquinas acessem o endpoint público:

    gcloud container clusters update private-cluster-1 \
        --enable-master-authorized-networks \
        --master-authorized-networks 203.0.113.0/29
    

Nesse momento, os únicos endereços IP que têm acesso ao mestre do cluster são estes:

  • O intervalo principal de my-subnet-2
  • O intervalo secundário my-pods-1
  • Os intervalos autorizados, como 203.0.113.0/29

Como usar o Cloud Shell para acessar um cluster particular

O cluster privado que você criou no exercício anterior, private-cluster-1, tem um endpoint público e tem as redes mestres autorizadas ativadas. Se você quiser usar o Cloud Shell para acessar o cluster, é necessário adicionar o endereço IP público do seu Cloud Shell à lista de redes mestres autorizadas do cluster.

Para fazer isso, siga estas etapas:

  1. Na janela da linha de comando do Cloud Shell, use dig para encontrar o endereço IP externo do seu Cloud Shell:

    dig +short myip.opendns.com @resolver1.opendns.com
        
  2. Adicione o endereço externo do seu Cloud Shell à lista de redes mestres autorizadas do cluster:

    gcloud container clusters update private-cluster-1 \
            --zone us-central1-c \
            --enable-master-authorized-networks \
            --master-authorized-networks existing-auth-nets,shell-IP/32
        

    em que:

    • existente-auth-redes é a lista atual de redes mestres autorizadas. É possível encontrar suas redes mestras autorizadas no console ou executando o comando gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])";
    • shell-IP é o endereço IP externo do Cloud Shell.
  3. Receba as credenciais para poder usar a kubectl para acessar o cluster:

    gcloud container clusters get-credentials private-cluster-1 \
            --zone us-central1-a \
            --project project-id
        

    em que project-id é o ID do projeto.

Agora é possível usar a kubectl no Cloud Shell para acessar seu cluster privado. Por exemplo:

kubectl get nodes
    

Como criar um cluster privado com acesso irrestrito ao endpoint público

Nesta seção, você cria um cluster privado em que qualquer endereço IP pode acessar o principal.

gcloud

Execute este comando:

    gcloud container clusters create private-cluster-2 \
        --create-subnetwork name=my-subnet-3 \
        --no-enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.32/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate
    

em que:

  • --no-enable-master-authorized-networks desativa redes autorizadas para o cluster;
  • --create-subnetwork name=my-subnet-3 faz com que o GKE crie automaticamente uma sub-rede denominada my-subnet-3;
  • --enable-ip-alias torna o cluster nativo de VPC;
  • --enable-private-nodes indica que os nós do cluster não têm endereços IP externos;
  • --master-ipv4-cidr 172.16.0.32/28 especifica um intervalo RFC 1918 para o mestre. Essa configuração é permanente para esse cluster.

Console

Siga as etapas abaixo:

  1. Acesse o menu do GKE no Console do Google Cloud.

    Acessar o menu do GKE

  2. Clique em Criar cluster.

  3. Escolha o Cluster padrão ou outro modelo apropriado para a carga de trabalho.

  4. Em Nome, insira private-cluster-2.

  5. Clique em Disponibilidade, rede, segurança e outros recursos na parte inferior do menu.

  6. Em Nativo de VPC, marque a caixa de seleção Ativar nativo de VPC (usando o IP de alias). Defina o menu suspenso Rede como default e Sub-rede de nós como default. Dessa forma, o GKE gera uma sub-rede para o cluster.

  7. Em Segurança de rede, marque a caixa de seleção Cluster privado.

  8. Desmarque a caixa de seleção Acessar mestre usando o endereço IP externo.

  9. Defina o Intervalo de IP principal como 172.16.0.32/28.

  10. Desmarque a caixa de seleção Ativar redes principais autorizadas automaticamente.

  11. Desmarque a caixa de seleção Ativar painel do Kubernetes.

  12. Desmarque a caixa de seleção Emitir um certificado de cliente.

  13. Clique em Criar.

Outras configurações de cluster privado

Além das configurações anteriores, é possível executar clusters privados com as seguintes configurações.

Como conceder aos nós privados acesso à Internet de saída

Para fornecer acesso à Internet de saída aos seus nós privados, é possível usar o Cloud NAT ou gerenciar seu próprio gateway NAT.

Como criar um cluster privado em uma rede VPC compartilhada

Para saber como criar um cluster privado em uma rede VPC compartilhada, consulte a documentação da VPC compartilhada.

Como implantar um aplicativo de contêiner do Windows Server em um cluster privado

Para saber como implantar um aplicativo de contêiner do Windows Server em um cluster privado, consulte a documentação do pool de nós do Windows.

Como rotear entre a VPC local/no cluster e o mestre do cluster

Ao criar um cluster privado do GKE com um endpoint mestre particular, o mestre do cluster fica inacessível na Internet pública, mas precisa ser acessível às ferramentas do lado do cliente, como kubectl. Para ativar o tráfego entre o mestre do cluster e a rede local, são necessárias rotas entre a rede local e a rede VPC do Google que hospeda o mestre do cluster.

Diagrama mostrando o roteamento entre a VPC local e o mestre de cluster

A VPC do Google exporta automaticamente a rota até o CIDR mestre para a VPC, conectada à sua rede local, usando o Cloud VPN ou o Cloud Interconnect. No entanto, a rota até o ambiente local também precisa ser exportada da VPC para a VPC do Google.

Para compartilhar as rotas, ative a sinalização --export-custom-routes no peering entre sua VPC e a VPC de propriedade do Google.

  1. Identifique o peering entre a VPC para seu cluster e a VPC de propriedade do Google:

        gcloud container clusters describe cluster-name
        

    A resposta ao comando inclui o campo privateClusterConfig.peeringName do cluster. Esse é o nome do peering entre seu cluster e a VPC de propriedade do Google. Por exemplo:

        privateClusterConfig:
        enablePrivateNodes: true
        masterIpv4CidrBlock: 172.16.1.0/28
        peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
        privateEndpoint: 172.16.1.2
        publicEndpoint: 34.68.128.12
        
  2. Ative --export-custom-routes no peering:

        gcloud compute networks peerings update peering --network network \
           --export-custom-routes
        

    em que peering é o valor de privateClusterConfig.peeringName identificado na etapa anterior e network é o nome da VPC.

    Essa sinalização faz com que network divulgue rotas para a VPC do Google em que seu mestre de cluster está localizado. Na próxima etapa, você verá como divulgar a rota da VPC para a VPC do Google no ambiente local.

  3. A rota para o CIDR do mestre do cluster também precisa ser divulgada da VPC para o ambiente local. É possível fazer isso de duas maneiras:

    • Técnica recomendada: divulgue a rota até a sub-rede mestre como uma rota personalizada sobre o eBGP do Cloud Router. Consulte Como divulgar intervalos de IP personalizados para mais informações. Essa técnica é recomendada porque as rotas divulgadas são retiradas se o eBGP não estiver disponível, o que ajuda no tráfego na lista negra.

    • Provisione uma rota estática no roteador local ou dispositivo de borda para o Google Cloud.

Como verificar se a exportação de rota personalizada está ativada

Use este comando para verificar se a opção --export-custom-routes está ativada no peering entre sua VPC e a VPC de propriedade do Google:

    gcloud compute networks peerings list
    

A resposta ao comando lista seus peerings rede do Compute Engine. Localize o peering com o nome que você encontrou na primeira etapa do procedimento acima e verifique se a coluna EXPORT_CUSTOM_ROUTES é True e a coluna STATE é ACTIVE.

Como desativar a exportação de rota personalizada

Para desativar a exportação de rota personalizada da sua VPC:

    gcloud compute networks peerings update peering --network network --no-export-custom-routes
    

em que:

  • peering é o valor de privateClusterConfig.peeringName;
  • network é o nome da VPC.

Para encontrar o peeringName, consulte a primeira etapa das instruções acima para ativar a exportação de rota personalizada.

Verificar que os nós não têm IPs externos

Depois de criar um cluster privado, verifique se os nós dele não têm endereços IP externos.

gcloud

Para verificar se os nós do cluster não têm endereços IP externos, execute o seguinte comando:

kubectl get nodes --output wide

A coluna EXTERNAL-IP da resposta está vazia:

STATUS ... VERSION        EXTERNAL-IP  OS-IMAGE ...
    Ready      v.8.7-gke.1                 Container-Optimized OS from Google
    Ready      v1.8.7-gke.1                Container-Optimized OS from Google
    Ready      v1.8.7-gke.1                Container-Optimized OS from Google

Console

Para verificar se os nós do cluster não têm endereços IP externos, siga estas etapas:

  1. Acesse o menu do GKE no Console do Cloud.

    Acessar o menu do GKE

  2. Na lista de clusters, clique no cluster desejado.

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

  4. Na lista de instâncias, verifique se as instâncias não têm endereços IP externos.

Como visualizar a sub-rede do cluster e os intervalos de endereços secundários

Depois de criar um cluster privado, exiba os intervalos de endereços de sub-rede e secundários que você ou o GKE provisionaram para o cluster.

gcloud

Listar todas as sub-redes

Para listar as sub-redes na rede do cluster, execute o seguinte comando:

gcloud compute networks subnets list --network network

em que network é a rede do cluster privado. Se você criou o cluster com uma sub-rede criada automaticamente, use default.

Na resposta ao comando, localize o nome da sub-rede do cluster.

Visualizar sub-rede do cluster

Use o comando para receber informações sobre a sub-rede criada automaticamente:

gcloud compute networks subnets describe subnet-name

em que subnet-name é o nome da sub-rede.

A resposta mostra o intervalo de endereços principal para nós, o primeiro campo ipCidrRange e os intervalos secundários para pods e Services, em secondaryIpRanges:

...
    ipCidrRange: 10.0.0.0/22
    kind: compute#subnetwork
    name: gke-private-cluster-1-subnet-163e3c97
    ...
    privateIpGoogleAccess: true
    ...
    secondaryIpRanges:
    - ipCidrRange: 10.40.0.0/14
      rangeName: gke-private-cluster-1-pods-163e3c97
    - ipCidrRange: 10.0.16.0/20
      rangeName: gke-private-cluster-1-services-163e3c97
    ...
    

Console

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

    Acessar a página "Redes VPC"

  2. Clique no nome da sub-rede. Por exemplo, gke-private-cluster-0-subnet-163e3c97.

  3. Em Intervalo de endereço IP, é possível ver o intervalo de endereço principal da sub-rede. Esse é o intervalo usado para nós.

  4. Em Intervalos de IP secundário, é possível ver o intervalo de endereços IP para pods e o intervalo para Services.

Como ver os endpoints de um cluster privado

Para visualizar os endpoints de clusters privados, use a ferramenta de linha de comando gcloud ou o Console do Cloud.

gcloud

Execute este comando:

    gcloud container clusters describe cluster-name

A saída mostra tanto o endpoint particular quanto o público:

    ...
    privateClusterConfig:
    enablePrivateEndpoint: true
    enablePrivateNodes: true
    masterIpv4CidrBlock: 172.16.0.32/28
    privateEndpoint: 172.16.0.34
    publicEndpoint: 35.239.154.67
    

Console

Siga as etapas abaixo:

  1. Acesse o menu do GKE no Console do Cloud.

    Acessar o menu do GKE

  2. Na lista, clique no cluster pretendido.

  3. Na guia Detalhes, em Cluster, procure o campo Endpoint.

Como extrair imagens de contêiner de um registro de imagem

Em um cluster privado, o ambiente de execução de contêiner pode extrair imagens do Container Registry. No entanto, não é possível extrair imagens de qualquer outro registro de imagem de contêiner na Internet. Isso ocorre porque os nós em um cluster privado não têm endereços IP externos. Portanto, por padrão, eles não podem se comunicar com serviços fora da rede do Google.

Os nós de um cluster privado poderão se comunicar com os Serviços do Google, como o Container Registry, se estiverem em uma sub-rede com o Acesso privado do Google ativado.

Os comandos a seguir criam um Deployment que extrai uma imagem de amostra de um repositório do Container Registry pertencente ao Google:

    kubectl run hello-deployment --image gcr.io/google-samples/hello-app:2.0
    

Como adicionar regras de firewall para casos de uso específicos

Esta seção explica como adicionar uma regra de firewall a um cluster privado. Por padrão, as regras de firewall restringem o mestre do cluster a apenas iniciar conexões TCP com os nós nas portas 443 (HTTPS) e 10250 (kubelet). Para alguns recursos do Kubernetes, talvez seja necessário adicionar regras de firewall para permitir o acesso em outras portas. Por exemplo, no Kubernetes 1.9 e anteriores, kubectl top acessa heapster, que precisa de uma regra de firewall para permitir conexões TCP na porta 8080. Para conceder esse acesso, adicione regras de firewall.

Adicionar uma regra de firewall permite o tráfego do mestre do cluster para todos os itens a seguir:

  • A porta especificada de cada nó (hostPort).
  • a porta especificada de cada pod em execução nesses nós
  • A porta especificada de cada Service em execução nesses nós.

Para mais informações sobre as regras de firewall, consulte a página relacionada na documentação do Cloud Load Balancing.

Para adicionar uma regra de firewall a um cluster privado, você precisa registrar o bloco CIDR do mestre do cluster e o destino usado. Depois de registrá-los, é possível criar a regra.

Etapa 1: Ver o bloco CIDR do mestre do cluster

Você precisa do bloco CIDR do mestre do cluster para adicionar uma regra de firewall.

gcloud

Execute este comando:

    gcloud container clusters describe cluster-name
    

em que cluster-name é o nome do cluster privado.

Na resposta ao comando, anote o valor no campo masterIpv4CidrBlock.

Console

  1. Acesse o menu do GKE no Console do Cloud.

    Acessar o menu do GKE

  2. Selecione o cluster pretendido.

Na guia Detalhes, em Cluster, anote o valor do campo Intervalo de endereços principal.

Etapa 2: Ver as regras de firewall atuais

É necessário especificar o destino (neste caso, os nós de destino) que as regras de firewall atuais do cluster usam.

gcloud

Execute este comando:

    gcloud compute firewall-rules list \
        --filter 'name~^gke-cluster-name' \
        --format 'table(
            name,
            network,
            direction,
            sourceRanges.list():label=SRC_RANGES,
            allowed[].map().firewall_rule().list():label=ALLOW,
            targetTags.list():label=TARGET_TAGS
        )'

Na saída do comando, anote o valor no campo Destinos.

Console

Siga as etapas abaixo:

  1. Acesse o menu "Regras de firewall" no Console do Cloud

    Acessar o menu "Regras de firewall"

  2. Preencha a caixa Recursos do filtro com gke-cluster-name.

Nos resultados, anote o valor no campo Destinos.

Etapa 3: Adicionar uma regra de firewall

gcloud

Execute este comando:

    gcloud compute firewall-rules create firewall-rule-name \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges master-CIDR-block \
        --rules protocol:port \
        --target-tags target

em que:

  • firewall-rule-name é o nome escolhido para a regra de firewall;
  • master-CIDR-block é o bloco CIDR do mestre de cluster (masterIpv4CidrBlock) coletado anteriormente;
  • protocol:port é a porta pretendida e o respectivo protocolo, tcp ou udp;
  • target é o valor de destino (Targets) que você coletou anteriormente.

Console

Siga as etapas abaixo:

  1. Acesse o menu "Regras de firewall" no Console do Cloud

    Acessar o menu "Regras de firewall"

  2. Clique em Criar regra de firewall.

  3. Preencha a caixa Nome com o nome desejado para a regra de firewall.

  4. No menu suspenso Rede, selecione a rede desejada.

  5. Em Direção de tráfego, clique em Entrada.

  6. Em Ação em relevância, clique em Permitir.

  7. No menu suspenso Destino, selecione Tags de destino especificado.

  8. Preencha a caixa Tags de destino com o valor de destino coletado anteriormente.

  9. No menu suspenso Filtro de origem, selecione Intervalos de IP.

  10. Preencha a caixa Intervalos de IP de origem com o bloco CIDR do mestre do cluster coletado anteriormente.

  11. Em Protocolos e portas, clique em Protocolos e portas especificados, marque a caixa do protocolo relevante (TCP ou UDP) e preencha a caixa com a porta pretendida.

  12. Clique em Criar.

Como proteger um cluster privado com o VPC Service Controls

Para proteger ainda mais os clusters privados do GKE, use o VPC Service Controls.

Ele protege ainda mais os clusters privados do GKE para reduzir o risco de exfiltração de dados. Ao usá-lo, é possível adicionar projetos a perímetros de serviço. Isso protege recursos e serviços contra solicitações que vêm de fora desses perímetros.

Para mais informações sobre os perímetros de serviço, consulte a página Configuração do perímetro de serviço na documentação do VPC Service Controls.

Se você usa o Container Registry com o cluster privado do GKE, é necessário realizar outras etapas para usar esse cluster com o VPC Service Controls. Para mais informações, consulte a página Como configurar o Container Registry para clusters privados do GKE.

Reutilização de peering de VPC

Todos os clusters privados criados após 15 de janeiro de 2020 reutilizam as conexões do peering da rede VPC.

Todos os clusters privados criados antes de 15 de janeiro de 2020 usam uma conexão exclusiva de peering da rede VPC. Cada rede VPC faz peering com até 25 outras redes VPC, o que significa que para esses clusters há um limite de no máximo 25 clusters privados por rede, supondo que os peerings não estejam sendo usados para outros fins.

Este recurso não é compatível com versões anteriores. Para habilitar a reutilização do peering da rede VPC em clusters privados 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.

Cada local será compatível com até 75 clusters privados se eles tiverem a reutilização de peering de VPC ativada. Zonas e regiões são tratadas como locais separados. Por exemplo, é possível criar até 75 clusters de zonas privados em us-east1-a e outros 75 clusters de regiões privados em us-east1. Isso também se aplica se você estiver usando clusters privados em uma rede VPC compartilhada. O número máximo de conexões com uma rede VPC é 25, o que significa que só é possível criar clusters privados usando 25 locais únicos.

É possível verificar se o cluster privado reutiliza as conexões do peering de VPC.

gcloud

    gcloud container clusters describe cluster-name \
    --zone=zone-name \
    --format="value(privateClusterConfig.peeringName)"
    

Se o cluster estiver usando novamente as conexões de peering de VPC, a resposta começará com gke-n. Por exemplo, gke-n34a117b968dee3b2221-93c6-40af-peer.

Console

Verifique a linha de Peering de VPC na página de detalhes do cluster. Se o cluster estiver usando novamente as conexões de peering de VPC, a resposta começará com gke-n. Por exemplo, gke-n34a117b968dee3b2221-93c6-40af-peer.

Como fazer a limpeza

Depois de concluir as tarefas nesta página, siga estas etapas para remover os recursos e evitar cobranças indesejadas na conta:

Excluir os clusters

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1

Console

  1. Acesse o menu do GKE no Console do Cloud.

    Acessar o menu do GKE

  2. Selecione cada cluster.

  3. Clique em Excluir.

Excluir a rede

gcloud

gcloud compute networks delete net-0

Console

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

    Acessar a página "Redes VPC"

  2. Na lista de redes, em net-0, clique no ícone da lixeira.

  3. Ao lado de cada sub-rede, clique no ícone da lixeira.

Requisitos, restrições e limitações

Os clusters particulares têm os seguintes requisitos:

Clusters privados têm as seguintes restrições:

  • Não é possível converter um cluster não particular atual em um cluster particular.
  • Para clusters executando versões anteriores à 1.14.4, um mestre do cluster, um nó, um pod ou um intervalo de IP do Service não pode se sobrepor a 172.17.0.0/16.
  • Para clusters executando a versão 1.14.4 ou posterior, é possível usar 172.17.0.0/16 para seu intervalo de IP mestre. No entanto, um nó, um pod ou um intervalo de IP do Service não podem se sobrepor a 172.17.0.0/16.
  • Algumas ações fazem com que o cluster privado pare de funcionar, como excluir o peering de VPC entre o mestre e os nós do cluster, excluir as regras de firewall que permitem o tráfego de entrada do mestre do cluster para nós na porta 10250 ou excluir a rota padrão para o gateway de Internet padrão. Para que um cluster privado apareça novamente após a exclusão da rota padrão, você precisa provisionar o VIP restrito estaticamente.
  • É possível adicionar até 50 redes autorizadas (blocos CIDR na lista de permissões) em um projeto. Para mais informações, consulte Adicionar uma rede autorizada a um cluster atual.

Clusters privados têm as seguintes limitações:

  • O tamanho do bloco RFC 1918 do mestre do cluster precisa ser /28.
  • O GKE é capaz de detectar a sobreposição com o bloco de endereços do mestre do cluster, mas não consegue detectá-la dentro de uma rede VPC compartilhada.
  • Os nós em um cluster privado não têm acesso de saída à Internet pública, mas têm acesso limitado a APIs e serviços do Google.
  • O endereço IP particular do mestre em um cluster regional só pode ser acessado via sub-redes dentro da mesma região ou de ambientes locais conectados à mesma região.
  • Todos os clusters privados criados antes de 15 de janeiro de 2020 têm um limite de no máximo 25 clusters por rede, supondo que os peerings não estejam sendo usados para outros fins. Consulte reutilização de peering de VPC para mais informações.

Como solucionar problemas

Veja nas seções a seguir como resolver problemas comuns relacionados a clusters privados.

Cluster se sobrepõe a um peering ativo

Sintomas
A tentativa de criar um cluster privado retorna um erro como Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network..
Causas possíveis
Você escolheu um CIDR mestre sobreposto.
Resolução
Exclua e recrie o cluster usando um CIDR mestre diferente.

Não é possível acessar o cluster

Sintomas
Depois de criar um cluster privado, a tentativa de executar comandos kubectl no cluster retorna um erro, como Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out ou Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Causas possíveis
A kubectl é incapaz de se comunicar com o mestre do cluster.
Resolução
Adicione redes autorizadas ao cluster para colocar os endereços IP da sua rede na lista de permissões.

Não é possível criar o cluster devido à sinalização omitida

Sintomas
gcloud container clusters create retorna um erro como Cannot specify --enable-private-endpoint without --enable-private-nodes.
Causas possíveis
Você não especificou uma sinalização necessária.
Resolução
Especifique as sinalizações necessárias. Não é possível ativar um endpoint particular para o mestre do cluster sem também ativar nós privados.

Não é possível criar o cluster devido à sobreposição do bloco CIDR IPv4 mestre

Sintomas
gcloud container clusters create retorna um erro como The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.
Causas possíveis
Você especificou um bloco CIDR mestre que se sobrepõe a uma sub-rede na VPC.
Resolução
Especifique um bloco CIDR para --master-ipv4-cidr que não se sobreponha a uma sub-rede atual.

Não é possível criar uma sub-rede

Sintomas
Quando você tenta criar um cluster privado com uma sub-rede automática ou tenta criar uma sub-rede personalizada, pode encontrar o seguinte erro: An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.
Causas possíveis
O intervalo de CIDR mestre especificado se sobrepõe a outro intervalo de IPs no cluster. Isso também pode ocorrer se você excluiu recentemente um cluster privado e está tentando criar um novo usando o mesmo CIDR mestre.
Resolução
Tente usar um intervalo de CIDR diferente.

Não é possível extrair a imagem do Hub Docker público

Sintomas
Um pod em execução no cluster exibe um aviso em kubectl describe, como Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).
Causas possíveis
Os nós no cluster privado não têm acesso de saída à Internet pública. Eles têm acesso limitado a APIs e serviços do Google, incluindo o Container Registry.
Resolução
Não é possível buscar imagens diretamente do Docker Hub. Em vez disso, use imagens hospedadas no Container Registry. Observe que, embora o espelho Docker Hub do Container Registry possa ser acessado de um cluster privado, ele não pode ser o único a ser usado. O espelho é apenas um cache, portanto, as imagens são periodicamente removidas, e um cluster privado não pode voltar para o Docker Hub.

A seguir