Crie um cluster de utilizadores

No Google Distributed Cloud, as suas cargas de trabalho são executadas num ou mais clusters de utilizadores. Este documento mostra como criar um cluster de utilizadores. Se quiser usar domínios de topologia, consulte o artigo Crie um cluster de utilizadores para usar com domínios de topologia.

Esta página destina-se a administradores, arquitetos e operadores que configuram, monitorizam e gerem a infraestrutura técnica. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Na versão 1.33 e superior, todos os novos clusters são criados como clusters avançados. Certifique-se de que revê as diferenças quando executa clusters avançados.

Existem várias ferramentas que pode usar para criar um cluster de utilizadores:

• gkectl
• Google Cloud consola
• Google Cloud CLI
• Terraform

Três destas ferramentas (a consola, a CLI gcloud e o Terraform) são clientes da API GKE On-Prem.

Para obter orientações sobre a ferramenta que pode querer usar, consulte o artigo Escolha uma ferramenta para gerir o ciclo de vida do cluster.

Antes de começar

• Se planeia usar o gkectl para criar o cluster de utilizadores, certifique-se de que configurou e consegue iniciar sessão na sua estação de trabalho de administrador, conforme descrito em Crie uma estação de trabalho de administrador.

• Certifique-se de que a estação de trabalho do administrador tem a versão necessária do gkectl. Normalmente, usa a mesma versão do gkectl que vai ser usada quando criar o cluster. Especifica a versão do cluster no campo gkeOnPremVersion no ficheiro de configuração do cluster. As seguintes regras de versão são aplicadas durante a criação do cluster:

  • A versão secundária gkectl não pode ser inferior à versão secundária do cluster. Por exemplo, não é permitido criar um cluster 1.30 com a versão 1.29 do gkectl. As versões de patch não são importantes. Por exemplo, pode usar a versão 1.29.0-gke.1456 para criar um cluster com uma versão de patch superior, como 1.29.1000-gke.94.gkectl

  • A versão secundária gkectl não pode ser mais de duas versões secundárias superior à versão do cluster. Por exemplo, se estiver a criar um cluster 1.28, a versão gkectl pode ser 1.29 ou 1.30. No entanto, não pode usar a versão 1.31 do gkectl porque é três versões secundárias superior à versão do cluster.

  Se necessário, consulte Transferir gkectl para obter uma versão suportada do gkectl.

• Se ainda não o fez, configure os seus Google Cloud recursos conforme descrito nestes documentos:

  • Instale a CLI do Google Cloud
  • Criar projetos na nuvem
  • Crie contas de serviço

  Ao configurar o projeto anfitrião da frota, tenha em atenção a ferramenta escolhida, porque se tiver escolhido um dos clientes da API GKE On-Prem, existem APIs adicionais que tem de ativar. Para ver a lista de APIs, consulte o artigo Ative APIs no projeto anfitrião da frota.

• Antes de criar um cluster de utilizadores, tem de ter um cluster de administrador para gerir o cluster de utilizadores. Se ainda não o fez, crie uma estação de trabalho de administrador e um cluster de administrador.

• Determine a versão do cluster de utilizadores que quer instalar. Quando cria um cluster de utilizadores, normalmente instala a versão que corresponde à versão do cluster de administrador. Se quiser instalar uma versão diferente num cluster de utilizadores, consulte as Regras de versão.

• Se planeia instalar a versão 1.30 ou uma versão superior, o Controlplane V2 é necessário. Mesmo que esteja a instalar a versão 1.29 ou inferior, recomendamos que ative o Controlplane V2. Quando o Controlplane V2 está ativado, o plano de controlo para o cluster de utilizadores é executado num ou mais nós no próprio cluster de utilizadores. A alternativa é criar um cluster de utilizadores que use o kubeception. No caso do kubeception, o plano de controlo do cluster de utilizadores é executado num ou mais nós no cluster de administrador.

• Reveja o documento de planeamento de endereços IP e certifique-se de que tem endereços IP suficientes disponíveis.

• Reveja a vista geral do balanceamento de carga e reveja a sua decisão sobre o tipo de balanceador de carga que quer usar. Pode usar o equilibrador de carga MetalLB incluído ou configurar manualmente um equilibrador de carga à sua escolha. Para o equilíbrio de carga manual, tem de configurar o equilibrador de carga antes de criar o cluster de utilizadores.

• Pense em quantos conjuntos de nós precisa e em que sistema operativo quer executar em cada um dos seus conjuntos.

• Pondere se quer usar clusters do vSphere separados para o cluster de administrador e os clusters de utilizadores, e se quer usar centros de dados separados. Pondere também se quer usar instâncias separadas do vCenter Server.

• Na versão 1.29 e superior, as verificações prévias do lado do servidor estão ativadas por predefinição. As verificações prévias do lado do servidor requerem regras de firewall adicionais. Em Regras de firewall para clusters de administrador, pesquise "Verificações prévias" e certifique-se de que todas as regras de firewall necessárias estão configuradas.

  Com as verificações prévias do lado do servidor, quando cria um cluster de utilizadores com o comando gkectl, as verificações prévias são executadas no cluster de administrador em vez de localmente na estação de trabalho de administrador. As verificações prévias do lado do servidor também são executadas se usar a consola, a CLI Google Cloud ou o Terraform para criar um cluster de utilizadores. Google Cloud

Crie um cluster de utilizadores com a ferramenta que escolher

Esta secção fornece passos para criar um cluster de utilizadores com o gkectl, a consola, a CLI gcloud e o Terraform.

gkectl

Vista geral do procedimento

Estes são os principais passos envolvidos na utilização da gkectl para criar um cluster de utilizadores:

1. Preencha os ficheiros de configuração

   Especifique os detalhes do novo cluster preenchendo um ficheiro de configuração do cluster de utilizadores, um ficheiro de configuração de credenciais e, possivelmente, um ficheiro de bloco de IPs.

2. (Opcional) Importe imagens do SO para o vSphere e envie imagens de contentores para o registo privado, se aplicável.

   Corrida gkectl prepare.

3. Crie um cluster de utilizadores

   Execute gkectl create cluster para criar um cluster conforme especificado no seu ficheiro de configuração.

4. Verifique se o cluster de utilizadores está em execução

   Use kubectl para ver os nós do cluster.

No final deste procedimento, tem um cluster de utilizadores em execução onde pode implementar as suas cargas de trabalho.

Se usar os VPC Service Controls, pode ver erros quando executar alguns comandos gkectl, como "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Para evitar estes erros, adicione o parâmetro --skip-validation-gcp aos seus comandos.

Preencha os ficheiros de configuração

Se usou gkeadm para criar a sua estação de trabalho de administrador, gkeadm gerou um modelo para o ficheiro de configuração do cluster de utilizadores denominado user-cluster.yaml. Além disso, o gkeadm preencheu alguns dos campos por si.

Se não usou o gkeadm para criar a estação de trabalho de administrador, pode usar o gkectl para gerar um modelo para o ficheiro de configuração do cluster de utilizadores.

Para gerar um modelo para o ficheiro de configuração do cluster de utilizadores:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

Substitua o seguinte:

OUTPUT_FILENAME: um caminho à sua escolha para o modelo gerado. Se omitir esta flag, gkectl atribui o nome user-cluster.yaml ao ficheiro e coloca-o no diretório atual.

VERSION: o número da versão pretendido. Por exemplo: gkectl create-config cluster --gke-on-prem-version=1.33.0-gke.799.

Familiarize-se com o ficheiro de configuração analisando o documento ficheiro de configuração do cluster de utilizadores. Recomendamos que mantenha este documento aberto num separador ou numa janela separada, porque vai consultá-lo à medida que conclui os passos seguintes.

name

Defina o campo name para um nome à sua escolha para o cluster de utilizadores.

gkeOnPremVersion

Este campo já está preenchido. Especifica a versão do Google Distributed Cloud. Por exemplo, 1.33.0-gke.799.

enableAdvancedCluster

Na versão 1.31, se quiser ativar a funcionalidade de cluster avançada, defina enableAdvancedCluster como true. Este campo tem de estar definido como true se o cluster de administrador tiver a funcionalidade de cluster avançada ativada.

Tenha em atenção as seguintes diferenças entre as versões:

• Na versão 1.31, a funcionalidade de cluster avançada está em pré-visualização:

  • Só pode ativar o cluster avançado no momento da criação do cluster para novos clusters 1.31.

  • Depois de ativar o cluster avançado, não pode atualizar o cluster para a versão 1.32. Ative o cluster avançado apenas num ambiente de teste.

• Na versão 1.32, a funcionalidade de cluster avançada está em DG.

  • Por predefinição, os grupos de utilizadores são criados como grupos avançados. Tem de definir explicitamente enableAdvancedCluster como false se quiser criar um cluster não avançado.

  • Para clusters com a funcionalidade de clusters avançados ativada, as atualizações de clusters são suportadas.

• Na versão 1.33 e superior, todos os clusters são criados como clusters avançados. Se definir enableAdvancedCluster como false, a criação do cluster falha.

enableControlplaneV2

Para criar um cluster de utilizadores com o Controlplane V2 ativado, defina enableControlplaneV2 como true.

Se ativar o cluster avançado, tem de definir enableControlplaneV2 como true.

Quando o Controlplane V2 está ativado, o plano de controlo do cluster de utilizador é executado em nós no próprio cluster de utilizador. Recomendamos vivamente que ative o Controlplane V2.

kubeception

Se definir este campo como false, o cluster usa o kubecetption. Com o kubeception, o plano de controlo do cluster de utilizador é executado em nós no cluster de administrador.

Para um cluster kubeception:

• Defina enableControlplaneV2 como false.

• Não preencha a secção controlPlaneIPBlock.

• Especifique os endereços IP dos nós do plano de controlo do cluster de utilizadores no ficheiro de bloco de IP do cluster de administrador.

enableDataplaneV2

Defina enableDataplaneV2 como true.

vCenter

Os valores que define na secção vCenter do ficheiro de configuração do cluster de administrador são globais. Ou seja, aplicam-se ao cluster de administrador e aos respetivos clusters de utilizadores associados.

Para cada cluster de utilizadores que criar, tem a opção de substituir alguns dos valores vCenter globais.

Para substituir qualquer um dos valores vCenter globais, preencha os campos relevantes na secção vCenter do ficheiro de configuração do cluster de utilizadores.

Em particular, pode querer usar clusters vSphere separados para o cluster de administrador e os clusters de utilizadores, e pode querer usar centros de dados separados para o cluster de administrador e os clusters de utilizadores.

Usar um centro de dados e um cluster do vSphere

A opção predefinida é usar um centro de dados e um cluster do vSphere para o cluster de administrador e o cluster de utilizadores. Para esta opção, não defina quaisquer valores vCenter no ficheiro de configuração do cluster de utilizadores. Os valores vCenter serão herdados do cluster de administração.

Usar clusters do vSphere separados

Se quiser criar um cluster de utilizadores que esteja no seu próprio cluster do vSphere, especifique um valor para vCenter.cluster no ficheiro de configuração do cluster de utilizadores.

Se o cluster de administrador e o cluster de utilizadores estiverem em clusters vSphere separados, podem estar no mesmo centro de dados ou em centros de dados diferentes.

Usar centros de dados do vSphere separados

O cluster de utilizadores e o cluster de administrador podem estar em centros de dados diferentes. Nesse caso, também estão em clusters do vSphere separados.

Se especificar vCenter.datacenter no ficheiro de configuração do cluster de utilizadores, também tem de especificar:

• vCenter.networkName
• vCenter.datastore ou vCenter.storagePolicyName
• vCenter.cluster ou vCenter.resourcePool

Usar contas do vCenter separadas

Um cluster de utilizadores pode usar uma conta do vCenter diferente, com vCenter.credentials diferentes, do cluster de administrador. A conta do vCenter para o cluster de administrador precisa de acesso ao centro de dados do cluster de administrador, enquanto a conta do vCenter para o cluster de utilizador só precisa de acesso ao centro de dados do cluster de utilizador.

