Crie um cluster

Esta página explica como criar um cluster e um conjunto de nós no GKE on Azure na versão 1.32.4-gke.200 do Kubernetes.

Antes de começar

Para concluir os passos nesta página, faça o seguinte:

  1. Siga os passos em Configure os pré-requisitos.

  2. Escolha se vai executar o plano de controlo em várias zonas ou numa única zona.

  3. Selecione intervalos de Classless Inter-Domain Routing (CIDR) para fornecer ao seu cluster.

Posicionamento zonal do plano de controlo

Por predefinição, o GKE no Azure coloca réplicas do plano de controlo separadas na mesma sub-rede em três zonas na região selecionada. Pode escolher estas zonas e sub-redes.

Se quiser usar o posicionamento predefinido da réplica do plano de controlo, avance para Selecionar intervalos CIDR para o cluster.

Gateway do Azure NAT e planos de controlo de clusters

Cada réplica do plano de controlo também requer conetividade ao serviço de gestão alojado na Google para funcionar num estado normal.

Se usar o gateway NAT do Azure para fornecer conetividade de saída, tem de considerar como uma falha zonal afeta o plano de controlo do cluster. Um ponto final do gateway NAT está isolado numa única zona ou é regional/não zonal, e isto apresenta um ponto único de falha.

Se quiser colocar réplicas do plano de controlo numa única zona, use uma única sub-rede e zona. Se usar o gateway NAT para a conetividade de saída, certifique-se de que o ponto final está colocado na mesma zona.

Se quiser colocar réplicas em duas ou três zonas, pode transmitir uma lista de sub-redes e zonas quando criar um cluster. Quando transmite duas sub-redes e zonas, o GKE no Azure coloca duas réplicas na primeira zona fornecida. Quando transmite três sub-redes e zonas, o GKE no Azure coloca réplicas em cada sub-rede. Para mais informações, consulte o artigo Coloque réplicas numa sub-rede específica.

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

Coloque réplicas numa sub-rede específica

Esta secção é opcional.

Para controlar em que zonas são colocadas as réplicas do plano de controlo, use a flag --replica-placements e transmita uma lista de IDs de sub-redes e zonas quando criar o cluster. Pode usar até três sub-redes e zonas onde colocar as réplicas do plano de controlo.

Para formatar a lista de sub-redes, siga estes passos.

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

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

    Substitua o seguinte:

    • CLUSTER_RESOURCE_GROUP_NAME: um nome de grupo de recursos existente onde quer executar o cluster
    • VNET_RESOURCE_GROUP_NAME: o nome do grupo de recursos que contém a sua VNet
    • VNET_NAME: o nome da sua VNet
    • SUBNET_NAME: o nome da sua sub-rede

    O resultado é o ID da sub-rede. Os IDs de sub-rede do Azure têm o seguinte aspeto:

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

    Repita este comando para cada sub-rede na qual quer criar uma réplica do plano de controlo. Copie os IDs das sub-redes para um editor de texto para o passo seguinte.

  2. Crie uma lista de IDs de sub-redes e zonas de disponibilidade do Azure separadas por vírgulas, com um dois pontos a separar a sub-rede e a zona. Por exemplo, para criar réplicas do plano de controlo em subnet1 na zona 1, subnet2 na zona 2 e subnet3 na zona 3, usa 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 esta string e use-a como o valor da flag --replica-placements quando criar um cluster.

Selecione intervalos CIDR para o seu cluster

Quando cria um cluster no GKE on Azure, tem de fornecer intervalos de endereços IPv4 para usar em pods e serviços.

