Criar um cluster

Nesta página, explicamos como criar um cluster e um pool de nós no GKE no Azure, na versão 1.32.4-gke.200 do Kubernetes.

Antes de começar

Para concluir as etapas desta página, faça o seguinte:

  1. Siga as etapas descritas em Configurar pré-requisitos.

  2. Escolha se você executará o plano de controle em várias zonas ou em uma única zona.

  3. Em seguida, selecione intervalos de roteamento entre domínios sem classe (CIDR, na sigla em inglês) para fornecer ao cluster.

Posicionamento por zona do plano de controle

Por padrão, o GKE no Azure coloca réplicas de plano de controle separadas na mesma sub-rede em três zonas na região selecionada. É possível escolher essas zonas e sub-redes.

Se você quiser usar a posição padrão da réplica do plano de controle, pule para Selecionar intervalos CIDR para seu cluster.

Planos de controle de cluster e gateway NAT do Azure

Cada réplica do plano de controle também requer conectividade com o serviço de gerenciamento hospedado pelo Google para operar em um estado normal.

Se você usar o gateway NAT do Azure para fornecer conectividade de saída, avalie como uma falha de zona afeta o plano de controle do cluster. Um endpoint do gateway NAT é isolado para uma única zona ou é regional/não zonal, e apresenta um único ponto de falha.

Se você quiser colocar réplicas do plano de controle em uma única zona, use uma única sub-rede e zona. Se você usar o gateway NAT para a conectividade de saída, verifique se o endpoint está posicionado na mesma zona.

Para colocar réplicas em duas ou três zonas, é possível transmitir uma lista de sub-redes e zonas ao criar um cluster. Quando você transmite duas sub-redes e zonas, o GKE no Azure coloca duas réplicas na primeira zona fornecida. Quando você transmite três sub-redes e zonas, o GKE no Azure coloca as réplicas em cada sub-rede. Para mais informações, consulte Colocar réplicas em uma sub-rede específica.

Para mais informações sobre como configurar sub-redes e zonas do Azure para alta disponibilidade, consulte Isolamento de zonas com pilhas zonais na documentação do Azure.

Colocar réplicas em uma sub-rede específica

Esta seção é opcional.

Para controlar em quais zonas as réplicas do plano de controle serão colocadas, use a sinalização --replica-placements e transmita uma lista de IDs de sub-rede e zonas ao criar o cluster. É possível usar até três sub-redes e zonas para colocar as réplicas do plano de controle.

Para formatar a lista de sub-redes, execute as etapas a seguir.

  1. Recupere os IDs das sub-redes do Azure com a ferramenta de linha de comando az:

    az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name SUBNET_NAME --query "id" -otsv

    Substitua:

    • CLUSTER_RESOURCE_GROUP_NAME: um nome de grupo de recursos atual em que você quer executar o cluster
    • VNET_RESOURCE_GROUP_NAME: o nome do grupo de recursos que contém sua VNet
    • VNET_NAME: seu nome de VNet
    • SUBNET_NAME: o nome da sub-rede

    A saída é o ID da sub-rede. Os IDs das sub-redes do Azure são semelhantes a estes:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

    Repita esse comando para cada sub-rede em que você quer criar uma réplica de plano de controle. Copie os IDs de sub-rede em um editor de texto para a etapa a seguir.

  2. Crie uma lista separada por vírgulas de IDs de sub-rede e zonas de disponibilidade do Azure, com dois pontos separando a sub-rede e a zona. Por exemplo, para criar réplicas do plano de controle em subnet1 na zona 1, subnet2 na zona 2 e subnet3 na zona 3, use a seguinte string:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet1:1,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet2:2,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet3:3

    Copie essa string e use-a como o valor da sinalização --replica-placements ao criar um cluster.

Selecionar intervalos CIDR para o cluster