Usar instâncias separadas do vCenter Server

Em determinadas situações, faz sentido criar um cluster de utilizadores que use a sua própria instância do vCenter Server. Ou seja, o cluster de administrador e um cluster de utilizador associado usam instâncias diferentes do vCenter Server.

Por exemplo, numa localização periférica, pode querer ter uma máquina física a executar o vCenter Server e uma ou mais máquinas físicas a executar o ESXi. Em seguida, pode usar a sua instância local do vCenter Server para criar uma hierarquia de objetos do vSphere, incluindo centros de dados, clusters, pools de recursos, arquivos de dados e pastas.

Preencha toda a secção vCenter do ficheiro de configuração do cluster de utilizadores. Em particular, especifique um valor para vCenter.address que seja diferente do endereço do vCenter Server que especificou no ficheiro de configuração do cluster de administrador. Por exemplo:

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Preencha também o campo network.vCenter.networkName.

network

Decida como quer que os nós de trabalho obtenham os respetivos endereços IP. As opções são:

• A partir de um servidor DHCP que configurou antecipadamente. Defina network.ipMode.type como "dhcp".

• A partir de uma lista de endereços IP estáticos que fornece. Defina network.ipMode.type como "static" e crie um ficheiro de bloqueio de IPs que faculte os endereços IP estáticos. Para ver um exemplo de um ficheiro de bloqueio de IPs, consulte Exemplo de ficheiros de configuração preenchidos.

Se decidiu usar endereços IP estáticos para os nós de trabalho, preencha o campo network.ipMode.ipBlockFilePath.

Os nós do plano de controlo do cluster de utilizadores têm de obter os respetivos endereços IP a partir de uma lista de endereços estáticos que fornece. Isto acontece mesmo que os nós de trabalho obtenham os respetivos endereços a partir de um servidor DHCP. Para especificar endereços IP estáticos para os nós do plano de controlo, preencha a secção network.controlPlaneIPBlock. Se quiser um cluster de utilizadores de alta disponibilidade (HA), especifique três endereços IP. Caso contrário, especifique um endereço IP.

Especifique os servidores DNS e NTP preenchendo a secção hostConfig. Estes servidores DNS e NTP destinam-se aos nós do plano de controlo. Se estiver a usar endereços IP estáticos para os nós de trabalho, estes servidores DNS e NTP também se destinam aos nós de trabalho.

Os campos network.podCIDR e network.serviceCIDR têm valores pré-preenchidos que pode deixar inalterados, a menos que entrem em conflito com endereços já usados na sua rede. O Kubernetes usa estes intervalos para atribuir endereços IP a pods e serviços no seu cluster.

Independentemente de usar um servidor DHCP ou especificar uma lista de endereços IP estáticos, tem de ter endereços IP suficientes disponíveis para o seu cluster de utilizadores. Para uma explicação de quantos endereços IP precisa, consulte o artigo Planeie os seus endereços IP.

loadBalancer

Reserve um IP virtual para o servidor da API Kubernetes do cluster de utilizador. Reserve outro VIP para o serviço de entrada do cluster de utilizadores. Forneça os seus VIPs como valores para loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.ingressVIP.

Decida que tipo de equilíbrio de carga quer usar. As opções são as seguintes:

• Balanceamento de carga integrado do MetalLB. Definir loadBalancer.kind para "MetalLB". Preencha também a secção loadBalancer.metalLB.addressPools e defina enableLoadBalancer como true para, pelo menos, um dos seus grupos de nós. Para mais informações, consulte o artigo Equilíbrio de carga integrado com o MetalLB.

• Balanceamento de carga manual. Defina loadBalancer.kind como "ManualLB" e preencha a secção manualLB. Para mais informações, consulte o artigo Equilíbrio de carga manual.

Para mais informações sobre as opções de equilíbrio de carga, consulte o artigo Vista geral do equilíbrio de carga.

advancedNetworking

Se planeia criar um gateway de NAT de saída, defina advancedNetworking como true.

multipleNetworkInterfaces

Decida se quer configurar várias interfaces de rede para pods e defina multipleNetworkInterfaces em conformidade.

storage

Se quiser desativar a implementação de componentes do CSI do vSphere, defina storage.vSphereCSIDisabled como true.

masterNode

Na secção masterNode, pode especificar quantos nós do plano de controlo quer para o cluster de utilizadores: especifique 3 para um cluster de alta disponibilidade (HA) ou 1 para um cluster sem HA. Também pode especificar um arquivo de dados para os nós do plano de controlo e se quer ativar a alteração automática do tamanho para os nós do plano de controlo.

Se o campo enableAdvancedCluster for true, tem de definir o campo replicas como 3. Apenas são suportados clusters de utilizadores de HA em clusters avançados.

Lembre-se de que especificou endereços IP para os nós do plano de controlo na secção network.controlPlaneIPBlock.

nodePools

Um conjunto de nós é um grupo de nós num cluster que têm todos a mesma configuração. Por exemplo, os nós num conjunto podem executar o Windows e os nós noutro conjunto podem executar o Linux.

Tem de especificar, pelo menos, um conjunto de nós preenchendo a secção nodePools.

Se ativar o cluster avançado, defina nodePools[i]osImageType como ubuntu_cgroupv2 ou ubuntu_containerd.

Para mais informações, consulte os artigos Pools de nós e Criar e gerir pools de nós.

antiAffinityGroups

Defina antiAffinityGroups.enabled como true ou false.

Este campo especifica se o Google Distributed Cloud cria regras de antiafinidade do Distributed Resource Scheduler (DRS) para os seus nós de trabalho, o que faz com que sejam distribuídos por, pelo menos, três anfitriões físicos no seu centro de dados.

stackdriver

Se quiser ativar o Cloud Logging e o Cloud Monitoring para o seu cluster, preencha a secção stackdriver.

Esta secção é obrigatória por predefinição. Ou seja, se não preencher esta secção, tem de incluir a flag --skip-validation-stackdriver quando executar gkectl create cluster.

Tenha em atenção os seguintes requisitos para novos clusters:

• O ID em stackdriver.projectID tem de ser igual ao ID em gkeConnect.projectID e cloudAuditLogging.projectID.

• A Google Cloud região definida em stackdriver.clusterLocation tem de ser igual à região definida em cloudAuditLogging.clusterLocation e gkeConnect.location. Além disso, se gkeOnPremAPI.enabled for true, tem de definir a mesma região em gkeOnPremAPI.location.

Se os IDs dos projetos e as regiões não forem os mesmos, a criação do cluster falha.

gkeConnect

O seu cluster de utilizadores tem de estar registado numa Google Cloud frota.

Preencha a secção gkeConnect para especificar um projeto anfitrião da frota e uma conta de serviço associada. O ID em gkeConnect.projectID tem de ser igual ao ID definido em stackdriver.projectID e cloudAuditLogging.projectID. Se os IDs dos projetos não forem iguais, a criação do cluster falha.

Na versão 1.28 e posteriores, pode especificar opcionalmente uma região onde os serviços Fleet e Connect são executados em gkeConnect.location. Se não incluir este campo, o cluster usa as instâncias globais destes serviços.

Importante: se planear instalar o Cloud Service Mesh num cluster regional, tem de instalar a versão 1.19.3 ou posterior.

Se incluir gkeConnect.location no ficheiro de configuração, a região especificada tem de ser igual à região configurada em cloudAuditLogging.clusterLocation, stackdriver.clusterLocation e gkeOnPremAPI.location. Se as regiões não forem as mesmas, a criação de clusters falha.

gkeOnPremAPI

Na versão 1.16 e posteriores, se a API GKE On-Prem estiver ativada no seu Google Cloud projeto, todos os clusters no projeto são inscritos na API GKE On-Prem automaticamente na região configurada em stackdriver.clusterLocation. A região gkeOnPremAPI.location tem de ser igual à região especificada em cloudAuditLogging.clusterLocation, gkeConnect.location (se o campo estiver incluído no ficheiro de configuração) e stackdriver.clusterLocation.

• Se quiser inscrever todos os clusters no projeto na API GKE On-Prem, certifique-se de que executa os passos em Antes de começar para ativar e usar a API GKE On-Prem no projeto.

• Se não quiser inscrever o cluster na API GKE On-Prem, inclua esta secção e defina gkeOnPremAPI.enabled como false. Se não quiser inscrever nenhum cluster no projeto, desative gkeonprem.googleapis.com (o nome do serviço para a API GKE On-Prem) no projeto. Para ver instruções, consulte o artigo Desativar serviços.

cloudAuditLogging

Se quiser integrar os registos de auditoria do servidor da API Kubernetes do seu cluster com os registos de auditoria da nuvem, preencha a secção cloudAuditLogging.

Tenha em atenção os seguintes requisitos:

• Se ativar o cluster avançado, defina cloudAuditLogging.serviceAccountKeyPath para o mesmo caminho que stackdriver.serviceAccountKeyPath.

• O ID em cloudAuditLogging.projectID tem de ser igual ao ID em gkeConnect.projectID e stackdriver.projectID.

• A região em cloudAuditLogging.clusterLocation tem de ser a mesma que a região definida em gkeConnect.location e stackdriver.clusterLocation. Além disso, se gkeOnPremAPI.enabled for true, tem de definir a mesma região em gkeOnPremAPI.location.

Se os IDs dos projetos e as regiões não forem os mesmos, a criação do cluster falha.

Exemplo de ficheiros de configuração preenchidos

Segue-se um exemplo de um ficheiro de bloqueio de IP e um ficheiro de configuração de cluster de utilizadores:

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.33.0-gke.799
enableControlplaneV2: true
enableDataplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.21.30-172.16.21.39"
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  enableLoadBalancer: true
antiAffinityGroups:
  enabled: true
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

Seguem-se os pontos importantes a compreender no exemplo anterior:

• O campo nodePools.replicas está definido como 3, o que significa que existem três nós de trabalho em "worker-node-pool". Todos os nós de trabalho usam endereços IP estáticos porque network.ipMode.type está definido como "static".

• Os endereços IP estáticos dos nós de trabalho são especificados num ficheiro de blocos de IP. O ficheiro de bloqueio de IP tem quatro endereços, apesar de existirem apenas três nós de trabalho. O endereço IP adicional é necessário durante a atualização, a atualização e a reparação automática do cluster.

• Os servidores DNS e NTP são especificados na secção hostConfig. Neste exemplo, estes servidores DNS e NTP destinam-se aos nós do plano de controlo e aos nós de trabalho. Isto deve-se ao facto de os nós de trabalho terem endereços IP estáticos. Se os nós de trabalho obtivessem os respetivos endereços IP de um servidor DHCP, estes servidores DNS e NTP seriam apenas para os nós do plano de controlo.

• Os endereços IP estáticos para os três nós do plano de controlo são especificados na secção network.controlPlaneIPBlock do ficheiro de configuração do cluster de utilizadores. Não é necessário um endereço IP adicional neste bloco.

• O plano de controlo V2 está ativado.

• O campo masterNode.replicas está definido como 3, pelo que o cluster tem um plano de controlo de alta disponibilidade.

• O VIP do plano de controlo e o VIP de entrada estão ambos na mesma VLAN que os nós de trabalho e os nós do plano de controlo.

• Os VIPs reservados para serviços do tipo LoadBalancer são especificados na secção loadBalancer.metalLB.addressPools do ficheiro de configuração do cluster de utilizadores. Estes IPs virtuais estão na mesma VLAN que os nós de trabalho e os nós do plano de controlo. O conjunto de VIPs especificados nesta secção tem de incluir o VIP de entrada e não pode incluir o VIP do plano de controlo.

• O ficheiro de configuração do cluster de utilizadores não inclui uma secção vCenter. Assim, o cluster de utilizadores usa os mesmos recursos do vSphere que o cluster de administrador.

Valide o ficheiro de configuração

Depois de preencher o ficheiro de configuração do cluster de utilizadores, execute o comando gkectl check-config para verificar se o ficheiro é válido:

gkectl check-config --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua o seguinte:

• ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig para o cluster de administrador

• USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de utilizadores

Se o comando devolver mensagens de falha, corrija os problemas e valide o ficheiro novamente.

Se quiser ignorar as validações mais demoradas, transmita a flag --fast. Para ignorar validações individuais, use as flags --skip-validation-xxx. Para saber mais acerca do comando check-config, consulte o artigo Executar verificações pré-publicação.

(Opcional) Importe imagens do SO para o vSphere e envie imagens de contentores para um registo privado

Execute gkectl prepare se alguma das seguintes afirmações for verdadeira:

• O cluster de utilizadores está num centro de dados do vSphere diferente do cluster de administração.

• O cluster de utilizadores tem um vCenter Server diferente do cluster de administrador.

• O cluster de utilizadores tem uma pasta do vCenter diferente do cluster de administrador.

• O seu cluster de utilizadores usa um registo de contentores privado diferente do registo privado usado pelo seu cluster de administrador.

gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path BUNDLE \
    --user-cluster-config USER_CLUSTER_CONFIG

Substitua o seguinte:

• ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador

• BUNDLE: o caminho do ficheiro do pacote. Este ficheiro está na estação de trabalho do administrador em /var/lib/gke/bundles/. Por exemplo:

  /var/lib/gke/bundles/gke-onprem-vsphere-1.33.0-gke.799-full.tgz
  

• USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de utilizadores

Crie um cluster de utilizadores

Execute o seguinte comando para criar um cluster de utilizadores:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Se usar os VPC Service Controls, pode ver erros quando executar alguns comandos gkectl, como "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Para evitar estes erros, adicione o parâmetro --skip-validation-gcp aos seus comandos.

Localize o ficheiro kubeconfig do cluster de utilizadores

O comando gkectl create cluster cria um ficheiro kubeconfig denominado USER_CLUSTER_NAME-kubeconfig no diretório atual. Vai precisar deste ficheiro kubeconfig mais tarde para interagir com o cluster de utilizadores.

O ficheiro kubeconfig contém o nome do cluster de utilizadores. Para ver o nome do cluster, pode executar o seguinte comando:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

O resultado mostra o nome do cluster. Por exemplo:

NAME
my-user-cluster

Se quiser, pode alterar o nome e a localização do ficheiro kubeconfig.

Verifique se o cluster de utilizadores está em execução

Verifique se o cluster de utilizadores está em execução:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de utilizadores.

O resultado mostra os nós do cluster de utilizadores. Por exemplo:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Consola

Começar

1. Na Google Cloud consola, aceda à página Criar cluster de VMs.

   Aceda a Criar cluster de VMs

2. Selecione o Google Cloud projeto no qual quer criar o cluster. O projeto selecionado é usado como o projeto anfitrião da frota. Tem de ser o mesmo projeto no qual o cluster de administrador está registado. Depois de criar o cluster de utilizadores, este é registado automaticamente na frota do projeto selecionado.

3. Na secção Escolha o tipo de cluster, selecione Criar um cluster de utilizadores para um cluster de administrador existente.

Noções básicas sobre clusters

Introduza informações básicas sobre o cluster.

1. Introduza um nome para o cluster de utilizadores.

2. Em Cluster de administrador, selecione o cluster de administrador na lista. Se não especificou um nome para o cluster de administrador quando o criou, o nome é gerado no formato gke-admin-[HASH]. Se não reconhecer o nome do cluster de administrador, execute o seguinte comando na sua estação de trabalho de administrador:

   KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
   kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
   

   Se o cluster de administrador que quer usar não for apresentado, consulte a secção de resolução de problemas O cluster de administrador não é apresentado na lista pendente Noções básicas do cluster.

3. No campo Localização da API GCP, selecione a Google Cloud região na lista. Esta definição especifica a região onde as seguintes APIs e serviços são executados:

   • API GKE On-Prem (gkeonprem.googleapis.com)
   • Serviço de frota (gkehub.googleapis.com)
   • Serviço Connect (gkeconnect.googleapis.com)

   Esta definição também controla a região na qual os seguintes elementos são armazenados:

   • Os metadados do cluster de utilizadores de que a API GKE On-Prem precisa para gerir o ciclo de vida do cluster
   • Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
   • O registo de auditoria do administrador criado pelos registos de auditoria da nuvem

   O nome do cluster, o projeto e a localização identificam de forma exclusiva o cluster no Google Cloud.

4. Selecione a versão do Google Distributed Cloud para o cluster de utilizadores.

5. Como criador do cluster, recebe privilégios de administrador do cluster para o cluster. Opcionalmente, introduza o endereço de email de outro utilizador que vai administrar o cluster no campo Utilizador administrador do cluster na secção Autorização.

   Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para lhe conceder, bem como a outros utilizadores administradores, a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.

   Nota: além das políticas RBAC do Kubernetes, tem de conceder algumas funções de gestão de identidades e acessos (IAM) aos utilizadores que não são proprietários do projeto. Para ver detalhes sobre a concessão das funções de IAM, consulte Conceda as funções necessárias.

6. Clique em Seguinte para aceder à secção Plano de controlo.

Plano de controlo

Todos os campos na secção Plano de controlo estão definidos com valores predefinidos. Reveja as predefinições e, opcionalmente, altere-as conforme necessário.

1. No campo vCPUs do nó do plano de controlo, introduza o número de vCPUs (mínimo de 4) para cada nó do plano de controlo do cluster de utilizadores.

2. No campo Memória do nó do plano de controlo, introduza o tamanho da memória em MiB (mínimo de 8192 e tem de ser um múltiplo de 4) para cada plano de controlo do seu cluster de utilizadores.

3. Em Nós do plano de controlo, selecione o número de nós do plano de controlo para o cluster de utilizadores. Por exemplo, pode selecionar 1 nó do plano de controlo para um ambiente de desenvolvimento e 3 nós do plano de controlo para ambientes de produção de alta disponibilidade (HA).

4. Opcionalmente, selecione Redimensionamento automático de nós. A alteração do tamanho significa que os recursos de vCPU e memória atribuídos a um nó são ajustados automaticamente. Quando ativados, os nós do plano de controlo do cluster de utilizadores são redimensionados de acordo com o número de nós de trabalho no cluster de utilizadores. Assim, à medida que adiciona mais nós de trabalho ao cluster de utilizadores, o tamanho dos nós do plano de controlo aumenta.

5. Na secção IPs dos nós do plano de controlo, introduza os endereços IP do gateway, da máscara de sub-rede e dos nós do plano de controlo.

6. Clique em Seguinte para aceder à secção Rede.

Trabalhar em rede

Nesta secção, especifica os endereços IP dos nós, dos pods e dos serviços do cluster. Um cluster de utilizadores tem de ter um endereço IP para cada nó e um endereço IP adicional para um nó temporário necessário durante as atualizações, as atualizações e a reparação automática do cluster. Para mais informações, consulte o artigo De quantos endereços IP precisa um cluster de utilizadores?.

1. Na secção IPs de nós, selecione o modo de IP para o cluster de utilizadores. Selecione uma das seguintes opções:

   • DHCP: escolha DHCP se quiser que os nós do cluster recebam o respetivo endereço IP de um servidor DHCP.

   • Estático: escolha Estático se quiser fornecer endereços IP estáticos para os nós do cluster ou se quiser configurar o equilíbrio de carga manual.

2. Se selecionou DHCP, avance para o passo seguinte para especificar os CIDRs de serviço e de pod. Para o modo de IP estático, faculte as seguintes informações:

   1. Introduza o endereço IP do gateway para o cluster de utilizadores.

   2. Introduza a máscara de sub-rede para os nós do cluster de utilizadores.

   3. Na secção Endereços IP, introduza os endereços IP e, opcionalmente, os nomes dos anfitriões para os nós no cluster de utilizadores. Pode introduzir um endereço IPv4 individual (como 192.0.2.1) ou um bloco CIDR de endereços IPv4 (como 192.0.2.0/24).

      • Se introduzir um bloco CIDR, não introduza um nome de anfitrião.

      • Se introduzir um endereço IP individual, pode introduzir opcionalmente um nome de anfitrião. Se não introduzir um nome de anfitrião, o Google Distributed Cloud usa o nome da VM do vSphere como o nome de anfitrião.

   4. Clique em + Adicionar endereço IP conforme necessário para introduzir mais endereços IP.

3. Na secção CIDRs de serviços e pods, a consola fornece os seguintes intervalos de endereços para os seus serviços e pods do Kubernetes:

   • CIDR de serviço: 10.96.0.0/20
   • CIDR do pod: 192.168.0.0/16

   Se preferir introduzir os seus próprios intervalos de endereços, consulte o artigo Endereços IP para pods e serviços para ver as práticas recomendadas.

4. Se selecionou Modo de IP estático ou Ativar plano de controlo v2, especifique as seguintes informações na secção Configuração do anfitrião:

   1. Introduza os endereços IP dos servidores DNS.
   2. Introduza os endereços IP dos servidores NTP.
   3. Opcionalmente, introduza domínios de pesquisa de DNS.

5. Clique em Seguinte para aceder à secção Equilibrador de carga.

Balanceador de carga

Escolha o equilibrador de carga a configurar para o seu cluster. Consulte a vista geral do equilibrador de carga para mais informações.

Selecione o Tipo de balanceador de carga na lista.

Incluído no MetalLB

Configure o balanceamento de carga integrado com o MetalLB. Pode usar o MetalLB para o cluster de utilizadores apenas se o cluster de administrador estiver a usar o SeeSaw ou o MetalLB. Esta opção requer uma configuração mínima. O MetalLB é executado diretamente nos nós do cluster e não requer VMs adicionais. Para mais informações sobre as vantagens da utilização do MetalLB e como se compara com as outras opções de equilíbrio de carga, consulte o artigo Equilíbrio de carga incluído com o MetalLB.

1. Na secção Conjuntos de endereços, configure, pelo menos, um conjunto de endereços, da seguinte forma:

   1. Introduza um nome para o conjunto de endereços.

   2. Introduza um intervalo de endereços IP que contenha o VIP de entrada na notação CIDR (por exemplo, 192.0.2.0/26) ou notação de intervalo (por exemplo, 192.0.2.64-192.0.2.72). Para especificar um único endereço IP num conjunto, use /32 na notação CIDR (por exemplo, 192.0.2.1/32).

   3. Se os endereços IP dos seus serviços do tipo LoadBalancer não estiverem no mesmo intervalo de endereços IP que o VIP de entrada, clique em + Adicionar intervalo de endereços IP e introduza outro intervalo de endereços.

      Os endereços IP em cada conjunto não podem sobrepor-se e têm de estar na mesma sub-rede que os nós do cluster.

   4. Em Atribuição de endereços IP, selecione uma das seguintes opções:

      • Automático: escolha esta opção se quiser que o controlador MetalLB atribua automaticamente endereços IP do conjunto de endereços aos serviços do tipo LoadBalancer

      • Manual: escolha esta opção se pretender usar endereços do conjunto para especificar manualmente endereços para serviços do tipo LoadBalancer

   5. Clique em Evitar endereços IP com erros se quiser que o controlador MetalLB não use endereços do conjunto que terminam em .0 ou .255. Isto evita o problema de dispositivos de consumo com erros que eliminam por engano o tráfego enviado para esses endereços IP especiais.

   6. Quando terminar, clique em Concluído.

2. Se necessário, clique em Adicionar conjunto de endereços.

3. Na secção IPs virtuais, introduza o seguinte:

   • VIP do plano de controlo: o endereço IP de destino a usar para o tráfego enviado para o servidor da API Kubernetes do cluster de utilizador. O servidor da API Kubernetes para o cluster de utilizador é executado num nó no cluster de administrador. Este endereço IP tem de estar no mesmo domínio L2 que os nós do cluster de administrador. Não adicione este endereço na secção Conjuntos de endereços.

   • VIP de entrada: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada. Tem de adicionar este intervalo a um conjunto de endereços na secção Conjuntos de endereços.

4. Clique em Continuar.

F5 BIG-IP

