Criar um cluster

Nesta página, descrevemos como criar um cluster do GKE na AWS. Também é possível criar uma VPC e um cluster com o Terraform.

Antes de começar

Antes de criar um cluster, conclua os pré-requisitos. Especificamente, é necessário fornecer os seguintes recursos:

  • Uma VPC da AWS em que o cluster será executado.
  • Até três sub-redes da AWS para as três réplicas do plano de controle. Cada um precisa estar em uma zona de disponibilidade diferente da AWS.
  • O papel do IAM da AWS que o GKE na AWS assume ao gerenciar o cluster. Isso requer um conjunto específico de permissões do IAM.
  • Chaves CMK simétricas do KMS para criptografia e configuração de dados do cluster (etcd) em repouso.
  • O perfil da instância do IAM da AWS para cada réplica do plano de controle. Isso requer um conjunto específico de permissões do IAM.
  • Um par de chaves SSH do EC2 (opcional) se você precisar de acesso SSH às instâncias do EC2 que executam cada réplica do plano de controle.

É sua responsabilidade criar e gerenciar esses recursos, que podem ser compartilhados entre todos os clusters do GKE. Todos os outros recursos da AWS com escopo de cluster são gerenciados pelo GKE na AWS.

Selecionar intervalos CIDR para o cluster

Ao criar um cluster no GKE na AWS, você precisa fornecer intervalos de endereços IPv4 para usar em pods e serviços.

Esses intervalos de IP são especificados usando a notação de roteamento entre domínios sem classe (CIDR), por exemplo, 100.64.0.0/16.

Recomendamos os seguintes intervalos CIDR para serviços e pods:

  • Serviços: 100.64.0.0/16
  • Pods: 100.96.0.0/11

Esses intervalos são grandes o suficiente para que você possa expandir seu cluster sem problemas.

Veja mais detalhes nas seções a seguir.

Detalhes sobre a seleção de intervalos

O GKE na AWS usa uma rede de sobreposição para pods e serviços. Portanto, os intervalos de IP dessas redes não precisam ser roteáveis na VPC. Todos os intervalos de IP usados precisam ter disponibilidade garantida. Para mais informações, consulte Dataplane V2.

  • Os intervalos de IPs de pods e serviços podem se sobrepor à rede VPC, desde que os intervalos de IPs de sub-rede do pool de nós ou do plano de controle não sejam incluídos.

  • O intervalo de IP do pod e do serviço precisa estar em um dos seguintes intervalos de IP particulares:

    • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — Endereços IP privados (RFC 1918)
    • Espaço de endereços compartilhado 100.64.0.0/10RFC 6598
    • Atribuições do protocolo IETF 192.0.0.0/24RFC 6890
    • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — Documentação (RFC 5737)
    • Retransmissão IPv6 para IPv4 (obsoleta) 192.88.99.0/24RFC 7526
    • Teste de comparativo de mercado 198.18.0.0/15RFC 2544

Recomendamos intervalos de IP dentro de 100.64.0.0/10 (RFC 6598). Esse intervalo é liberado para NAT de nível de operadora, que provavelmente não é usado na VPC.

O exemplo a seguir é uma configuração válida, já que as redes de pods, serviços e nós não se sobrepõem (a VPC usa endereços IP privados RFC 1918, enquanto as redes de pods e serviços são sobrepostas em IPs privados RFC 6598).

  • Rede VPC: 10.0.0.0/16, 172.16.1.0/24 e 172.16.2.0/24
  • Rede do pod: 100.65.0.0/16
  • Rede de serviços: 100.66.0.0/16

Veja a seguir uma configuração válida, mesmo com as redes de pods e serviços sobrepostas pela rede VPC, já que não há sobreposição com as réplicas do plano de controle.

  • Rede VPC: 10.0.0.0/16
  • Rede do pod: 10.0.1.0/24
  • Rede de serviços: 10.0.2.0/24
  • Sub-redes da réplica do plano de controle: 10.0.3.0/24, 10.0.4.0/24, 10.0.5.0/24

A configuração a seguir é inválida porque o intervalo de IP do pod se sobrepõe à rede do plano de controle. Essa sobreposição pode impedir que as cargas de trabalho se comuniquem com a réplica do plano de controle na rede VPC:

  • Rede VPC: 10.0.0.0/16
  • Rede do pod: 10.0.1.0/24
  • Rede de serviços: 10.1.0.0/24
  • Sub-redes da réplica do plano de controle: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Detalhes sobre o intervalo de endereços do pod