Estes intervalos de IP são especificados através da notação Classless Inter-Domain Routing (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

Estes intervalos são suficientemente grandes para que possa aumentar o seu cluster sem problemas.

As secções seguintes fornecem mais detalhes.

Detalhes sobre a seleção de intervalos

O GKE no Azure usa uma rede de sobreposição para pods e serviços, pelo que os intervalos de IP destas redes não precisam de ser encaminháveis na VNet. Todos os intervalos de IP que usar têm de ter disponibilidade garantida. Para mais informações, consulte o artigo Dataplane V2.

  • Os intervalos de IP do pod e do serviço podem sobrepor-se à rede VNet, desde que nenhum deles inclua os intervalos de IP da sub-rede do plano de controlo ou do conjunto de nós.

  • O intervalo de IPs do pod e do serviço tem de estar dentro de um dos seguintes intervalos de IPs privados:

    • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16: endereços IP privados (RFC 1918)
    • 100.64.0.0/10 — Espaço de endereço partilhado (RFC 6598)
    • 192.0.0.0/24 — Atribuições de protocolos da IETF (RFC 6890)
    • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24: documentação (RFC 5737)
    • 192.88.99.0/24 — Relé IPv6 para IPv4 (descontinuado) (RFC 7526)
    • 198.18.0.0/15 — Testes de referência (RFC 2544)

Recomendamos intervalos de IPs dentro de 100.64.0.0/10 (RFC 6598). Este intervalo está reservado para NAT de nível de operador, que provavelmente não é usado na sua VNet.

Por exemplo, a seguinte é uma configuração válida em que as redes de nós, serviços e pods não se sobrepõem (a VNet está a usar endereços IP privados RFC 1918, enquanto as redes de serviços e pods estã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 de pods: 100.65.0.0/16
  • Rede de serviços: 100.66.0.0/16

A seguinte também é uma configuração válida, apesar de as redes de pods e serviços se sobreporem à rede VNet, uma vez que não existe sobreposição com as réplicas do plano de controlo.

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

A seguinte configuração é inválida porque o intervalo de IPs do pod sobrepõe-se à rede do plano de controlo. Esta sobreposição pode impedir que as cargas de trabalho comuniquem com a réplica do plano de controlo na rede VNet:

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

Detalhes acerca do intervalo de endereços do pod

O Kubernetes atribui endereços a objetos Pod a partir do intervalo de endereços do Pod. O intervalo de pods de um cluster é dividido em intervalos mais pequenos para cada nó. Quando um pod é agendado num nó específico, o Kubernetes atribui um endereço IP do pod a partir do intervalo do nó.

Para calcular o tamanho do intervalo de endereços do Pod, tem de estimar o número de nós que quer no cluster e o número de Pods que quer executar em cada nó.

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

Tabela de intervalos de endereços de pods

Intervalo de endereços do pod Máximo de endereços IP do agrupamento Máximo de nós Agrupamentos máximos
/24
Intervalo de endereços de pod mais pequeno possível		 256 endereços 1 nó 110 pods
/23 512 endereços 2 nós 220 agrupamentos
/22 1024 endereços 4 nós 440 Pods
/21 2048 endereços 8 nós 880 Pods
/20 4096 endereços 16 nós 1760 agrupamentos
/19 8192 endereços 32 nós 3520 agrupamentos
/18 16 384 endereços 64 nós 7040 agrupamentos
/17 32 768 endereços 128 nós 14 080 agrupamentos
/16 65 536 endereços 256 nós 28 160 agrupamentos
/15 131 072 endereços 512 nós 56 320 agrupamentos
/14 262 144 endereços 1024 nós 112 640 agrupamentos

Detalhes sobre o intervalo de moradas de serviço

O Kubernetes atribui endereços IP virtuais para objetos de serviço, por exemplo, equilibradores de carga a partir deste intervalo de endereços.

Para calcular a dimensão do intervalo de endereços de serviço, tem de estimar o número de serviços que quer no cluster.

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

Tabela de intervalos de moradas de serviço

Intervalo de moradas de serviço Número máximo de serviços
/27
O intervalo de endereços de serviço mais pequeno possível		 32 serviços
/26 64 serviços
/25 128 serviços
/24 256 serviços
/23 512 serviços
/22 1024 serviços
/21 2048 serviços
/20 4096 serviços
/19 8192 serviços
/18 16 384 serviços
/17 32 768 serviços
/16
Maior intervalo de moradas de serviço possível		 65 536 serviços

Autentique-se 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 de cliente. A autenticação da federação de identidades de cargas de trabalho é o método recomendado, porque é mais simples e seguro.

Federação de identidades de cargas de trabalho

A federação de identidade da carga de trabalho permite que o GKE no Azure se autentique no Azure através de uma conta de serviço Google para gerir posteriormente recursos na aplicação Azure AD. Em comparação com o AzureClient, não precisa de gerir certificados nem carregá-los manualmente para o Azure AD.

Para configurar uma credencial de identidade federada na sua aplicação do Azure AD, execute os seguintes comandos. Tenha em atenção que pode adicionar até 20 credenciais a cada aplicação do Azure AD.

  1. Guarde o ID da aplicação do Azure nas 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 ficheiro JSON denominado 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 que aloja o cluster. Google Cloud

  3. Crie uma credencial de identidade federada na aplicação do 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 identidades de cargas de trabalho do Azure AD com o Google Cloud.

Também pode aprovisionar a credencial de identidade federada do Azure através do Terraform. Para ver 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

Quando cria um cluster, tem de fornecer um par de chaves SSH. Se já tiver um par de chaves para usar, ignore este passo.

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

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

    Substitua KEY_PATH pelo caminho para a sua nova chave privada.

  2. Armazene a chave numa 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 numa variável de ambiente, execute o seguinte comando:

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

Depois de guardar a chave pública numa variável de ambiente, pode criar um cluster.

Selecione o projeto de anfitrião do Fleet

As frotas são um Google Cloud conceito para organizar clusters em grupos maiores. Com as frotas, pode gerir vários clusters em várias nuvens e aplicar políticas consistentes em todos eles. A API GKE Multi-Cloud regista automaticamente os seus clusters numa frota quando o cluster é criado.

Quando cria um cluster, especifica um projeto de anfitrião da frota a partir do qual o cluster vai ser gerido. Uma vez que o GKE no Azure usa o nome do cluster como o nome de membro da frota, tem de garantir que os nomes dos clusters são únicos na sua frota.

Registo em vários projetos

Se quiser usar um projeto anfitrião da frota diferente do Google Cloud projeto onde o cluster está localizado, tem de aplicar uma associação de política do IAM adicional à conta de serviço do agente de serviço multinuvem. Isto permite que a conta de serviço faça a gestão de frotas com o projeto anfitrião da frota.

  1. Para adicionar o agente do serviço ao seu 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 Google Cloud projeto.

  2. Atribua esta associaçã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 o seguinte:

    • FLEET_PROJECT_ID: o projeto de alojamento do Fleet Google Cloud
    • CLUSTER_PROJECT_NUMBER: o número do seu Google Cloud projeto

O nome da conta do agente do serviço multinuvem tem o seguinte formato: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

Pode encontrar as suas contas de serviço na página Google Cloud consola Conta de serviço. Para mais informações sobre como encontrar o número do projeto, consulte o artigo Identificar projetos.

Crie um cluster

Para criar um cluster, execute os seguintes comandos:

  1. Guarde os IDs do grupo de recursos, da VNet e da sub-rede do Azure nas 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 o seguinte:

    • CLUSTER_RESOURCE_GROUP_NAME: um nome de grupo de recursos existente onde quer executar o cluster
    • VNET_RESOURCE_GROUP_NAME: o nome do grupo de recursos que contém a sua VNet
    • VNET_NAME: o nome da sua VNet

  2. Crie um cluster com a CLI do Google Cloud:

    Federação de identidades de cargas 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 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 o seguinte:

    • CLUSTER_NAME: o nome do seu cluster
    • GOOGLE_CLOUD_LOCATION: a Google Cloud localização que gere o seu cluster
    • FLEET_PROJECT com o projeto anfitrião da frota onde o cluster vai ser registado. Se quiser gerir este cluster a partir de outro Google Cloud projeto, consulte Registo entre projetos.
    • AZURE_REGION: a região do Azure suportada associada à sua Google Cloud região
    • POD_CIDR: o intervalo de endereços de agrupamentos do seu cluster, por exemplo, 10.0.1.0/18
    • SERVICE_CIDR: o intervalo de endereços de serviço do cluster
    • VM_SIZE: a tamanho da VM do Azure suportado
    • ADMIN_USERS_LIST (opcional): uma lista separada por vírgulas dos endereços de email dos utilizadores aos quais conceder privilégios administrativos. Por exemplo, "kai@example.com,hao@example.com,kalani@example.com". A predefinição é o utilizador que cria o cluster
    • CLIENT_NAME: o nome do seu AzureClient

  3. Verifique o estado do seu cluster:

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION

    Substitua o seguinte:

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

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

Autorize o Cloud Logging / Cloud Monitoring

Para que o GKE no Azure crie e carregue métricas e registos do sistema para o Google Cloud, tem de ser autorizado.

Para autorizar a identidade da carga de trabalho do Kubernetes gke-system/gke-telemetry-agent a escrever registos 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 cluster.

Esta associação de IAM concede acesso a todos os clusters no projeto Google Cloud project para carregar registos e métricas. Só tem de o executar depois de criar o primeiro cluster para o projeto.

A adição desta associação de IAM falha, a menos que tenha sido criado, pelo menos, um cluster no seu projeto Google Cloud . Isto deve-se ao facto de o Workload Identity Pool a que se refere (GOOGLE_PROJECT_ID.svc.id.goog) não ser aprovisionado até à criação do cluster.

Crie um node pool

Antes de criar um conjunto de nós, precisa do seguinte:

  • Autorizações para usar a ferramenta de linha de comandos az para obter um ID de sub-rede do Azure.
  • Acesso à chave pública de SSH do cluster.

Para criar um node pool, execute os seguintes comandos:

  1. Guarde o ID da sub-rede da VNet do Azure e a chave pública de 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 o seguinte:

    • VNET_RESOURCE_GROUP_NAME: o nome do grupo de recursos que contém a VNet
    • VNET_NAME: o nome da sua VNet
    • KEY_PATH: o caminho para o seu par de chaves

  2. Crie um node pool 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 o seguinte:

    • NODE_POOL_NAME: um nome exclusivo para o seu conjunto de nós, por exemplo, node-pool-1
    • CLUSTER_NAME: o nome do seu cluster do GKE no Azure
    • GOOGLE_CLOUD_LOCATION: a Google Cloud localização que gere o seu cluster
    • VM_SIZE: a tamanho da VM do Azure suportado
    • MIN_NODES: o número mínimo de nós no node pool. Para mais informações, consulte o artigo Cluster autoscaler
    • MAX_NODES: o número máximo de nós no node pool

  3. Verifique o estado do seu conjunto de nós:

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

    Substitua o seguinte:

    • NODE_POOL_NAME: um nome exclusivo para o seu conjunto de nós, por exemplo, node-pool-1
    • CLUSTER_NAME: o nome do seu cluster do GKE no Azure
    • GOOGLE_CLOUD_LOCATION: a Google Cloud localização que gere o seu cluster

    A saída inclui o estado do seu conjunto de nós, incluindo se está PROVISIONING ou RUNNING.

O que se segue?