Pode usar o F5 BIG-IP para o cluster de utilizadores apenas se o cluster de administrador estiver a usar o F5 BIG-IP. Certifique-se de que instala e configura o F5 BIG-IP ADC antes de o integrar com o Google Distributed Cloud.

O nome de utilizador e a palavra-passe do F5 são herdados do cluster de administrador.

1. Na secção IPs virtuais, introduza o seguinte:

   • VIP do plano de controlo: o endereço IP de destino a usar para o tráfego enviado para o servidor da API Kubernetes.

   • VIP de entrada: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada.

2. No campo Endereço, introduza o endereço do seu equilibrador de carga F5 BIG-IP.

3. No campo Partição, introduza o nome de uma partição do BIG-IP que criou para o seu cluster de utilizadores.

4. No campo Nome do conjunto de sNAT, introduza o nome do seu conjunto de sNAT, se aplicável.

5. Clique em Continuar.

Manual

Só pode usar um equilibrador de carga manual para o cluster de utilizadores se o cluster de administrador usar um equilibrador de carga manual. No Google Distributed Cloud, o servidor da API Kubernetes e o proxy de entrada são expostos por um serviço Kubernetes do tipo LoadBalancer. Escolha os seus próprios valores nodePort no intervalo de 30000 a 32767 para estes serviços. Para o proxy de entrada, escolha um valor nodePort para o tráfego HTTP e HTTPS. Consulte o artigo Ativar o modo de equilíbrio de carga manual para mais informações.

1. Na secção IPs virtuais, introduza o seguinte:

   • VIP do plano de controlo: o endereço IP de destino a usar para o tráfego enviado para o servidor da API Kubernetes.

   • VIP de entrada: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada.

2. No campo Porta do nó do plano de controlo, introduza um valor nodePort para o servidor da API Kubernetes.

3. No campo Ingress HTTP node port, introduza um valor nodePort para o tráfego HTTP para o proxy de entrada.

4. No campo Ingress HTTPS node port, introduza um valor nodePort para o tráfego HTTPS para o proxy de entrada.

5. No campo Porta do nó do servidor Konnectivity, introduza um valor nodePort para o servidor Konnectivity.

6. Clique em Continuar.

Funcionalidades

Esta secção apresenta as funcionalidades e as operações ativadas no cluster.

1. As seguintes opções são ativadas automaticamente e não podem ser desativadas:

   • Cloud Logging de serviços do sistema

   • Cloud Monitoring dos serviços do sistema

   • O registo de auditoria de atividade do administrador

2. As seguintes opções estão ativadas por predefinição, mas pode desativá-las:

   • Ative o controlador CSI do vSphere: também denominado plug-in de armazenamento de contentores do vSphere. O controlador da interface de armazenamento de contentores (CSI) é executado num cluster do Kubernetes implementado no vSphere para aprovisionar volumes persistentes no armazenamento do vSphere. Para mais informações, consulte o artigo Usar o controlador da interface de armazenamento de contentores do vSphere.

   • Ative grupos de antiafinidade: as regras de antiafinidade do VMware Distributed Resource Scheduler (DRS) são criadas automaticamente para os nós do cluster de utilizadores, o que faz com que sejam distribuídos por, pelo menos, 3 anfitriões físicos no seu centro de dados. Certifique-se de que o seu ambiente vSphere cumpre os requisitos.

   Nota: se seguiu o procedimento Configure a infraestrutura mínima, só tem um anfitrião ESXi, por isso, certifique-se de que desmarca a opção Ativar grupos de antiafinidade.

3. Clique em Seguinte para configurar um conjunto de nós

Node pools

O cluster é criado com, pelo menos, um conjunto de nós. Um conjunto de nós é um modelo para um grupo de nós de trabalho criados neste cluster. Para mais informações, consulte o artigo Criar e gerir conjuntos de nós .

1. Na secção Predefinições do conjunto de nós, conclua o seguinte:

   1. Introduza o Nome do conjunto de nós ou aceite "default-pool" como nome.
   2. Introduza o número de vCPUs para cada nó no conjunto (mínimo de 4 por worker do cluster de utilizadores).
   3. Introduza o tamanho da memória em mebibytes (MiB) para cada nó no conjunto (mínimo de 8192 MiB por nó de trabalho do cluster de utilizadores e tem de ser um múltiplo de 4).
   4. No campo Nodes (Nós), introduza o número de nós no conjunto (mínimo de 3). Se introduziu endereços IP estáticos para os IPs dos nós na secção Rede, certifique-se de que introduziu IPs suficientes para acomodar estes nós do cluster de utilizadores.
   5. Selecione o tipo de imagem do SO: Ubuntu, Ubuntu Containerd ou COS.
   6. Introduza o tamanho do disco de arranque em gibibytes (GiB) (mínimo de 40 GiB).
   7. Se estiver a usar o MetalLB como equilibrador de carga, o MetalLB tem de estar ativado em, pelo menos, um conjunto de nós. Deixe a opção Usar este conjunto de nós para o balanceamento de carga do MetalLB selecionada ou adicione outro conjunto de nós para usar para o MetalLB.

2. Na secção Metadados do node pool (opcional), se quiser adicionar etiquetas do Kubernetes e restrições, faça o seguinte:

   1. Clique em + Adicionar etiquetas do Kubernetes. Introduza a Chave e o Valor da etiqueta. Repita estes passos conforme necessário.
   2. Clique em + Adicionar contaminação. Introduza a Chave, o Valor e o Efeito da contaminação. Repita estes passos conforme necessário.

3. Clique em Validar e concluir para criar o cluster de utilizadores. A criação do cluster de utilizadores demora 15 minutos ou mais. A consola apresenta mensagens de estado à medida que valida as definições e cria o cluster no seu centro de dados.

   Se for encontrado um erro ao validar as definições, a consola apresenta uma mensagem de erro que deve ser suficientemente clara para corrigir o problema de configuração e tentar novamente criar o cluster.

   Para mais informações sobre possíveis erros e como os corrigir, consulte o artigo Resolva problemas de criação de clusters de utilizadores na Google Cloud consola.

CLI gcloud

Use o seguinte comando para criar um cluster de utilizadores:

gcloud container vmware clusters create

Depois de criar o cluster, tem de criar, pelo menos, um node pool com o seguinte comando:

gcloud container vmware node-pools create

A maioria das flags para criar o cluster e o node pool corresponde aos campos no ficheiro de configuração do cluster de utilizadores. Para ajudar a começar, pode testar um comando completo na secção exemplos.

Recolha informações

Reúna algumas informações necessárias para criar o cluster.

1. Obtenha o nome e a localização da associação à frota do cluster de administrador:

   gcloud container fleet memberships list \
       --project=FLEET_HOST_PROJECT_ID
   

   Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto no qual o cluster de administrador está registado.

   O resultado é semelhante ao seguinte:

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   A localização especifica onde os serviços Fleet e Connect são executados. Os clusters de administrador criados antes da versão 1.28 são geridos pelos serviços globais da frota e do Connect. Na versão 1.28 e superior, pode especificar global ou uma região quando cria o cluster de administrador. Google Cloud Especifica a região no comando --admin-cluster-membership-location no exemplo de comandos que se segue.

2. Obtenha uma lista das versões disponíveis:

   gcloud container vmware clusters query-version-config \
       --admin-cluster-membership=ADMIN_CLUSTER_NAME \
       --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
       --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
       --location=REGION
   

   Substitua o seguinte:

   • ADMIN_CLUSTER_NAME: o nome do cluster de administrador.

   • FLEET_HOST_PROJECT_ID: o ID do projeto no qual o cluster de administrador está registado.

   • ADMIN_CLUSTER_REGION: a região de associação da frota do cluster de administrador. Esta opção é global ou de uma Google Cloud região. Use a localização do cluster de administrador a partir do resultado de gcloud container fleet memberships list.

   • REGION: a Google Cloud região que vai usar quando criar o cluster de utilizadores. Esta é a região em que a API GKE On-Prem é executada e armazena os respetivos metadados.

     • Se o cluster de administrador estiver inscrito na API GKE On-Prem, use a mesma região que o cluster de administrador. Para saber a região do cluster de administrador, execute o seguinte comando:

       gcloud container vmware admin-clusters list \
         --project=FLEET_HOST_PROJECT_ID \
         --location=-
       

     • Se o cluster de administrador não estiver inscrito na API GKE On-Prem, especifique us-west1 ou outra região suportada. Se inscrever posteriormente o cluster de administrador na API GKE On-Prem, use a mesma região em que o cluster de utilizador se encontra.

   O resultado do comando gcloud container vmware clusters query-version-config é semelhante ao seguinte:

   versions:
   - isInstalled: true
     version: 1.28.800-gke.109
   - version: 1.29.0-gke.1456
   - version: 1.29.100-gke.248
   - version: 1.29.200-gke.245
   - version: 1.29.300-gke.184
   

   O comando também produz uma explicação das versões que pode usar para a criação ou a atualização do cluster de utilizadores. As versões permitidas são anotadas com isInstalled: true, o que significa que o cluster de administrador tem os componentes específicos da versão de que precisa para gerir clusters de utilizadores dessa versão. Se quiser usar uma versão instalada no cluster de administrador, avance para a secção Exemplos para criar o cluster de utilizador.

Instale uma versão diferente

Um cluster de administrador pode gerir clusters de utilizadores em diferentes versões. O resultado do comando query-version-config apresenta outras versões que pode usar quando cria o cluster. Se quiser criar um cluster de utilizadores que seja uma versão diferente do cluster de administrador, tem de transferir e implementar os componentes de que o cluster de administrador precisa para gerir clusters de utilizadores dessa versão, da seguinte forma:

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

Substitua VERSION por uma das versões indicadas no resultado do comando query-version-config.

O comando transfere a versão dos componentes que especificar em --required-platform-version para o cluster de administrador e, em seguida, implementa os componentes. Já pode criar um cluster de utilizadores com a versão especificada.

Se executar novamente o comando gcloud container vmware clusters query-version-config, a versão especificada é anotada com isInstalled: true.

Exemplos

Os exemplos seguintes mostram como criar um cluster de utilizadores com diferentes balanceadores de carga com o Controlplane V2 ativado. Com o Controlplane V2, o plano de controlo para um cluster de utilizadores é executado num ou mais nós no próprio cluster de utilizadores. Recomendamos que ative o Controlplane V2 e, na versão 1.30 e superior, os novos clusters de utilizadores têm de ter o Controlplane V2 ativado. Para obter informações acerca das opções de balanceamento de carga disponíveis, consulte a Vista geral do balanceador de carga.

A maioria dos exemplos usa os valores predefinidos para configurar os nós do plano de controlo. Se quiser alterar alguma das predefinições, inclua as flags descritas na secção Flags do plano de controlo. Se necessário, também pode alterar algumas definições do vSphere.

Antes de executar o comando gcloud para criar o cluster, pode incluir --validate-only para validar a configuração especificada nas flags para o comando gcloud. Quando tiver tudo pronto para criar o cluster, remova esta flag e execute o comando.

Se receber um erro após a execução do comando gcloud container vmware clusters create durante cerca de um minuto ou mais, verifique se o cluster foi criado parcialmente executando o seguinte comando:

gcloud container vmware clusters list \
    --project=FLEET_HOST_PROJECT_ID \
    --location=-

Se o cluster não estiver listado no resultado, corrija o erro e volte a executar o comando gcloud container vmware clusters create.

Se o cluster estiver listado no resultado, elimine-o através do seguinte comando:

gcloud container vmware clusters delete USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --force \
    --allow-missing

Em seguida, corrija o erro e execute novamente gcloud container vmware clusters create.

Depois de o cluster estar em execução, tem de adicionar um conjunto de nós antes de implementar cargas de trabalho, conforme descrito na secção Crie um conjunto de nós.

MetalLB e DHCP

Este exemplo mostra como criar um cluster de utilizadores com o balanceador de carga MetalLB incluído e usar o seu servidor DHCP para obter endereços IP para os nós de trabalho do cluster.