O Kubernetes aloca endereços para objetos de pod do intervalo de endereços do pod. O intervalo do pod de um cluster é dividido em intervalos menores para cada nó. Quando um pod é programado em um nó específico, o Kubernetes atribui um endereço IP de pod do intervalo do nó.

Para calcular o tamanho do intervalo de endereços de pods, é preciso estimar o número de nós que você quer no cluster e o número de pods que você quer executar em cada nó.

A tabela a seguir fornece recomendações de tamanho para intervalos de CIDR de pod com base no número de nós e pods que você pretende executar.

Tabela de intervalos de endereços de pods

Intervalo de endereços do pod Máximo de endereços de IP de pod Máximo de nós Máximo de pods
/24
Menor intervalo de endereços de pod possível		 256 endereços 1 nó 110 pods
/23 512 endereços 2 nós 220 pods
/22 1.024 endereços 4 nós 440 pods
/21 2.048 endereços 8 nós 880 pods
/20 4.096 endereços 16 nós 1.760 pods
/19 8.192 endereços 32 nós 3.520 pods
/18 16.384 endereços 64 nós 7.040 pods
/17 32.768 endereços 128 nós 14.080 pods
/16 65.536 endereços 256 nós 28.160 pods
/15 131.072 endereços 512 nós 56.320 pods
/14 262.144 endereços 1.024 nós 112.640 pods

Detalhes sobre o intervalo de endereços do serviço

O Kubernetes aloca endereços IP virtuais para objetos de serviço, por exemplo, desse tipo de balanceador de carga.

Para calcular o tamanho do intervalo de endereços de Serviço, faça uma estimativa do número de serviços que você quer no cluster.

A tabela a seguir fornece recomendações de tamanho para intervalos CIDR de serviço com base no número de serviços que você pretende executar.

Tabela de intervalos de endereços de serviço

Intervalo de endereços do serviço Número máximo de Serviços
/27
Menor intervalo de endereços de Serviço possível		 32 Serviços
/26 64 Serviços
/25 128 Serviços
/24 256 Serviços
/23 512 Serviços
/22 1.024 Serviços
/21 2.048 Serviços
/20 4.096 Serviços
/19 8.192 Serviços
/18 16.384 Serviços
/17 32.768 Serviços
/16
O maior intervalo de endereços de Serviço possível		 65.536 Serviços

Selecionar o projeto host de frota

Fleets são um conceito do Google Cloud para organizar clusters em grupos maiores. Com as frotas, é possível gerenciar vários clusters em várias nuvens e aplicar políticas consistentes nelas. A API GKE Multi-Cloud registra automaticamente seus clusters com uma frota quando o cluster é criado.

Ao criar um cluster, especifique um projeto host da frota em que o cluster será gerenciado. Como o GKE na AWS usa o nome do cluster como o nome da associação da frota, é preciso garantir que os nomes dos clusters sejam exclusivos em toda a frota.

Registro entre projetos

Se você quiser usar um projeto de host do Fleet diferente do projeto do Google Cloud em que o cluster está localizado, aplique uma vinculação de política de IAM adicional à conta de serviço do agente de serviços de várias nuvens. Isso permite que a conta de serviço gerencie as frotas com o projeto host da frota.

  1. Para adicionar o agente de serviço ao projeto, execute este comando:

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER

    Substitua CLUSTER_PROJECT_NUMBER pelo número do projeto do Google Cloud.

  2. Atribua essa vinculação com o seguinte comando:

    gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \
  --role="roles/gkemulticloud.serviceAgent"

    Substitua:

    • FLEET_PROJECT_ID: o projeto do Google Cloud do seu projeto host da frota
    • CLUSTER_PROJECT_NUMBER: o número do projeto do Google Cloud.

O nome da conta do agente de serviços em várias nuvens tem o seguinte formato: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

É possível encontrar as contas de serviço na página Conta de serviço do console do Google Cloud. Para mais informações sobre como encontrar o número de projeto, consulte Como identificar projetos.

Crie o cluster

Use o seguinte comando para criar o cluster no GKE na AWS. Para mais informações sobre esse comando, incluindo os parâmetros opcionais, consulte a página de referência gcloud container aws.