Ao criar um cluster no GKE no Azure, é necessário 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 no Azure 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 VNet. 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 VNet, 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 VNet.

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 VNet usa endereços IP privados RFC 1918, enquanto as redes de pods e serviços são sobrepostas em IPs privados RFC 6598).

  • Rede VNet: 10.0.0.0/16, 172.16.1.0/24, 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 VNet, já que não há sobreposição com as réplicas do plano de controle.

  • Rede VNet: 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 VNet:

  • Rede VNet: 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

Autenticar no Azure

O GKE no Azure oferece dois métodos de autenticação no Azure: federação de identidade da carga de trabalho e criação de um certificado do cliente. A autenticação da federação de identidade da carga de trabalho é o método recomendado, porque é mais simples e seguro.

Federação de identidade da carga de trabalho

A federação de identificação de carga de trabalho permite que o GKE no Azure seja autenticado no Azure usando uma conta de serviço do Google para gerenciar recursos posteriormente no aplicativo Azure AD. Em comparação com o AzureClient, não é necessário gerenciar certificados e fazer upload para o Azure AD manualmente.

Para configurar uma credencial de identidade federada no aplicativo Azure AD, execute os comandos a seguir. É possível adicionar até 20 credenciais a cada aplicativo do Azure AD.

  1. Salve o ID do aplicativo Azure em variáveis de ambiente:

    APPLICATION_ID=$(az ad app list --all \
  --query "[?displayName=='APPLICATION_NAME'].appId" --output tsv)
PROJECT_ID="$(gcloud config get-value project)"
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
--format "value(projectNumber)")

  2. Crie um arquivo JSON chamado credential.json.

    {
  "name": "CREDENTIAL_NAME",
  "issuer": "https://accounts.google.com",
  "subject": "service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Allow GKE on Azure to authenticate to the Azure AD application using a Google service account."
}
    • CREDENTIAL_NAME: o nome da credencial.
    • PROJECT_NUMBER: o número do projeto do Google Cloud que hospeda o cluster.

  3. Crie uma credencial de identidade federada no aplicativo Azure AD:

    az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json

Para mais detalhes, consulte a documentação do Azure Federação de identidade da carga de trabalho do Azure AD com o Google Cloud.

Também é possível provisionar a credencial de identidade federada do Azure usando o Terraform. Para mais detalhes, consulte azuread_application_federated_identity_credential.

Depois de configurar as credenciais, crie ou selecione um par de chaves SSH para o cluster.

Crie um par de chaves SSH.

Ao criar um cluster, você precisa fornecer um par de chaves SSH. Se você tiver um par de chaves para usar, pule esta etapa.

  1. Para criar um novo par de chaves, use a ferramenta de linha de comando ssh-keygen:

    ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH

    Substitua KEY_PATH pelo caminho para a nova chave privada.

  2. Armazene a chave em uma variável de ambiente:

    SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Por exemplo, para criar um novo par de chaves em ~/.ssh/anthos-multicloud-key.pub e armazenar a chave pública em uma variável de ambiente, execute os seguintes comandos:

    ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key
SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)

Depois de salvar a chave pública em uma variável de ambiente, você estará pronto para criar um cluster.

Selecionar o projeto host de frota

Frotas são um conceito doGoogle 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 os 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 no Azure usa o nome do cluster como o nome da associação do Fleet, é preciso garantir que os nomes dos seus clusters sejam exclusivos em todo o Fleet.

Registro entre projetos

Se você quiser usar um projeto de host do Fleet diferente do projeto 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 seu projeto 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: oGoogle Cloud projeto do seu projeto host da frota
    • CLUSTER_PROJECT_NUMBER: o número do seu Google Cloud projeto

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 um cluster

Para criar um cluster, execute os seguintes comandos:

  1. Salve os IDs de grupo de recursos, VNet e sub-rede do Azure em variáveis de ambiente:

    SUBSCRIPTION_ID=$(az account show --query "id" --output tsv)