Só pode usar o MetalLB para o cluster de utilizadores se o cluster de administrador estiver a usar o MetalLB. Esta opção de equilíbrio de carga requer uma configuração mínima. O MetalLB é executado diretamente nos nós do cluster e não requer VMs adicionais. Para mais informações sobre as vantagens da utilização do MetalLB e como se compara com as outras opções de equilíbrio de carga, consulte o artigo Equilíbrio de carga integrado com o MetalLB.

O comando de exemplo cria um cluster de utilizadores com as seguintes características, que pode modificar conforme necessário para o seu ambiente.

Bandeira	Descrição
--admin-users	Concede-lhe e a outro utilizador direitos administrativos completos no cluster.
--enable-control-plane-v2	Ativa o Controlplane V2, que é recomendado e obrigatório na versão 1.30 e superior.
--control-plane-ip-block	Um endereço IP para o nó do plano de controlo. Para criar um cluster de utilizadores de alta disponibilidade (HA), especifique três endereços IP e adicione a flag --replicas=3.
--metal-lb-config-address-pools	Dois conjuntos de endereços para o balanceador de carga MetalLB. Precisa de, pelo menos, um conjunto de endereços e pode especificar mais, se necessário. Para maior conveniência, o exemplo contém um conjunto de endereços com o nome "ingress-vip-pool" como lembrete de que o endereço IP do VIP de entrada tem de estar num dos conjuntos de endereços. Pode especificar o CIDR para um único endereço IP anexando /32 ao endereço IP.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --enable-dhcp

Substitua o seguinte:

• USER_CLUSTER_NAME: um nome à sua escolha para o cluster de utilizadores. Não é possível alterar o nome após a criação do cluster. O nome tem de:
  • Conter, no máximo, 40 carateres
  • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
  • Começar com um caráter alfabético
  • Terminar com um caráter alfanumérico
• FLEET_HOST_PROJECT_ID: o ID do projeto no qual quer criar o cluster. O projeto especificado também é usado como o projeto de anfitrião da frota. Tem de ser o mesmo projeto no qual o cluster de administrador está registado. Após a criação do cluster de utilizadores, este é automaticamente registado na frota do projeto selecionado. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.
• ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gere o cluster de utilizadores. Na flag --admin-cluster-membership, pode usar o nome do cluster totalmente especificado, que tem o seguinte formato:

      projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

  Em alternativa, pode definir --admin-cluster-membership para o nome do cluster de administração, como no comando de exemplo. Quando usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e a localização com --admin-cluster-membership-location. A localização do cluster de administrador é global ou uma região Google Cloud . Se precisar de encontrar a região, execute gcloud container fleet memberships list.

• REGION: A Google Cloud região na qual a API GKE On-Prem (gkeonprem.googleapis.com), o serviço Fleet (gkehub.googleapis.com) e o serviço Connect (gkeconnect.googleapis.com) são executados. Especifique us-west1 ou outra região suportada. Não é possível alterar a região após a criação do cluster. Esta definição especifica a região onde os seguintes elementos são armazenados:
  • Os metadados do cluster de utilizadores que a API GKE On-Prem precisa para gerir o ciclo de vida do cluster
  • Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
  • O registo de auditoria do administrador criado pelos registos de auditoria da nuvem

  O nome do cluster, o projeto e a localização identificam em conjunto o cluster de forma exclusiva em Google Cloud.

  Importante Se planeia instalar o Cloud Service Mesh, tem de instalar a versão 1.19.3 ou posterior. Isto é necessário porque os serviços Fleet e Connect são executados numa região.
• VERSION: a versão do Google Distributed Cloud para o seu cluster de utilizador.
• YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se não incluir a flag --admin-users, como criador do cluster, são-lhe concedidos privilégios de administrador do cluster por predefinição. No entanto, se incluir --admin-users para designar outro utilizador como administrador, substitui a predefinição e tem de incluir o seu endereço de email e o endereço de email do outro administrador. Por exemplo, para adicionar dois administradores:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

  Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para lhe conceder a si e a outros utilizadores administradores a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.

  Nota: além das políticas de CABF do Kubernetes, tem de conceder algumas funções de gestão de identidade e de acesso (IAM) aos utilizadores que não são proprietários do projeto. Para ver detalhes sobre a concessão das funções de IAM, consulte Conceda as funções necessárias.

• SERVICE_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para serviços no seu cluster. Tem de ser, pelo menos, um intervalo /24.

  Exemplo: --service-address-cidr-blocks=10.96.0.0/20

• POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para pods no seu cluster. Tem de ser, pelo menos, um intervalo /18.

  Exemplo: --pod-address-cidr-blocks=192.168.0.0/16

• --metal-lb-config-address-pools: inclua este sinalizador para especificar a configuração dos pools de endereços a serem usados pelo balanceador de carga do MetalLB. O valor da flag tem o seguinte formato:
  --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

  O valor tem segmentos que começam com as palavras-chave pool, avoid-buggy-ip, manual-assign e addresses. Separe cada segmento com uma vírgula.

  • pool: um nome à sua escolha para o conjunto.
  • avoid-buggy-ips1: Se definir esta opção como True, o controlador MetalLB não atribui endereços IP que terminem em .0 ou .255 aos serviços. Isto evita o problema de dispositivos de consumo com erros que rejeitam por engano o tráfego enviado para esses endereços IP especiais. Se não for especificado, o fuso horário predefinido é False.
  • manual-assign: se não quiser que o controlador MetalLB atribua automaticamente endereços IP deste conjunto a serviços, defina esta opção como True. Em seguida, um programador pode criar um serviço do tipo LoadBalancer e especificar manualmente um dos endereços do conjunto. Se não for especificado, manual-assign é definido como False.
  • Na lista de addresses: cada endereço tem de ser um intervalo na notação CIDR ou no formato de intervalo com hífen. Para especificar um único endereço IP num conjunto (como para o VIP de entrada), use /32 na notação CIDR, por exemplo: 192.0.2.1/32.

  Tenha em conta o seguinte:

  • Coloque todo o valor entre aspas simples.
  • Não são permitidos espaços em branco.
  • Separe cada intervalo de endereços IP com um ponto e vírgula.

  Por exemplo:

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

• CONTROL_PLANE_VIP: o endereço IP que escolheu para configurar no equilibrador de carga para o servidor da API Kubernetes do cluster de utilizadores.

  Exemplo: --control-plane-vip=203.0.113.3

• INGRESS_VIP: o endereço IP que escolheu para configurar no balanceador de carga para o proxy de entrada.

  Exemplo: --ingress-vip=10.251.134.80

  O endereço IP do VIP de entrada tem de estar num dos conjuntos de endereços do MetalLB.

• --enable-dhcp: inclua --enable-dhcp se quiser que os nós do cluster recebam o respetivo endereço IP de um servidor DHCP que forneça. Não inclua esta flag se quiser fornecer endereços IP estáticos para os nós do cluster ou se quiser configurar o equilíbrio de carga manual.

MetalLB e IPs estáticos

Este exemplo mostra como criar um cluster de utilizadores com o balanceador de carga MetalLB incluído e atribuir endereços IP estáticos aos nós de trabalho do cluster.

Só pode usar o MetalLB para o cluster de utilizadores se o cluster de administrador estiver a usar o MetalLB. Esta opção de equilíbrio de carga requer uma configuração mínima. O MetalLB é executado diretamente nos nós do cluster e não requer VMs adicionais. Para mais informações sobre as vantagens da utilização do MetalLB e como se compara com as outras opções de equilíbrio de carga, consulte o artigo Equilíbrio de carga integrado com o MetalLB.

O comando de exemplo cria um cluster de utilizadores com as seguintes características, que pode modificar conforme necessário para o seu ambiente.

Bandeira	Descrição
--admin-users	Concede-lhe e a outro utilizador direitos administrativos completos no cluster.
--enable-control-plane-v2	Ativa o Controlplane V2, que é recomendado e obrigatório na versão 1.30 e superior.
--control-plane-ip-block	Um endereço IP para o nó do plano de controlo. Para criar um cluster de utilizadores de alta disponibilidade (HA), especifique três endereços IP e adicione a flag --replicas=3.
--metal-lb-config-address-pools	Dois conjuntos de endereços para o balanceador de carga MetalLB. Precisa de, pelo menos, um conjunto de endereços e pode especificar mais, se necessário. Para maior conveniência, o exemplo contém um conjunto de endereços com o nome "ingress-vip-pool" como lembrete de que o endereço IP do VIP de entrada tem de estar num dos conjuntos de endereços. Pode especificar o CIDR para um único endereço IP anexando /32 ao endereço IP.
--static-ip-config-ip-blocks	Quatro endereços IP para os nós de trabalho nos clusters. Isto inclui uma morada para um nó adicional que pode ser usado durante a atualização. Se necessário, pode especificar mais endereços IP. O nome do anfitrião é opcional.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=AVOID_BUGGY_IPS,manual-assign=MANUAL_ASSIGN,addresses=IP_ADDRESS_RANGE_1' \
    --metal-lb-config-address-pools='pool=ingress-vip-pool,avoid-buggy-ips=False,manual-assign=True,addresses=INGRESS_VIP/32' \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

Substitua o seguinte:

• USER_CLUSTER_NAME: um nome à sua escolha para o cluster de utilizadores. Não é possível alterar o nome após a criação do cluster. O nome tem de:
  • Conter, no máximo, 40 carateres
  • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
  • Começar com um caráter alfabético
  • Terminar com um caráter alfanumérico
• FLEET_HOST_PROJECT_ID: o ID do projeto no qual quer criar o cluster. O projeto especificado também é usado como o projeto de anfitrião da frota. Tem de ser o mesmo projeto no qual o cluster de administrador está registado. Após a criação do cluster de utilizadores, este é automaticamente registado na frota do projeto selecionado. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.
• ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gere o cluster de utilizadores. Na flag --admin-cluster-membership, pode usar o nome do cluster totalmente especificado, que tem o seguinte formato:

      projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

  Em alternativa, pode definir --admin-cluster-membership para o nome do cluster de administração, como no comando de exemplo. Quando usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e a localização com --admin-cluster-membership-location. A localização do cluster de administrador é global ou uma região Google Cloud . Se precisar de encontrar a região, execute gcloud container fleet memberships list.

• REGION: A Google Cloud região na qual a API GKE On-Prem (gkeonprem.googleapis.com), o serviço Fleet (gkehub.googleapis.com) e o serviço Connect (gkeconnect.googleapis.com) são executados. Especifique us-west1 ou outra região suportada. Não é possível alterar a região após a criação do cluster. Esta definição especifica a região onde os seguintes elementos são armazenados:
  • Os metadados do cluster de utilizadores que a API GKE On-Prem precisa para gerir o ciclo de vida do cluster
  • Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
  • O registo de auditoria do administrador criado pelos registos de auditoria da nuvem

  O nome do cluster, o projeto e a localização identificam em conjunto o cluster de forma exclusiva em Google Cloud.

  Importante Se planeia instalar o Cloud Service Mesh, tem de instalar a versão 1.19.3 ou posterior. Isto é necessário porque os serviços Fleet e Connect são executados numa região.
• VERSION: a versão do Google Distributed Cloud para o seu cluster de utilizador.
• YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se não incluir a flag --admin-users, como criador do cluster, são-lhe concedidos privilégios de administrador do cluster por predefinição. No entanto, se incluir --admin-users para designar outro utilizador como administrador, substitui a predefinição e tem de incluir o seu endereço de email e o endereço de email do outro administrador. Por exemplo, para adicionar dois administradores:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

  Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para lhe conceder a si e a outros utilizadores administradores a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.

  Nota: além das políticas de CABF do Kubernetes, tem de conceder algumas funções de gestão de identidade e de acesso (IAM) aos utilizadores que não são proprietários do projeto. Para ver detalhes sobre a concessão das funções de IAM, consulte Conceda as funções necessárias.

• SERVICE_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para serviços no seu cluster. Tem de ser, pelo menos, um intervalo /24.

  Exemplo: --service-address-cidr-blocks=10.96.0.0/20

• POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para pods no seu cluster. Tem de ser, pelo menos, um intervalo /18.

  Exemplo: --pod-address-cidr-blocks=192.168.0.0/16

• --metal-lb-config-address-pools: inclua este sinalizador para especificar a configuração dos pools de endereços a serem usados pelo balanceador de carga do MetalLB. O valor da flag tem o seguinte formato:
  --metal-lb-config-address-pool 'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

  O valor tem segmentos que começam com as palavras-chave pool, avoid-buggy-ip, manual-assign e addresses. Separe cada segmento com uma vírgula.

  • pool: um nome à sua escolha para o conjunto.
  • avoid-buggy-ips1: Se definir esta opção como True, o controlador MetalLB não atribui endereços IP que terminem em .0 ou .255 aos serviços. Isto evita o problema de dispositivos de consumo com erros que rejeitam por engano o tráfego enviado para esses endereços IP especiais. Se não for especificado, o fuso horário predefinido é False.
  • manual-assign: se não quiser que o controlador MetalLB atribua automaticamente endereços IP deste conjunto a serviços, defina esta opção como True. Em seguida, um programador pode criar um serviço do tipo LoadBalancer e especificar manualmente um dos endereços do conjunto. Se não for especificado, manual-assign é definido como False.
  • Na lista de addresses: cada endereço tem de ser um intervalo na notação CIDR ou no formato de intervalo com hífen. Para especificar um único endereço IP num conjunto (como para o VIP de entrada), use /32 na notação CIDR, por exemplo: 192.0.2.1/32.

  Tenha em conta o seguinte:

  • Coloque todo o valor entre aspas simples.
  • Não são permitidos espaços em branco.
  • Separe cada intervalo de endereços IP com um ponto e vírgula.

  Por exemplo:

  --metal-lb-config-address-pool 'pool=pool1,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.134.80/32;192.168.1.0/26;192.168.1.2-192.168.1.3'

• CONTROL_PLANE_VIP: o endereço IP que escolheu para configurar no equilibrador de carga para o servidor da API Kubernetes do cluster de utilizadores.

  Exemplo: --control-plane-vip=203.0.113.3

• INGRESS_VIP: o endereço IP que escolheu para configurar no balanceador de carga para o proxy de entrada.

  Exemplo: --ingress-vip=10.251.134.80

  O endereço IP do VIP de entrada tem de estar num dos conjuntos de endereços do MetalLB.

• --static-ip-config-ip-blocks: especifique o gateway predefinido, a máscara de sub-rede e uma lista dos endereços IP estáticos para os nós de trabalho no cluster de utilizadores. O valor da flag tem o seguinte formato:
  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  O valor tem segmentos que começam com as palavras-chave gateway, netmask e ips. Separe os segmentos com uma vírgula.

  Tenha em conta o seguinte:

  • Coloque todo o valor entre aspas simples.
  • Não são permitidos espaços em branco, exceto entre um endereço IP e um nome de anfitrião.

  Na lista de endereços IP:

  • Pode especificar um endereço IP individual ou um bloco CIDR de endereços IP.
  • Separe cada endereço IP ou bloco CIDR com um ponto e vírgula.
  • Para um endereço IP individual, pode especificar opcionalmente um nome de anfitrião após o endereço IP. Separe o endereço IP e o nome do anfitrião com um espaço. Quando não especifica um nome de anfitrião, o Google Distributed Cloud usa o nome da VM do vSphere como o nome de anfitrião.
  • Se especificar um bloco CIDR, não especifique um valor para o nome do anfitrião.

  Por exemplo:

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: Uma lista separada por vírgulas dos endereços IP dos servidores DNS para as VMs.
• DNS_SEARCH_DOMAIN: Uma lista separada por vírgulas dos domínios de pesquisa DNS que os anfitriões devem usar. Estes domínios são usados como parte de uma lista de pesquisa de domínios.

  Por exemplo:

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: Uma lista separada por vírgulas dos endereços IP dos servidores de tempo que as VMs devem usar.

Equilíbrio de carga manual e IPs estáticos

Este exemplo mostra como criar um cluster de utilizadores com um equilibrador de carga manual e atribuir endereços IP estáticos aos nós de trabalho do cluster.

Só pode usar um equilibrador de carga manual para o cluster de utilizadores se o cluster de administrador usar um equilibrador de carga manual. No Google Distributed Cloud, o servidor da API Kubernetes, o proxy de entrada e o serviço de suplemento para agregação de registos são expostos por um serviço Kubernetes do tipo LoadBalancer. Escolha os seus próprios valores nodePort no intervalo de 30000 a 32767 para estes serviços. Para o proxy de entrada, escolha um valor nodePort para o tráfego HTTP e HTTPS. Consulte o artigo Ativar o modo de equilíbrio de carga manual para mais informações.

O comando de exemplo cria um cluster de utilizadores com as seguintes características, que pode modificar conforme necessário para o seu ambiente.

Bandeira	Descrição
--admin-users	Concede-lhe e a outro utilizador direitos administrativos completos no cluster.
--enable-control-plane-v2	Ativa o Controlplane V2, que é recomendado e obrigatório na versão 1.30 e superior.
--control-plane-ip-block	Um endereço IP para o nó do plano de controlo. Para criar um cluster de utilizadores de alta disponibilidade (HA), especifique três endereços IP e adicione a flag --replicas=3.
--static-ip-config-ip-blocks	Quatro endereços IP para os nós de trabalho nos clusters. Isto inclui uma morada para um nó adicional que pode ser usado durante a atualização. Se necessário, pode especificar mais endereços IP. O nome do anfitrião é opcional.

gcloud container vmware clusters create USER_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership=ADMIN_CLUSTER_NAME \
    --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
    --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
    --location=REGION \
    --version=VERSION \
    --admin-users=YOUR_EMAIL_ADDRESS \
    --admin-users=ANOTHER_EMAIL_ADDRESS \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1 CP_HOST_1' \
    --control-plane-vip=CONTROL_PLANE_VIP \
    --ingress-vip=INGRESS_VIP \
    --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
    --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
    --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1 HOST_1;IP_ADDRESS_2 HOST_2;IP_ADDRESS_3 HOST_3;IP_ADDRESS_4 HOST_4' \
    --dns-servers=DNS_SERVER_1 \
    --ntp-servers=NTP_SERVER_1

Substitua o seguinte:

• USER_CLUSTER_NAME: um nome à sua escolha para o cluster de utilizadores. Não é possível alterar o nome após a criação do cluster. O nome tem de:
  • Conter, no máximo, 40 carateres
  • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
  • Começar com um caráter alfabético
  • Terminar com um caráter alfanumérico
• FLEET_HOST_PROJECT_ID: o ID do projeto no qual quer criar o cluster. O projeto especificado também é usado como o projeto de anfitrião da frota. Tem de ser o mesmo projeto no qual o cluster de administrador está registado. Após a criação do cluster de utilizadores, este é automaticamente registado na frota do projeto selecionado. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.
• ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gere o cluster de utilizadores. Na flag --admin-cluster-membership, pode usar o nome do cluster totalmente especificado, que tem o seguinte formato:

      projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

  Em alternativa, pode definir --admin-cluster-membership para o nome do cluster de administração, como no comando de exemplo. Quando usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e a localização com --admin-cluster-membership-location. A localização do cluster de administrador é global ou uma região Google Cloud . Se precisar de encontrar a região, execute gcloud container fleet memberships list.

• REGION: A Google Cloud região na qual a API GKE On-Prem (gkeonprem.googleapis.com), o serviço Fleet (gkehub.googleapis.com) e o serviço Connect (gkeconnect.googleapis.com) são executados. Especifique us-west1 ou outra região suportada. Não é possível alterar a região após a criação do cluster. Esta definição especifica a região onde os seguintes elementos são armazenados:
  • Os metadados do cluster de utilizadores que a API GKE On-Prem precisa para gerir o ciclo de vida do cluster
  • Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
  • O registo de auditoria do administrador criado pelos registos de auditoria da nuvem

  O nome do cluster, o projeto e a localização identificam em conjunto o cluster de forma exclusiva em Google Cloud.

  Importante Se planeia instalar o Cloud Service Mesh, tem de instalar a versão 1.19.3 ou posterior. Isto é necessário porque os serviços Fleet e Connect são executados numa região.
• VERSION: a versão do Google Distributed Cloud para o seu cluster de utilizador.
• YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se não incluir a flag --admin-users, como criador do cluster, são-lhe concedidos privilégios de administrador do cluster por predefinição. No entanto, se incluir --admin-users para designar outro utilizador como administrador, substitui a predefinição e tem de incluir o seu endereço de email e o endereço de email do outro administrador. Por exemplo, para adicionar dois administradores:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

  Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para lhe conceder a si e a outros utilizadores administradores a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.

  Nota: além das políticas de CABF do Kubernetes, tem de conceder algumas funções de gestão de identidade e de acesso (IAM) aos utilizadores que não são proprietários do projeto. Para ver detalhes sobre a concessão das funções de IAM, consulte Conceda as funções necessárias.

• SERVICE_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para serviços no seu cluster. Tem de ser, pelo menos, um intervalo /24.

  Exemplo: --service-address-cidr-blocks=10.96.0.0/20

• POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para pods no seu cluster. Tem de ser, pelo menos, um intervalo /18.

  Exemplo: --pod-address-cidr-blocks=192.168.0.0/16

• CONTROL_PLANE_VIP: O endereço IP que escolheu para configurar no equilibrador de carga para o servidor da API Kubernetes do cluster de utilizadores.

  Exemplo: --control-plane-vip=203.0.113.3

• INGRESS_VIP: o endereço IP que escolheu para configurar no balanceador de carga para o proxy de entrada.

  Exemplo: --ingress-vip=203.0.113.4

• INGRESS_HTTP_NODE_PORT: um valor nodePort para o tráfego HTTP para o proxy de entrada (como 30243).

• INGRESS_HTTPS_NODE_PORT: um valor nodePort para o tráfego HTTPS para o proxy de entrada (como 30879).

• --static-ip-config-ip-blocks: especifique o gateway predefinido, a máscara de sub-rede e uma lista dos endereços IP estáticos para os nós de trabalho no cluster de utilizadores. O valor da flag tem o seguinte formato:
  --static-ip-config-ip-blocks 'gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...'

  O valor tem segmentos que começam com as palavras-chave gateway, netmask e ips. Separe os segmentos com uma vírgula.

  Tenha em conta o seguinte:

  • Coloque todo o valor entre aspas simples.
  • Não são permitidos espaços em branco, exceto entre um endereço IP e um nome de anfitrião.

  Na lista de endereços IP:

  • Pode especificar um endereço IP individual ou um bloco CIDR de endereços IP.
  • Separe cada endereço IP ou bloco CIDR com um ponto e vírgula.
  • Para um endereço IP individual, pode especificar opcionalmente um nome de anfitrião após o endereço IP. Separe o endereço IP e o nome do anfitrião com um espaço. Quando não especifica um nome de anfitrião, o Google Distributed Cloud usa o nome da VM do vSphere como o nome de anfitrião.
  • Se especificar um bloco CIDR, não especifique um valor para o nome do anfitrião.

  Por exemplo:

  --static-ip-config-ip-blocks 'gateway=172.16.23.254,netmask=255.255.252.0,ips=172.16.20.10;172.16.20.11 host2;172.16.20.12/30'

• DNS_SERVER: Uma lista separada por vírgulas dos endereços IP dos servidores DNS para as VMs.
• DNS_SEARCH_DOMAIN: Uma lista separada por vírgulas dos domínios de pesquisa DNS que os anfitriões devem usar. Estes domínios são usados como parte de uma lista de pesquisa de domínios.

  Por exemplo:

  --dns-search-domains example.com,examplepetstore.com

• NTP_SERVER: Uma lista separada por vírgulas dos endereços IP dos servidores de tempo que as VMs devem usar.

Sinalizadores do plano de controlo

Se quiser usar valores não predefinidos para a configuração do plano de controlo, inclua uma ou mais das seguintes flags:

• --cpus=vCPUS: o número de vCPUs (mínimo de 4) para cada nó do plano de controlo do cluster de utilizadores. Se não for especificado, o valor predefinido é 4 vCPUs.

• --memory=MEMORY: o tamanho da memória em mebibytes (MiB) para cada plano de controlo do cluster de utilizadores. O valor mínimo é 8192 e tem de ser um múltiplo de 4. Se não for especificado, o valor predefinido é 8192.

• --replicas=NODES: o número de nós do plano de controlo para o cluster de utilizador. Por exemplo, pode selecionar 1 nó do plano de controlo para um ambiente de desenvolvimento e 3 nós do plano de controlo para ambientes de produção de alta disponibilidade (HA).

• --enable-auto-resize: se quiser ativar a alteração automática do tamanho dos nós do plano de controlo para o cluster de utilizador, inclua --enable-auto-resize. O redimensionamento significa que os recursos de vCPU e memória atribuídos a um nó são ajustados automaticamente. Quando ativados, os nós do plano de controlo para o cluster de utilizador são redimensionados de acordo com o número de nós de trabalho no cluster de utilizador. Assim, à medida que adiciona mais nós de trabalho ao cluster de utilizadores, o tamanho dos nós do plano de controlo aumenta.

• --enable-control-plane-v2: Para ativar o Controlplane V2, que recomendamos, inclua esta flag. Quando o Controlplane V2 está ativado, o plano de controlo para um cluster de utilizadores é executado num ou mais nós no próprio cluster de utilizadores. Na versão 1.30 e superior, o Controlplane V2 é obrigatório.

  Quando ativa o Controlplane V2, também tem de especificar as seguintes flags:

  • --dns-servers=DNS_SERVER_1,...: Uma lista separada por vírgulas dos endereços IP dos servidores DNS para as VMs.

  • --ntp-servers=NTP_SERVER_1,...: Uma lista separada por vírgulas dos endereços IP dos servidores de tempo que as VMs devem usar.

  • --control-plane-ip-block, que tem o seguinte formato:

      --control-plane-ip-block 'gateway=CP_GATEWAY,netmask=CP_NETMASK,ips=CP_IP_ADDRESS_1;CP_IP_ADDRESS_2 CP_HOST_2'

    O valor tem segmentos que começam com as palavras-chave gateway, netmask e ips. Separe os segmentos com uma vírgula.

    Tenha em conta o seguinte:

    • Coloque todo o valor entre aspas simples.

    • Não são permitidos espaços em branco, exceto entre um endereço IP e um nome de anfitrião.

      Na lista de endereços IP:

    • Pode especificar um endereço IP individual ou um bloco de endereços IP CIDR.

    • Separe cada endereço IP ou bloco CIDR com um ponto e vírgula.

    • Para um endereço IP individual, pode especificar opcionalmente um nome de anfitrião após o endereço IP. Separe o endereço IP e o nome do anfitrião com um espaço.

    • Se especificar um bloco CIDR, não especifique um valor para o nome do anfitrião.

      Por exemplo:

      --control-plane-ip-block 'gateway=192.168.0.1,netmask=255.0.0.0,ips=192.168.1.1;192.168.1.2 hostname-2;192.168.2.2/28`
      

  • Opcional: --dns-search-domains=DNS_SEARCH_DOMAIN_1,...: Uma lista separada por vírgulas dos domínios de pesquisa DNS que os anfitriões devem usar. Estes domínios são usados como parte de uma lista de pesquisa de domínios.

    Por exemplo:

    --dns-search-domains example.com,examplepetstore.com

  Para ver uma lista completa das flags e das respetivas descrições, consulte a referência da CLI gcloud.

  Sinalizações do vSphere

  Especifique as seguintes flags opcionais, se necessário:

• --disable-aag-config: se não incluir esta flag, as regras de antiafinidade do VMware Distributed Resource Scheduler (DRS) são criadas automaticamente para os nós do cluster de utilizadores, o que faz com que sejam distribuídos por, pelo menos, 3 anfitriões físicos no seu centro de dados. Certifique-se de que o seu ambiente do vSphere cumpre os requisitos. Se o seu cluster não cumprir os requisitos, inclua esta flag.

  Nota: se seguiu o artigo Configure uma infraestrutura mínima, tem apenas um anfitrião ESXi, por isso, certifique-se de que inclui esta flag.

• --disable-vsphere-csi: se não incluir esta flag, os componentes da interface de armazenamento de contentores (CSI) do vSphere são implementados no cluster de utilizadores. O controlador CSI é executado num cluster Kubernetes nativo implementado no vSphere para aprovisionar volumes persistentes no armazenamento do vSphere. Para mais informações, consulte o artigo Usar o controlador da interface de armazenamento de contentores do vSphere. Se não quiser implementar os componentes da CSI, inclua esta flag.

  Para ver uma lista completa das flags e respetivas descrições, consulte a referência da CLI gcloud

  Monitorize o progresso da criação de clusters

  A saída do comando de criação do cluster é semelhante à seguinte:

  Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
  

  No exemplo de saída, a string operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 é o OPERATION_ID da operação de longa duração. Pode saber o estado da operação com o seguinte comando:

  gcloud container vmware operations describe OPERATION_ID \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION
  

  Para mais informações, consulte o artigo gcloud container vmware operations.

  A criação do cluster de utilizadores demora 15 minutos ou mais. Pode ver o cluster na Google Cloud consola na página Clusters do GKE.

  Crie um node pool

  Depois de criar o cluster, tem de criar, pelo menos, um conjunto de nós antes de implementar cargas de trabalho.

  gcloud container vmware node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME  \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --image-type=IMAGE_TYPE  \
  --boot-disk-size=BOOT_DISK_SIZE \
  --cpus=vCPUS \
  --memory=MEMORY \
  --replicas=NODES \
  --enable-load-balancer
  

  Substitua o seguinte:

• NODE_POOL_NAME: um nome à sua escolha para o node pool. O nome tem de:

  • Conter, no máximo, 40 carateres
  • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
  • Começar com um caráter alfabético
  • Terminar com um caráter alfanumérico

• USER_CLUSTER_NAME: o nome do cluster de utilizadores recém-criado.

• FLEET_HOST_PROJECT_ID: o ID do projeto no qual o cluster está registado.

• REGION: a Google Cloud região que especificou quando criou o cluster.

• IMAGE_TYPE: o tipo de imagem do SO a executar nas VMs no node pool. Defina uma das seguintes opções: ubuntu_containerd ou cos.

• BOOT_DISK_SIZE: O tamanho do disco de arranque em gibibytes (GiB) para cada nó no conjunto. O mínimo é de 40 GiB.

• vCPUs: o número de vCPUs para cada nó no node pool. O mínimo é 4.

• MEMORY: o tamanho da memória em mebibytes (MiB) para cada nó no conjunto. O mínimo é de 8192 MiB por nó de trabalho do cluster de utilizadores e o valor tem de ser um múltiplo de 4.

• NODES: o número de nós no node pool. O mínimo é 3.

• Se estiver a usar o MetalLB como o equilibrador de carga, inclua opcionalmente --enable-load-balancer se quiser permitir que o altifalante do MetalLB seja executado nos nós no conjunto. O MetalLB tem de estar ativado em, pelo menos, um conjunto de nós. Se não incluir esta flag, tem de criar outro conjunto de nós para usar com o MetalLB.

  Para obter informações sobre flags opcionais, consulte o artigo Adicione um conjunto de nós e a referência da CLI gcloud.

Exemplos de comandos gcloud

MetalLB e DHCP

gcloud container vmware clusters create user-cluster-1 \
    --project=example-project-12345 \
    --location=us-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/us-west1/memberships/admin-cluster-1 \
    --version=1.32.300-gke.85 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --enable-dhcp \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;pool=lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --enable-control-plane-v2 \
    --control-plane-vip=203.0.113.1 \
    --ingress-vip=198.51.100.1

MetalLB e IPs estáticos

gcloud container vmware clusters create user-cluster-3 \
    --project=example-project-12345 \
    --location=europe-west1 \
    --admin-cluster-membership=projects/example-project-12345/locations/global/memberships/admin-cluster-1 \
    --version=1.32.300-gke.85 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2' \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm' \
    --dns-servers=203.0.113.1,203.0.113.2  \
    --dns-search-domains=example.com,altostrat.com \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --metal-lb-config-address-pools='pool=lb-pool-1,manual-assign=False,avoid-buggy-ips=True,addresses=192.0.2.0/26;lb-ingress-vip-pool,manual-assign=True,addresses=198.51.100.1/32' \
    --control-plane-vip=172.16.20.61 \
    --ingress-vip=172.16.20.62

Equilíbrio de carga manual e IPs estáticos

gcloud container vmware clusters create user-cluster-4 \
    --project=example-project-12345 \
    --location=asia-east1 \
    --admin-cluster-membership=projects/example-project-12345/locations/asia-east1/memberships/admin-cluster-1 \
    --version=1.32.300-gke.85 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail] \
    --static-ip-config-ip-blocks='gateway=192.0.2.254,netmask=255.255.255.0,ips=192.0.2.10 user-vm-1;192.0.2.11 user-vm-2';ips=192.0.2.12 user-vm-3;192.0.2.13 extra-vm'\
    --dns-servers=203.0.113.1,203.0.113.2  \
    --ntp-servers=203.0.113.3,203.0.113.4 \
    --service-address-cidr-blocks=10.96.0.0/20 \
    --pod-address-cidr-blocks=192.168.0.0/16 \
    --enable-control-plane-v2 \
    --control-plane-ip-block 'gateway=192.0.2.254,netmask=255.255.255.0,ips=198.51.100.1 cp-vm-1;198.51.100.2 cp-vm-2;198.51.100.3 cp-vm-3' \
    --replicas=3 \
    --control-plane-vip=192.0.2.60 \
    --ingress-vip=192.0.2.50 \
    --ingress-http-node-port=30243 \
    --ingress-https-node-port=30879

Terraform

Antes de começar

1. Obtenha o nome e a localização da associação à frota do cluster de administrador:

   gcloud container fleet memberships list \
       --project=FLEET_HOST_PROJECT_ID
   

   Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto no qual o cluster de administrador está registado.

   O resultado é semelhante ao seguinte:

   NAME             EXTERNAL_ID                           LOCATION
   admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
   admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
   admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
   

   A localização especifica onde os serviços Fleet e Connect são executados. Os clusters de administrador criados antes da versão 1.28 são geridos pelos serviços globais da frota e do Connect. Na versão 1.28 e posterior, pode especificar global ou uma Google Cloud região quando cria o cluster.

2. Obtenha uma lista das versões disponíveis:

   gcloud container vmware clusters query-version-config \
       --admin-cluster-membership=ADMIN_CLUSTER_NAME \
       --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
       --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
       --location=REGION
   

   Substitua o seguinte:

   • ADMIN_CLUSTER_NAME: o nome do cluster de administrador.

   • FLEET_HOST_PROJECT_ID: o ID do projeto no qual o cluster de administrador está registado.

   • ADMIN_CLUSTER_REGION: a região de associação da frota do cluster de administrador. Esta opção é global ou de uma Google Cloud região. Use a localização do cluster de administrador a partir do resultado de gcloud container fleet memberships list.

   • REGION: A Google Cloud região que vai usar quando criar o cluster. Esta é a região na qual a API GKE On-Prem e os serviços Fleet e Connect são executados. Especifique us-west1 ou outra região suportada.

   O resultado do comando é semelhante ao seguinte:

   versions:
   - isInstalled: true
     version: 1.14.3-gke.25
   - version: 1.14.4-gke.54
   - version: 1.15.0-gke.581
   

   O comando também produz uma explicação das versões que pode usar para a criação ou a atualização do cluster de utilizadores. As versões permitidas são anotadas com isInstalled: true, o que significa que o cluster de administrador tem os componentes específicos da versão de que precisa para gerir clusters de utilizadores dessa versão. Se quiser usar uma versão instalada no cluster de administrador, avance para a secção Exemplo para criar o cluster de utilizador.