gcloud container aws clusters create CLUSTER_NAME \
  --aws-region AWS_REGION \
  --location GOOGLE_CLOUD_LOCATION \
  --cluster-version CLUSTER_VERSION \
  --fleet-project FLEET_PROJECT \
  --vpc-id VPC_ID \
  --subnet-ids CONTROL_PLANE_SUBNET_1,CONTROL_PLANE_SUBNET_2,CONTROL_PLANE_SUBNET_3 \
  --pod-address-cidr-blocks POD_ADDRESS_CIDR_BLOCKS \
  --service-address-cidr-blocks SERVICE_ADDRESS_CIDR_BLOCKS \
  --role-arn API_ROLE_ARN \
  --database-encryption-kms-key-arn DB_KMS_KEY_ARN \
  --admin-users ADMIN_USERS_LIST \
  --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
  --iam-instance-profile CONTROL_PLANE_PROFILE \
  --tags "Name=CLUSTER_NAME-cp"

Substitua:

  • CLUSTER_NAME: o nome do cluster escolhido
  • AWS_REGION: a região da AWS em que o cluster será criado
  • GOOGLE_CLOUD_LOCATION: o nome do local do Google Cloud em que esse cluster vai ser gerenciado, conforme definido nas regiões de gerenciamento do Google Cloud.
  • CLUSTER_VERSION: a versão do Kubernetes a ser instalada no cluster
  • FLEET_PROJECT: o projeto host da frota em que o cluster será registrado. Se você quiser gerenciar esse cluster em outro projeto do Google Cloud, consulte Registro entre projetos.
  • VPC_ID: o ID de VPC da AWS para este cluster
  • CONTROL_PLANE_SUBNET_1, CONTROL_PLANE_SUBNET_2, CONTROL_PLANE_SUBNET_3: os IDs da sub-rede das três instâncias do plano de controle do cluster
  • POD_ADDRESS_CIDR_BLOCKS: o intervalo de endereços CIDR dos pods do cluster.
  • SERVICE_ADDRESS_CIDR_BLOCKS o intervalo de endereços CIDR dos serviços do cluster.
  • API_ROLE_ARN: o ARN do papel da API GKE Multi-Cloud
  • CONTROL_PLANE_PROFILE: o perfil da instância do IAM associada ao cluster. Para detalhes sobre como atualizar um perfil de instância do IAM, consulte Atualizar o perfil da instância do IAM da AWS.
  • DB_KMS_KEY_ARN: o nome de recurso da Amazon (ARN) da chave de KMS da AWS que criptografa os secrets do cluster
  • CONFIG_KMS_KEY_ARN: o Nome de Recursos da Amazon (ARN, na sigla em inglês) da chave de AWS KMS para criptografar dados do usuário;
  • ADMIN_USERS_LIST (opcional): uma lista separada por vírgulas de endereços de e-mail dos usuários para conceder privilégios administrativos a, por exemplo, "kai@example.com,hao@example.com,kalani@example.com". O padrão é o usuário que cria o cluster.

Se estiver presente, o parâmetro --tags aplicará a tag da AWS fornecida a todos os recursos da AWS subjacentes gerenciados pelo GKE na AWS. Este exemplo marca os nós do plano de controle com o nome do cluster ao qual eles pertencem.

Não será possível usar o SSH nesses nós do plano de controle, a menos que você especifique um par de chaves SSH com a sinalização --ssh-ec2-key-pair.

Para ver todas as versões compatíveis do Kubernetes em um determinado local do Google Cloud, execute o comando a seguir.

gcloud container aws get-server-config --location GCP_LOCATION

Autorizar o Cloud Logging / Cloud Monitoring

Para que o GKE na AWS crie e faça upload de registros e métricas do sistema para o Google Cloud, ele precisa ser autorizado.

Para autorizar a Identidade da carga de trabalho do Kubernetes gke-system/gke-telemetry-agent a gravar registros no Google Cloud Logging e métricas no Google Cloud Monitoring, execute este comando:

gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
  --member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
  --role=roles/gkemulticloud.telemetryWriter

Substitua GOOGLE_PROJECT_ID pelo ID do projeto do Google Cloud do cluster.

Essa vinculação do IAM concede acesso a todos os clusters no projeto do Google Cloud para fazer upload de registros e métricas. Você só precisa executá-lo após criar o primeiro cluster para o projeto.

A adição dessa vinculação do IAM falhará a menos que pelo menos um cluster tenha sido criado no seu projeto do Google Cloud. Isso ocorre porque o pool de identidades de cargas de trabalho a que ele se refere (GOOGLE_PROJECT_ID.svc.id.goog) não é provisionado até a criação do cluster.

A seguir