TENANT_ID=$(az account list \
  --query "[?id=='${SUBSCRIPTION_ID}'].{tenantId:tenantId}" --output tsv)
CLUSTER_RG_ID=$(az group show --resource-group=CLUSTER_RESOURCE_GROUP_NAME \
  --query "id" -otsv)
VNET_ID=$(az network vnet show --resource-group=VNET_RESOURCE_GROUP_NAME \
  --name=VNET_NAME --query "id" -otsv)
SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)

    Substitua:

    • CLUSTER_RESOURCE_GROUP_NAME: um nome de grupo de recursos atual em que você quer executar o cluster
    • VNET_RESOURCE_GROUP_NAME: o nome do grupo de recursos que contém sua VNet
    • VNET_NAME: o nome da sua VNet

  2. Crie um cluster com a Google Cloud CLI:

    Federação de identidade da carga de trabalho

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --azure-tenant-id "${TENANT_ID}" \
    --azure-application-id "${APPLICATION_ID}" \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.32.4-gke.200 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Cliente do Azure

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --client CLIENT_NAME \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.32.4-gke.200 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Substitua:

    • CLUSTER_NAME: o nome do cluster.
    • GOOGLE_CLOUD_LOCATION: o Google Cloud local que gerencia seu cluster
    • FLEET_PROJECT pelo projeto host da fleet em que o cluster será registrado. Se você quiser gerenciar esse cluster em outro projeto doGoogle Cloud , consulte Registro entre projetos.
    • AZURE_REGION: uma região compatível do Azure associada à região Google Cloud .
    • POD_CIDR: o intervalo de endereços de pods do cluster, por exemplo, 10.0.1.0/18
    • SERVICE_CIDR: o intervalo de endereços de serviço do cluster
    • VM_SIZE: um tamanho de VM do Azure compatível
    • 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.
    • CLIENT_NAME: nome do seu AzureClient.

  3. Verifique o status do cluster:

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION

    Substitua:

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

    A saída inclui informações sobre o status e a configuração do cluster.

Autorizar o Cloud Logging / Cloud Monitoring

Para que o GKE no Azure crie e faça upload de registros e métricas do sistema para 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 Google Cloud do cluster.

Essa vinculação do IAM concede acesso a todos os clusters no projeto 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 projeto Google Cloud . Isso ocorre porque o pool de Identidade de carga de trabalho ao qual se refere (GOOGLE_PROJECT_ID.svc.id.goog) não é provisionado até a criação do cluster.

Crie um pool de nós.

Antes de criar um pool de nós, você precisa do seguinte:

  • Permissões para usar a ferramenta de linha de comando az para recuperar um ID de sub-rede do Azure.
  • Acesso à chave pública SSH do cluster de usuário.

Para criar um pool de nós, execute os comandos a seguir:

  1. Salve o ID da sub-rede VNet do Azure e a chave pública SSH nas variáveis de ambiente:

    SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Substitua:

    • VNET_RESOURCE_GROUP_NAME: o nome do grupo de recursos em que está a VNet
    • VNET_NAME: o nome da sua VNet
    • KEY_PATH: o caminho para o par de chaves

  2. Crie um pool de nós com a Google Cloud CLI:

    gcloud container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version 1.32.4-gke.200 \
    --vm-size VM_SIZE \
    --max-pods-per-node 110 \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --ssh-public-key "${SSH_PUBLIC_KEY}" \
    --subnet-id "${SUBNET_ID}"

    Substitua:

  3. Verifique o status do seu pool de nós:

    gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION

    Substitua:

    • NODE_POOL_NAME: um nome exclusivo para o pool de nós, por exemplo, node-pool-1
    • CLUSTER_NAME: o nome do cluster do GKE no Azure
    • GOOGLE_CLOUD_LOCATION: o local doGoogle Cloud que gerencia seu cluster

    A saída inclui o status do pool de nós, incluindo se é PROVISIONING ou RUNNING.

A seguir