Instale uma versão diferente

Um cluster de administrador pode gerir clusters de utilizadores em diferentes versões. O resultado do comando query-version-config apresenta outras versões que pode usar quando cria o cluster. Se quiser criar um cluster de utilizadores que seja uma versão diferente do cluster de administrador, tem de transferir e implementar os componentes de que o cluster de administrador precisa para gerir clusters de utilizadores dessa versão, da seguinte forma:

gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION

Substitua VERSION por uma das versões indicadas no resultado do comando query-version-config.

O comando transfere a versão dos componentes que especificar em --required-platform-version para o cluster de administrador e, em seguida, implementa os componentes. Já pode criar um cluster de utilizadores com a versão especificada.

Se executar novamente o comando gcloud container vmware clusters query-version-config, a versão especificada é anotada com isInstalled: true.

Exemplo

Pode usar o seguinte exemplo de configuração básica para criar um cluster de utilizadores com o balanceador de carga MetalLB incluído e um conjunto de nós.

Para mais informações e outros exemplos, consulte a google_gkeonprem_vmware_cluster documentação de referência.

Defina variáveis em terraform.tfvars

O exemplo fornece um ficheiro de variáveis de exemplo para transmitir a main.tf, que mostra como configurar o balanceador de carga MetalLB incluído e permitir que os nós do cluster obtenham os respetivos endereços IP a partir de um servidor DHCP fornecido por si.

1. Clone o repositório anthos-samples e mude para o diretório onde se encontra o exemplo do Terraform:

   git clone https://github.com/GoogleCloudPlatform/anthos-samples
   cd anthos-samples/anthos-onprem-terraform/avmw_user_cluster_metallb
   

2. Crie uma cópia do ficheiro terraform.tfvars.sample:

   cp terraform.tfvars.sample terraform.tfvars
   

3. Modifique os valores dos parâmetros em terraform.tfvars.

   project_id                  = "FLEET_HOST_PROJECT_ID"
   region                      = "REGION"
   admin_cluster_name          = "ADMIN_CLUSTER_NAME"
   on_prem_version             = "VERSION"
   admin_user_emails           = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
   cluster_name                = "avmw-user-cluster-metallb"
   control_plane_node_cpus     = 4
   control_plane_node_memory   = 8192
   control_plane_node_replicas = 3
   control_plane_vip           = "CONTROL_PLANE_VIP"
   ingress_vip                 = "INGRESS_VIP"
   lb_address_pools            = [
       { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
   ]
   

   A lista seguinte descreve as variáveis:

   • project_id: o ID do projeto no qual quer criar o cluster. O projeto especificado também é usado como o projeto anfitrião da frota. Este tem de ser o mesmo projeto no qual o cluster de administrador está registado. Depois de o cluster de utilizadores ser criado, é registado automaticamente na frota do projeto selecionado. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.

   • region: a região na qual a API GKE On-Prem (gkeonprem.googleapis.com), o serviço Fleet (gkehub.googleapis.com) e o serviço Connect (gkeconnect.googleapis.com) são executados. Google Cloud Especifique us-west1 ou outra região suportada.

   • admin_cluster_name: o nome do cluster de administrador que gere o cluster de utilizadores. O exemplo pressupõe que o cluster de administrador usa global como a região. Se tiver um cluster de administração regional:

     1. Abra main.tf num editor de texto.
     2. Pesquise admin_cluster_membership, que tem o seguinte aspeto:

     admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

     1. Altere global para a região que o cluster de administrador usa e guarde o ficheiro.

   • on_prem_version: a versão do Google Distributed Cloud para o cluster de utilizadores.

   • admin_user_emails: uma lista de endereços de email dos utilizadores aos quais vão ser concedidos privilégios administrativos no cluster. Certifique-se de que adiciona o seu endereço de email se pretender administrar o cluster.

     Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para conceder aos utilizadores administradores a função do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.clusterrole/cluster-admin Isto também permite que os utilizadores iniciem sessão na consola através da respetiva identidade Google.

   • cluster_name: um nome à sua escolha para o cluster de utilizadores. Não é possível alterar o nome após a criação do cluster. O nome tem de:

     • Conter, no máximo, 40 carateres
     • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
     • Começar com um caráter alfabético
     • Terminar com um caráter alfanumérico

   • control_plane_node_cpus: o número de vCPUs para cada nó do plano de controlo do cluster de utilizadores. O mínimo é de 4 vCPUs.

   • control_plane_node_memory: O tamanho da memória em mebibytes (MiB) para cada plano de controlo do cluster de utilizadores. O valor mínimo é 8192 e tem de ser um múltiplo de 4.

   • control_plane_node_replicas: o número de nós do plano de controlo para o cluster de utilizador. Por exemplo, pode introduzir 1 nó do plano de controlo para um ambiente de desenvolvimento e 3 nós do plano de controlo para ambientes de produção de alta disponibilidade (HA).

   • control_plane_vip: O endereço IP virtual (VIP) que escolheu para configurar no balanceador de carga para o servidor da API Kubernetes do cluster de utilizador.

   • ingress_vip: o endereço IP que escolheu para configurar no balanceador de carga para o proxy de entrada.

   • lb_address_pools: uma lista de mapas que definem os conjuntos de endereços a serem usados pelo equilibrador de carga do MetalLB. O VIP de entrada tem de estar num destes conjuntos. Especifique o seguinte:

     • name: um nome para o conjunto.
     • addresses: um intervalo de endereços na notação CIDR ou no formato de intervalo com hífen. Para especificar um único endereço IP num conjunto (como para o VIP de entrada), use /32 na notação CIDR, por exemplo: 192.0.2.1/32.

     Substitua os exemplos de endereços IP pelos seus valores e adicione conjuntos de endereços adicionais, se necessário.

4. Guarde as alterações em terraform.tfvars. Se não quiser fazer alterações opcionais a main.tf, avance para a secção seguinte, Crie o cluster e um conjunto de nós.

Configure o Controlplane V2

Na versão 1.30 e superior, tem de ativar o Controlplane V2. O ficheiro main.tf no exemplo não ativa o Controlplane V2. Tem de alterar main.tf para ativar o Controlplane V2 e adicionar os endereços IP do gateway, da máscara de rede e dos nós do plano de controlo. Antes de fazer alterações, faça uma cópia de segurança de main.tf:

  cp main.tf main.tf.bak
  

Para configurar o Controlplane V2, faça as seguintes alterações a main.tf:

1. Adicione a seguinte linha ao bloco resource:

     enable_control_plane_v2 = "true"
   

2. Adicione um mapa control_plane_v2_config ao bloco network_config, por exemplo:

     control_plane_v2_config {
       control_plane_ip_block {
         netmask = "255.255.252.0"
         gateway = "10.250.71.254"
         ips {
           ip = "10.250.68.54"
           hostname = "cpv2-vm1"
         }
         ips {
           ip = "10.250.68.128"
           hostname = "cpv2-vm2"
         }
         ips {
           ip = "10.250.71.50"
           hostname = "cpv2-vm3"
         }
       }
     }
   

3. Substitua os valores de netmask e gateway por endereços IP da sua rede. Substitua ip e hostname pelos endereços IP dos nós do plano de controlo.

Opcional: ative o cluster avançado

Por predefinição, na versão 1.32 e superior, os clusters de utilizadores criados com o Terraform não têm o cluster avançado ativado. Se quiser ativar o cluster avançado, adicione o seguinte campo de nível superior a main.tf:

enable_advanced_cluster = true

Certifique-se de que revê as diferenças quando executa clusters avançados antes de ativar o cluster avançado.

Opcional: modo de endereçamento IP do nó de trabalho

Esta secção explica algumas alterações de configuração opcionais que pode fazer no main.tf. Antes de fazer alterações, faça uma cópia de segurança do seguinte: main.tf

cp main.tf main.tf.bak

Por predefinição, o main.tf configura o cluster para usar um servidor DHCP que fornece para atribuir endereços IP aos nós de trabalho do cluster. O DHCP é configurado incluindo o mapa dhcp_config no bloco network_config. Se quiser fornecer endereços IP estáticos para os nós de trabalho, faça as seguintes alterações a main.tf:

1. Substitua o bloco network_config e inclua um bloco static_ip_config. Por exemplo:

     network_config {
       service_address_cidr_blocks = ["10.96.0.0/12"]
       pod_address_cidr_blocks = ["192.168.0.0/16"]
       host_config {
         dns_servers = ["10.254.41.1"]
         ntp_servers = ["216.239.35.8"]
       }
       static_ip_config {
         ip_blocks {
           netmask = "255.255.252.0"
           gateway = "10.251.31.254"
           ips {
             ip = "10.251.30.153"
             hostname = "vm-1"
           }
           ips {
             ip = "10.251.31.206"
             hostname = "vm-2"
           }
           ips {
             ip = "10.251.31.193"
             hostname = "vm-3"
           }
           ips {
             ip = "10.251.30.230"
             hostname = "vm-4"
           }
         }
       }
     }
   

2. Substitua o seguinte pelos seus valores:

   • service_address_cidr_blocks: um intervalo de endereços IP, no formato CIDR, a usar para serviços no seu cluster. Tem de ser, pelo menos, um intervalo /24.

   • pod_address_cidr_blocks: um intervalo de endereços IP, no formato CIDR, a usar para pods no seu cluster. Tem de ser, pelo menos, um intervalo /18.

   • dns_servers: Uma lista dos endereços IP dos servidores DNS para as VMs.

   • ntp_servers: Uma lista dos endereços IP dos servidores de tempo que as VMs vão usar.

   • No bloco static_ip_config, substitua os valores de netmask e gateway pelos endereços da sua rede. Substituaip e hostname pelos endereços IP e pelos nomes de anfitrião dos nós de trabalho.

Crie o cluster e um node pool

1. Inicialize e crie o plano do Terraform:

   terraform init
   

   O Terraform instala todas as bibliotecas necessárias, como o Google Cloud fornecedor.

2. Reveja a configuração e faça alterações, se necessário:

   terraform plan
   

3. Aplique o plano do Terraform para criar o cluster de utilizadores:

   terraform apply
   

   A criação do cluster de utilizadores demora cerca de 15 minutos ou mais e a criação do node pool demora mais 15 minutos. Pode ver o cluster na Google Cloud consola na página Clusters do GKE.

Opcional: execute ferramentas de linha de comandos antes da criação de recursos

Se necessário, pode executar ferramentas de linha de comandos, como a CLI gcloud e o gkectl, para realizar tarefas de configuração antes da criação de recursos. Define as linhas de comando a executar no ficheiro de configuração do Terraform através do aprovisionador local-exec, que lhe permite reutilizar as variáveis do Terraform definidas.

O exemplo seguinte mostra como modificar main.tf para executar o comando gkectl prepare antes da criação do cluster:

resource "null_resource" "gkectl_prepare" {
  provisioner "local-exec" {
    command = "gkectl prepare --kubeconfig=${var.kubeconfig} --cluster-name=${var.cluster_name} --vcenter-username=${var.vcenter_username} --vcenter-password=${var.vcenter_password} --vcenter-address=${var.vcenter_address} --datacenter=${var.datacenter} --datastore=${var.datastore} --network=${var.network} --os-image=${var.os_image} --service-account-key-file=${var.service_account_key_file} --location=${var.location}"
    working_dir = path.module  # Important: Set working directory
    environment = {
        # Optional: set environment variables if needed.
        # Example: GOOGLE_APPLICATION_CREDENTIALS = "/path/to/your/credentials.json"
    }
  }
}

resource "google_gkeonprem_vmware_cluster" "cluster" {
  # ... your cluster configuration ...
  # Ensure this depends on the null_resource
  depends_on = [null_resource.gkectl_prepare]

  # ... rest of your cluster configuration ...
  location = var.location
  name = var.cluster_name
  # ... other required fields ...
}

Resolução de problemas

Consulte o artigo Resolução de problemas de criação e atualização de clusters.

O que se segue?

• Ligue-se ao seu cluster a partir da Google Cloud consola.
• Implemente uma aplicação.