Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Criar um cluster de usuário

No Google Distributed Cloud, as cargas de trabalho são executadas em um ou mais clusters de usuário. Neste documento, você aprende a criar um cluster de usuário. Esta página é destinada a administradores, arquitetos e operadores que configuram, monitoram e gerenciam a infraestrutura de tecnologia. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Há várias ferramentas que você pode usar para criar um cluster de usuários:

gkectl
Console do Google Cloud
Google Cloud CLI
Terraform

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

Para orientações sobre qual ferramenta usar, consulte Escolher uma ferramenta para gerenciar o ciclo de vida do cluster.

Antes de começar

Se ainda não tiver feito isso, configure os recursos do Google Cloud conforme descrito nestes documentos:
Ao configurar o projeto do host da frota, considere a ferramenta escolhida. Se você escolheu um dos clientes da API GKE On-Prem, há outras APIs que precisam ser ativadas. Para conferir a lista de APIs, consulte Ativar APIs no projeto do host da frota.
Antes de criar um cluster de usuário, é necessário um cluster de administrador para gerenciá-lo. Se ainda não tiver feito isso, crie uma estação de trabalho de administrador e um cluster de administrador.
Determine a versão do cluster de usuário que você quer instalar. Ao criar um cluster de usuário, normalmente você instala a versão que corresponde à versão do cluster de administrador. Mas é possível instalar uma versão de patch posterior. Na versão 1.28 e mais recentes, os clusters de usuário podem ter até duas versões secundárias mais recentes que o cluster de administrador.
Recomendamos que você ative o Controlplane V2. Quando o Controlplane V2 está ativado, o plano de controle de um cluster de usuário é executado em um ou mais nós no próprio cluster. Para instalar a versão 1.30 ou mais recente, o Controlplane V2 é obrigatório. A alternativa é criar um cluster de usuário que use o kubeception. No caso do kubeception, o plano de controle do cluster de usuário é executado em um ou mais nós no cluster de administrador.
Consulte o documento de planejamento de endereços IP e verifique se você tem endereços IP suficientes disponíveis.
Consulte a visão geral do balanceamento de carga e reveja sua decisão sobre o tipo de balanceador de carga que você quer usar. É possível usar o balanceador de carga MetalLB empacotado ou configurar manualmente um balanceador de carga de sua escolha. Para balanceamento de carga manual, configure o balanceador de carga antes de criar o cluster de usuário.
Pense em quantos pools de nós você precisa e em qual sistema operacional você quer executar em cada um deles.
Considere se você quer usar clusters do vSphere para os clusters de administrador e de usuário e se quer usar data centers separados. Pense também se você quer usar instâncias separadas do vCenter Server.
Na versão 1.29 e mais recentes, as verificações de simulação do lado do servidor são ativadas por padrão. Verificações de simulação do lado do servidor não exigem regras de firewall adicionais. Em Regras de firewall para clusters de administrador, pesquise "Verificações de simulação" e garantir que todas as regras de firewall necessárias sejam configurados.

Com as verificações de simulação do lado do servidor, ao criar um cluster de usuário usando gkectl, as verificações de simulação executadas no cluster de administrador em vez de localmente na estação de trabalho do administrador. As verificações de simulação do lado do servidor são executadas no console do Google Cloud, a CLI do Google Cloud ou o Terraform para criar um cluster de usuário.

Criar um cluster de usuário

gkectl

Visão geral do procedimento

Estas são as principais etapas envolvidas no uso de gkectl para criar um cluster de usuários:

Conectar-se à estação de trabalho do administrador

A estação de trabalho de administrador é uma máquina que tem as ferramentas necessárias para criar um cluster de usuário.
Preencher os arquivos de configuração

Para especificar os detalhes do novo cluster, preencha um arquivo de configuração de cluster de usuário, um arquivo de configuração de credenciais e possivelmente um arquivo de bloco de IP.
(Opcional) Importe imagens do SO para o vSphere e envie imagens de contêiner para o registro particular, se aplicável.

Executar gkectl prepare.
Criar um cluster de usuário

Execute gkectl create cluster para criar um cluster conforme especificado no arquivo de configuração.
Verificar se o cluster de usuário está em execução

Use o kubectl para ver os nós do cluster.

No final deste procedimento, você terá um cluster de usuários em execução para implantar as cargas de trabalho.

Se você usa o VPC Service Controls, talvez apareçam erros ao executar alguns comandos gkectl, como "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Para evitar esses erros, adicione o parâmetro --skip-validation-gcp aos comandos.

Preencher os arquivos de configuração

Siga estas etapas na estação de trabalho do administrador.

Quando gkeadm criou a estação de trabalho do administrador, foi gerado um arquivo de configuração chamado user-cluster.yaml. Esse arquivo de configuração serve para criar o cluster de usuário.

Para se familiarizar com o arquivo de configuração, leia o documento arquivo de configuração do cluster de usuário. É recomendável manter esse documento aberto em uma guia ou janela separada para fazer referência a ele ao concluir as etapas a seguir.

`name`

Defina o campo name como um nome de sua escolha para o cluster de usuário.

`gkeOnPremVersion`

Este campo já foi preenchido para você. Ele especifica a versão do Google Distributed Cloud. Por exemplo, 1.30.0-gke.1930

`enableControlplaneV2`

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

Quando o Controlplane V2 está ativado, o plano de controle do cluster de usuário é executado nos nós no próprio cluster de usuário. Recomendamos que você ative o Controlplane V2.

kubeception

Se você definir esse campo como false, o cluster vai usar o kubecetption. Com o kubeception, o plano de controle do cluster de usuário é executado em nós no cluster de administrador.

Para um cluster kubeception:

Defina enableControlplaneV2 como false.
Não preencha a seção controlPlaneIPBlock.
Especifique endereços IP para os nós do plano de controle do cluster de usuário no arquivo de bloco de IP do cluster de administrador.

`enableDataplaneV2`

Defina enableDataplaneV2 como true.

`vCenter`

Os valores definidos na seção vCenter do arquivo de configuração do cluster de administrador são globais. Ou seja, elas se aplicam ao cluster de administrador e aos clusters de usuário associados.

Para cada cluster de usuário criado, você tem a opção de modificar alguns dos valores globais de vCenter.

Para substituir qualquer um dos valores vCenter globais, preencha os campos relevantes na seção vCenter do seu arquivo de configuração do cluster de usuário.

Talvez você queira usar clusters do vSphere separados para o cluster de administrador e os clusters de usuário. Em vez disso, use data centers separados para o cluster de administrador e os clusters de usuário.

Como usar um data center e um cluster do vSphere

A opção padrão é usar um data center e um cluster do vSphere para o cluster de administrador e o cluster de usuário. Para essa opção, não defina valores vCenter no arquivo de configuração do cluster de usuário. Os valores vCenter serão herdados do cluster de administrador.

Como usar clusters do vSphere separados

Se você quiser criar um cluster de usuário que esteja no próprio cluster do vSphere, especifique um valor para vCenter.cluster no arquivo de configuração do cluster de usuário.

Se o cluster de administrador e o cluster de usuário estiverem em clusters separados do vSphere, eles podem estar no mesmo data center ou em data centers diferentes.

Como usar data centers separados do vSphere

Os clusters de usuário e de administrador podem estar em diferentes data centers. Nesse caso, eles também estão em clusters separados do vSphere.

Se você especificar vCenter.datacenter no arquivo de configuração do cluster de usuário, também será necessário especificar:

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

Como usar contas do vCenter separadas

Um cluster de usuário pode usar uma conta do vCenter diferente, com vCenter.credentials diferentes, do cluster de administrador. A conta do vCenter do cluster de administrador precisa acessar o data center do cluster de administrador, enquanto a conta do vCenter do cluster de usuário só precisa de acesso ao data center do cluster de usuário.

Como usar instâncias separadas do vCenter Server

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

Por exemplo, em um local de borda, convém ter uma máquina física executando o vCenter Server e uma ou mais máquinas físicas executando o ESXi. Em seguida, use a instância local do vCenter Server para criar uma hierarquia de objetos do vSphere, incluindo data centers, clusters, pools de recursos, repositórios de dados e pastas.

Preencha a seção vCenter do arquivo de configuração do cluster de usuário Especificamente, especifique um valor para vCenter.address diferente do endereço do vCenter Server especificado no arquivo 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 você quer que os nós de trabalho recebam os endereços IP deles. As opções são:

De um servidor DHCP configurado com antecedência. Defina network.ipMode.type como "dhcp".
A partir de uma lista de endereços IP estáticos fornecidos. Defina network.ipMode.type como "static" e crie um arquivo de bloco de IPs que forneça os endereços IP estáticos. Para ver um exemplo de arquivo de bloco de IP, consulte Exemplo de arquivos de configuração preenchidos.

Se você 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 controle do cluster de usuário precisam receber os endereços IP de uma lista de endereços estáticos fornecidos por você, mesmo se os nós de trabalho receberem os endereços de um servidor DHCP. Para especificar endereços IP estáticos para os nós do plano de controle, preencha a seção network.controlPlaneIPBlock. Se você quiser um cluster de usuário de alta disponibilidade (HA, na sigla em inglês), especifique três endereços IP. Caso contrário, especifique um endereço IP.

Para especificar os servidores DNS e NTP, preencha a seção hostConfig. Esses servidores DNS e NTP são para os nós do plano de controle. Se você estiver usando endereços IP estáticos para os nós de trabalho, esses servidores DNS e NTP também serão para os nós de trabalho.

O network.podCIDR e o network.serviceCIDR têm valores pré-preenchidos que não podem ser alterados, a menos que entrem em conflito com endereços que já estão em uso na sua rede. O Kubernetes usa esses intervalos para atribuir endereços IP a pods e serviços no cluster.

Independentemente de você depender de um servidor DHCP ou especificar uma lista de endereços IP estáticos, é necessário ter endereços IP suficientes disponíveis para o cluster de usuário. Para uma explicação de quantos endereços IP você precisa, consulte Planejar seus endereços IP.

`loadBalancer`

Reserve um VIP para o servidor da API Kubernetes do seu cluster de usuários. Reserve outro VIP para o serviço de entrada do seu cluster de usuários. Forneça seus VIPs como valores para loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.ingressVIP.

Decida qual tipo de balanceamento de carga você quer usar. As opções são:

Balanceamento de carga em pacote MetalLB. Defina loadBalancer.kind como "MetalLB". Preencha também a seção loadBalancer.metalLB.addressPools e defina enableLoadBalancer como true para pelo menos um dos pools de nós. Para mais informações, consulte Balanceamento de carga em pacote com o MetalLB.
Balanceamento de carga manual. Defina loadBalancer.kind como "ManualLB" e preencha a seção manualLB. Para mais informações, consulte Balanceamento de carga manual.

Para mais informações, consulte Visão geral do balanceamento de carga.

`advancedNetworking`

Se você planeja criar um gateway NAT de saída, defina advancedNetworking como true.

`multipleNetworkInterfaces`

Decida se quer configurar várias interfaces de rede para pods e defina multipleNetworkInterfaces conforme necessário.

`storage`

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

`masterNode`

Na seção masterNode, especifique quantos nós do plano de controle você quer para o cluster de usuário: um ou três. Também é possível especificar um repositório de dados para os nós do plano de controle e se você quer ativar o redimensionamento automático dos nós do plano de controle.

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

`nodePools`

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

Preencha a seção nodePools para especificar pelo menos um pool de nós.

Para mais informações, consulte Pools de nós e Como criar e gerenciar 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, na sigla em inglês) para os nós de trabalho, fazendo com que eles sejam espalhados por no mínimo três hosts físicos no data center.

`stackdriver`

Se você quiser ativar o Cloud Logging e o Cloud Monitoring para o cluster, preencha a seção stackdriver.

Esta seção é obrigatória por padrão. Ou seja, se você não preencher essa seção, inclua a sinalização --skip-validation-stackdriver ao executar gkectl create cluster.

Observe os seguintes requisitos para novos clusters:

O ID em stackdriver.projectID precisa ser o mesmo que o ID em gkeConnect.projectID e cloudAuditLogging.projectID.
A região do Google Cloud definida em stackdriver.clusterLocation precisa ser igual à região definida em cloudAuditLogging.clusterLocation e gkeConnect.location (se o campo estiver incluído no arquivo de configuração). Além disso, se gkeOnPremAPI.enabled for true, a mesma região precisará ser definida em gkeOnPremAPI.location.

Se os IDs do projeto e as regiões não forem iguais, a criação do cluster vai falhar.

`gkeConnect`

Seu cluster de usuário precisa ser registrado em uma frota do Google Cloud.

Preencha a seção gkeConnect para especificar um projeto host de frota e uma conta de serviço associada. O ID em gkeConnect.projectID precisa ser igual ao ID definido em stackdriver.projectID e cloudAuditLogging.projectID. Se os IDs do projeto não forem iguais, a criação do cluster falhará.

Na versão 1.28 e mais recentes, é possível especificar uma região em que os serviços de frota e Connect são executados em gkeConnect.location. Se você não incluir esse campo, o cluster vai usar as instâncias globais desses serviços.

Se você incluir gkeConnect.location no arquivo de configuração, a região especificada precisará ser a mesma configurada em cloudAuditLogging.clusterLocation, stackdriver.clusterLocation e gkeOnPremAPI.location. Se as regiões não forem iguais, a criação do cluster falhará.

`gkeOnPremAPI`

Na versão 1.16 e mais recentes, se a API GKE On-Prem estiver ativada no projeto do Google Cloud, todos os clusters no projeto serão automaticamente registrados na API GKE On-Prem na região configurada em stackdriver.clusterLocation. A região gkeOnPremAPI.location precisa ser a mesma especificada em cloudAuditLogging.clusterLocation, gkeConnect.location (se o campo estiver incluído no arquivo de configuração) e stackdriver.clusterLocation.

Se você quiser registrar todos os clusters do projeto na API GKE On-Prem, siga as etapas em Antes de começar para ativar e usar a API GKE On-Prem no projeto.
Se você não quiser registrar o cluster na API GKE On-Prem, inclua esta seção e defina gkeOnPremAPI.enabled como false. Se você não quiser registrar clusters no projeto, desative gkeonprem.googleapis.com (o nome do serviço da API GKE On-Prem) no projeto. Para instruções, consulte Como desativar serviços.

`usageMetering`

Se você quiser ativar a medição de uso do cluster, preencha a seção usageMetering.

`cloudAuditLogging`

Se você quiser integrar os registros de auditoria do servidor da API Kubernetes do cluster com os registros de auditoria do Cloud, preencha a seção cloudAuditLogging.

Observe os seguintes requisitos para novos clusters:

O ID em cloudAuditLogging.projectID precisa ser o mesmo que o ID em gkeConnect.projectID e stackdriver.projectID.
A região em cloudAuditLogging.clusterLocation precisa ser a mesma definida em gkeConnect.location (se o campo estiver incluído no arquivo de configuração) e stackdriver.clusterLocation. Além disso, se gkeOnPremAPI.enabled for true, a mesma região precisará ser definida em gkeOnPremAPI.location.

Se os IDs do projeto e as regiões não forem iguais, a criação do cluster vai falhar.

Exemplo de arquivos de configuração preenchidos

Confira um exemplo de um arquivo de bloco de IP e um arquivo de configuração de cluster de usuário:

usuario-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.30.0-gke.1930
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

Estes são os pontos importantes que você precisa entender no exemplo anterior:

Os endereços IP estáticos dos nós de trabalho são especificados em um arquivo de bloco de IP. O arquivo de bloco de IP tem quatro endereços, mesmo que haja apenas três nós de trabalho. O endereço IP extra é necessário durante o upgrade, a atualização e o reparo automático do cluster.
Os servidores DNS e NTP são especificados na seção hostConfig. Neste exemplo, esses servidores DNS e NTP são destinados aos nós do plano de controle e dos nós de trabalho. Isso ocorre porque os nós de trabalho têm endereços IP estáticos. Se os nós de trabalho recebessem os endereços IP de um servidor DHCP, esses servidores DNS e NTP seriam apenas para os nós do plano de controle.
Os endereços IP estáticos dos três nós do plano de controle são especificados na seção network.controlPlaneIPBlock do arquivo de configuração do cluster de usuário. Não é necessário ter um endereço IP extra neste bloco.
O Controlplane V2 está ativado.
O campo masterNode.replicas está definido como 3, então o cluster terá um plano de controle de alta disponibilidade.
O VIP do plano de controle e o VIP de entrada estão na mesma VLAN dos nós de trabalho e do plano de controle.
Os VIPs definidos para os serviços do tipo LoadBalancer são especificados na seção loadBalancer.metalLB.addressPools do arquivo de configuração do cluster de usuário. Esses VIPs estão na mesma VLAN que os nós de trabalho e os nós do plano de controle. O conjunto de VIPs especificados nesta seção precisa incluir o VIP de entrada e não deve incluir o VIP do plano de controle.
O arquivo de configuração do cluster de usuário não inclui uma seção vCenter. Portanto, o cluster de usuário usa os mesmos recursos do vSphere que o cluster de administrador.

Validar o arquivo de configuração

Depois de preencher o arquivo de configuração do cluster de usuário, execute gkectl check-config para verificar se o arquivo é válido:

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

Substitua:

ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig para o cluster de administrador.
USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

Se o comando retornar mensagens, corrija os problemas e valide o arquivo novamente.

Se quiser pular as validações mais demoradas, transmita a sinalização --fast. Para pular validações individuais, use as sinalizações --skip-validation-xxx. Para saber mais sobre o comando check-config, consulte Como executar verificações de simulação.

3. (Opcional) Importe imagens do SO para o vSphere e envie imagens de contêiner para um registro particular

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

O cluster de usuário está em um data center do vSphere diferente do cluster de administrador.
O cluster de usuário tem um servidor vCenter diferente do cluster de administrador.
O cluster de usuário usa um registro de contêiner particular diferente do registro particular usado pelo cluster de administrador.

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

Substitua:

ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;
BUNDLE: o caminho do arquivo do pacote. Esse arquivo está na estação de trabalho do administrador em /var/lib/gke/bundles/. Por exemplo:
```
/var/lib/gke/bundles/gke-onprem-vsphere-1.30.0-gke.1930-full.tgz
```
USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

4. Criar um cluster de usuário

Crie um cluster de usuário:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Localizar o arquivo kubeconfig do cluster de usuário

O comando gkectl create cluster cria um arquivo kubeconfig chamado USER_CLUSTER_NAME-kubeconfig no diretório atual. Você precisará desse arquivo kubeconfig mais tarde para interagir com seu cluster de usuários.

O arquivo kubeconfig contém o nome do cluster de usuário. Para acessar o nome do cluster, execute o seguinte:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

A saída mostra o nome do cluster. Por exemplo:

NAME
my-user-cluster

Se preferir, é possível alterar o nome e o local do arquivo kubeconfig.

5. Verificar se o cluster de usuário está em execução

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

A saída mostra os nós do cluster de usuário. 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

Console

Começar

No console do Google Cloud, acesse a página Criar um cluster do Google Distributed Cloud.

Acesse Criar um cluster do Google Distributed Cloud
Selecione o projeto do Google Cloud em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado.

Noções básicas sobre clusters

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

Insira um nome para o cluster de usuário.
Em Cluster de administração, selecione o cluster de administrador na lista. Se você não tiver especificado um nome para o cluster de administrador quando o criou, o nome será gerado no formato gke-admin-[HASH]. Se você não reconhece o nome do cluster de administrador, execute o seguinte comando na estação de trabalho do administrador:
```
KUBECONFIG=ADMIN_CLUSTER_KUBECONFIG
kubectl get OnPremAdminCluster -n kube-system -o=jsonpath='{.items[0].metadata.name}'
```
Se o cluster de administrador que você quer usar não for exibido, consulte a seção de solução de problemas O cluster de administrador não é exibido naNoções básicas sobre clusters Lista suspensa de dados.
No campo Local da API GCP, selecione a região do Google Cloud na lista. Essa configuração especifica a região em que as seguintes APIs e serviços são executadas:
- API GKE On-Prem (gkeonprem.googleapis.com)
- Serviço do Fleet (gkehub.googleapis.com)
- Serviço do Connect (gkeconnect.googleapis.com)
Essa configuração também controla a região em que os seguintes itens são armazenados:
- Os metadados do cluster de usuário de que a API GKE On-Prem precisa para gerenciar o ciclo de vida do cluster
- Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
- O registro de auditoria do administrador criado pelos registros de auditoria do Cloud
O nome, o projeto e o local do cluster identificam exclusivamente o cluster no Google Cloud.
Selecione a versão do Google Distributed Cloud para o cluster de usuário.
Como criador do cluster, você recebe privilégios de administrador. Se quiser, insira o endereço de e-mail de outro usuário que administrará o cluster no campo Usuário administrador do cluster na seção Autorização.

Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces.

Observação: além das políticas do RBAC do Kubernetes, você precisa conceder alguns papéis do Identity and Access Management (IAM) aos usuários que não são proprietários de projetos. Para detalhes sobre como conceder os papéis do IAM, consulte Conceder os papéis necessários.
Clique em Próxima para acessar a seção Plano de controle.

Plano de controle

Todos os campos na seção Plano de controle são definidos com valores padrão. Revise os padrões e, se desejar, altere-os.

No campo vCPUs do nó do plano de controle, insira o número de vCPUs (mínimo de 4) para cada nó do plano de controle do cluster de usuário.
No campo Memória do nó do plano de controle, insira o tamanho da memória em MiB (mínimo de 8.192 e precisa ser um múltiplo de 4) para cada plano de controle do cluster de usuário.
Em Nós do plano de controle, selecione o número de nós do plano de controle para o cluster de usuário. Por exemplo, é possível selecionar um nó do plano de controle para um ambiente de desenvolvimento e três nós do plano para alta disponibilidade (HA, na sigla em inglês).
Opcionalmente, selecione Redimensionamento automático de nós. 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 controle para o cluster de usuário são redimensionados de acordo com o número de nós de trabalho no cluster de usuário. Portanto, à medida que você adiciona mais nós de trabalho ao cluster de usuário, os nós do plano de controle aumentam de tamanho.
Opcionalmente, selecione Ativar plano de controle v2. Ativar o plano de controle V2 significa que o plano de controle para um cluster de usuário é executado em um ou mais nós no próprio cluster de usuário, em vez de no cluster de administrador (chamado de kubeception).

Quando você seleciona Ativar plano de controle v2, a seção IPs do nó do plano de controle é exibida. Insira o endereço IP do gateway, a máscara de sub-rede e os endereços IP dos nós do plano de controle.

Quando o Controlplane V2 está ativado, os campos vCPU e memória se aplicam aos nós do plano de controle no cluster de usuário. O número de nós é determinado pelo número de endereços IP que você insere. Quando o Controlplane V2 não está ativado, os campos de vCPU, memória e número de nós do plano de controle se aplicam aos nós no cluster de administrador. Reserve endereços IP suficientes para o cluster de administrador.
Clique em Continuar para acessar a seção Rede.

Rede

Nesta seção, você especificará os endereços IP para os nós, pods e serviços do cluster. Um cluster de usuário precisa ter um endereço IP para cada nó e um endereço IP adicional para um nó temporário, que é necessário durante upgrades de cluster, atualizações e reparo automático. Para mais informações, consulte De quantos endereços IP um cluster de usuário precisa?.

Na seção IPs de nós, selecione o Modo IP do cluster de usuário. Selecione uma destas opções:
- DHCP: escolha DHCP se quiser que os nós do cluster recebam o 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 balanceamento de carga manual.
Se você tiver selecionado DHCP, pule para a próxima etapa para especificar os CIDRs de serviço e pod. Para o modo de IP estático, forneça as informações a seguir:
1. Digite o endereço IP do gateway para o cluster de usuário.
2. Insira a máscara de sub-rede para os nós do cluster de usuário.
3. Na seção Endereços IP, insira os endereços IP e, opcionalmente, os nomes do host dos nós no cluster de usuários. É possível inserir um endereço IP v4 individual (como 192.0.2.1) ou um bloco CIDR de endereços IPv4 (como 192.0.2.0/24).
  - Se você inserir um bloco CIDR, não insira um nome do host.
  - Se você digitar um endereço IP individual, poderá inserir um nome do host. Se você não inserir um nome do host, o Google Distributed Cloud usará o nome da VM do vSphere como o nome do host.
4. Clique em + Adicionar endereço IP conforme necessário para inserir mais endereços IP.
Na seção CIDRs de serviços e pods, o console fornece os seguintes intervalos de endereços para os serviços e pods do Kubernetes:
- CIDR de serviço: 10.96.0.0/20
- CIDR de pods: 192.168.0.0/16
Se você preferir inserir seus próprios intervalos de endereços, consulte Endereços IP para pods e serviços para ver práticas recomendadas.
Se você tiver selecionado Modo de IP estático ou Ativar plano de controle v2, especifique as seguintes informações na seção Configuração do host:
1. Digite os endereços IP dos servidores DNS.
2. Digite os endereços IP dos servidores NTP.
3. Também é possível digitar domínios de pesquisa DNS.
Clique em Próxima para acessar a seção Balanceador de carga.

Balanceador de carga

Escolha o balanceador de carga a ser configurado para o cluster. Consulte a visão geral do balanceador de carga para mais informações.

Selecione o Tipo de balanceador de carga na lista.

Empacotado com MetalLB

Configurar balanceamento de carga em pacote com o MetalLB. Só é possível usar o MetalLB no cluster de usuário se o cluster de administrador estiver usando o SeeSaw ou o MetalLB. Essa opção requer configuração mínima. Executado diretamente nos nós do cluster e não requer VMs extras Para mais informações sobre os benefícios do uso do MetalLB e como ele se compara às outras opções de balanceamento de carga, consulte Balanceamento de carga em pacote com MetalLB.

Na seção Pools de endereços, configure pelo menos um pool de endereços da seguinte maneira:
1. Insira um Nome para o pool de nós.
2. Insira um intervalo de endereços IP que contenha o VIP de entrada em qualquer notação CIDR (por exemplo, 192.0.2.0/26) ou a notação de intervalo (por exemplo, 192.0.2.64-192.0.2.72). Para especificar um único endereço IP em um pool, use /32 na notação CIDR (por exemplo, 192.0.2.1/32).
3. Se os endereços IP dos 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 digite outro endereço. um intervalo
  
  Os endereços IP de cada pool não podem se sobrepor e precisam 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 essa opção se quiser que o controlador do MetalLB atribua automaticamente endereços IP do pool de endereços aos serviços do tipo LoadBalancer.
  - Manual: escolha essa opção se você pretende usar endereços do pool para especificar manualmente os endereços para serviços do tipo LoadBalancer.
5. Clique em Evitar endereços IP com bugs se quiser que o controlador MetalLB não use endereços do pool que terminam em .0 ou .255. Isso evita o problema de dispositivos com bug de consumo que descartam o tráfego enviado para esses endereços IP especiais.
6. Quando terminar, clique em Concluído.
Se necessário, clique em Adicionar pool de endereços.
Na seção IPs virtuais, digite o seguinte:
- Plano de controle VIP: o endereço IP de destino a ser usado para o tráfego enviado ao servidor da API Kubernetes do cluster de usuário. O servidor da API Kubernetes para o cluster de usuário é executado em um nó no cluster de administrador. Esse endereço IP precisa estar no mesmo domínio L2 que os nós do cluster de administrador. Não adicione esse endereço na seção Pools de endereços.
- Ingress VIP: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada. É necessário adicionar isso a um pool de endereços na seção Pools de endereços.
Clique em Continuar.

F5 BIG-IP

Só é possível usar o F5 BIG-IP para o cluster de usuário se o cluster de administrador estiver usando o F5 BIG-IP. Instale e configure o ADC F5 BIG-IP antes de integrá-lo ao Google Distributed Cloud.

O nome de usuário e a senha F5 são herdados do cluster de administrador.

Na seção IPs virtuais, digite o seguinte:
- Plano de controle VIP: o endereço IP de destino a ser usado para o tráfego enviado para o servidor da API Kubernetes.
- Ingress VIP: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada.
No campo Endereço, digite o endereço do balanceador de carga F5 BIG-IP.
No campo Partição, insira o nome de uma partição BIG-IP que você criou para o cluster de usuário.
No campo Nome do pool de sNAT, insira o nome do pool de SNAT, se aplicável.
Clique em Continuar.

Manual

Só é possível usar um balanceador de carga manual para o cluster de usuário se o cluster de administrador usar um balanceador de carga manual. No Google Distributed Cloud, o servidor da API Kubernetes e o proxy de entrada são expostos por um serviço do Kubernetes do tipo LoadBalancer. Escolha seus próprios valores de nodePort no intervalo 30000 - 32767 para esses Serviços. Para o proxy de entrada, escolha um valor de nodePort para tráfego HTTP e HTTPS. Consulte Como ativar o modo de balanceamento de carga manual para mais informações.

Na seção IPs virtuais, digite o seguinte:
- Plano de controle VIP: o endereço IP de destino a ser usado para o tráfego enviado para o servidor da API Kubernetes.
- Ingress VIP: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada.
No campo Porta do nó do plano de controle, insira um valor nodePort para o servidor da API Kubernetes.
No campo Porta do nó HTTP de entrada, insira um valor nodePort para o tráfego HTTP do proxy de entrada.
No campo Porta de nó HTTPS de entrada, insira um valor nodePort para o tráfego HTTPS ao proxy de entrada.
No campo Porta do nó do servidor de conectividade, insira um valor nodePort para o servidor da Konnectivity.
Clique em Continuar.

Recursos

Nesta seção, são exibidos os recursos e as operações ativados no cluster.

Os itens a seguir são ativados automaticamente e não podem ser desativados:
- Cloud Logging de serviços do sistema
- Cloud Monitoring dos serviços do sistema
- O registro de auditoria da atividade do administrador
Os itens a seguir são ativados por padrão, mas você pode desativá-los:
- Ativar o driver CSI do vSphere: também chamado de plug-in do vSphere Container Storage. O driver da Interface de Armazenamento de Contêiner (CSI, na sigla em inglês) é executado em um cluster nativo do Kubernetes implantado no vSphere para provisionar volumes permanentes no armazenamento do vSphere. Para mais informações, consulte Como usar o driver da interface de armazenamento do contêiner do vSphere.
- Ativar grupos de antiafinidade: as regras de antiafinidade do VMware Distribuird Resource Scheduler (DRS) são criadas automaticamente para os nós do cluster de usuário, fazendo com que eles sejam distribuídos por pelo menos três hosts físicos. no seu data center. Verifique se o ambiente vSphere atende aos requisitos.
Observação: se você seguiu Configurar uma infraestrutura mínima, você tem apenas um host ESXi, então não se esqueça de Ativar grupos antiafinidade.
Clique em Próxima para configurar um pool de nós.

Pools de nós

O cluster vai ser criado com pelo menos um pool de nós. Um pool de nós é um modelo para um grupo de nós de trabalho criados nesse cluster. Para mais informações, consulte Como criar e gerenciar pools de nós.

Na seção Detalhes do pool de nós, preencha o seguinte:
1. Insira o Nome do pool de nós ou aceite "default-pool" como o nome.
2. O número de vCPUs de cada nó no pool (mínimo de 4 por worker do cluster de usuário)
3. Insira o tamanho da memória em mebibytes (MiB) para cada nó no pool (mínimo de 8.192 MiB por nó de trabalho do cluster de usuário, e precisa ser um múltiplo de 4).
4. No campo Nodes, insira o número de nós no pool (mínimo de três). Se você tiver inserido endereços IP estáticos para os IPs do nó na seção Rede, verifique se você inseriu endereços IP suficientes para acomodar esses nós do cluster de usuário.
5. Selecione o tipo de imagem do SO: Ubuntu, Ubuntu Containerd ou COS.
6. Digite Tamanho do disco de inicialização em gibibytes (GiB) (mínimo de 40 GiB).
7. Se você estiver usando MetalLB como balanceador de carga, ele precisará ser ativado em pelo menos um pool de nós. Deixe a opção Usar este pool de nós para balanceamento de carga MetalLB selecionada ou adicione outro pool de nós para usar no MetalLB.
Na seção Metadados do pool de nós (opcional), se você quiser adicionar rótulos e taints do Kubernetes, faça o seguinte:
1. Clique em + Adicionar rótulos do Kubernetes. Insira a Chave e o Valor do rótulo. Repita quantas vezes forem necessárias.
2. Clique em + Adicionar taint. Insira Key, Value e Effect para o taint. Repita quantas vezes forem necessárias.
Clique em Verificar e concluir para criar o cluster de usuário. Leva 15 minutos ou mais para criar o cluster de usuário. O console exibe mensagens de status durante a verificação das configurações e a criação do cluster no data center.

Se for encontrado um erro ao verificar as configurações, o console exibirá uma mensagem de erro que deve estar clara o suficiente para que você corrija o problema de configuração e tente criar o cluster novamente.

Para mais informações sobre possíveis erros e como corrigi-los, consulte Resolver problemas na criação de clusters de usuário no console do Google Cloud.

CLI da gcloud

Use o seguinte comando para criar um cluster de usuário:

gcloud container vmware clusters create

Após criar o cluster, você precisa criar pelo menos um pool de nós usando o seguinte comando:

gcloud container vmware node-pools create

A maioria das flags para criar o cluster e o pool de nós corresponde aos campos no arquivo de configuração do cluster de usuário. Para ajudar você a começar, teste o comando completo na seção exemplos.

Coletar informações

Colete algumas informações necessárias para criar o cluster.

Confira o nome e o local da assinatura da frota do cluster de administrador:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto em que o cluster de administrador está registrado.

O resultado será assim:
```
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
```
O local especifica onde os serviços Fleet e Connect são executados. Os clusters de administrador criados antes da versão 1.28 são gerenciados pelos serviços globais do Fleet e do Connect. Na versão 1.28 e mais recentes, é possível especificar global ou uma região do Google Cloud ao criar o cluster de administrador. Especifique a região na flag --admin-cluster-membership-location nos comandos de exemplo a seguir.
Veja 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:
- ADMIN_CLUSTER_NAME: o nome do cluster de administrador.
- FLEET_HOST_PROJECT_ID: o ID do projeto em que o cluster está registrado.
- ADMIN_CLUSTER_REGION: a região de associação à frota do cluster de administrador. É uma região global ou do Google Cloud. Use o local do cluster de administrador da saída de gcloud container fleet memberships list.
- REGION: a região do Google Cloud que você vai usar ao criar o cluster. Essa é a região em que a API GKE On-Prem é executada e armazena os metadados.
  - Se o cluster de administrador estiver registrado na API GKE On-Prem, use a mesma região do cluster de administrador. Para descobrir 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 registrado na API GKE On-Prem, especifique us-west1 ou outra região com suporte. Se você registrar o cluster de administrador na API GKE On-Prem, use a mesma região do cluster de usuário.
A saída deste comando gcloud container vmware clusters query-version-config é semelhante a:
```
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 mostra uma explicação das versões que podem ser usadas para criar ou fazer upgrade de clusters de usuários. As versões que podem ser usadas para criar um cluster de usuário são anotadas com isInstalled: true, o que significa que o cluster de administrador tem os componentes específicos da versão necessários para gerenciar os clusters de usuário dessa versão. Se você quiser usar uma versão instalada no cluster de administrador, pule para a seção Exemplos para criar o cluster de usuário.

Instalar uma versão mais recente

Um cluster de administrador pode gerenciar clusters de usuários em diferentes versões. A saída do comando query-version-config lista outras versões que podem ser usadas ao criar o cluster. Se você quiser criar um cluster de usuário que seja uma versão posterior ao cluster de administrador, será necessário fazer o download e implantar os componentes necessários para o cluster de administrador gerenciar os clusters de usuário dessa versão, da seguinte maneira:

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 listadas na saída do comando query-version-config.

Esse comando faz o download da versão dos componentes especificados em --required-platform-version no cluster de administrador e, em seguida, implanta os componentes. Agora é possível criar um cluster de usuário com a versão especificada.

Se você executar o gcloud container vmware clusters query-version-config novamente, a versão especificada será anotada com isInstalled: true.

Exemplos

Os exemplos a seguir mostram como criar um cluster de usuário com diferentes balanceadores de carga com o Controlplane V2 ativado. Com o Controlplane V2, o plano de controle de um cluster de usuário é executado em um ou mais nós no próprio cluster de usuário. Recomendamos ativar o Controlplane V2. Na versão 1.30 e mais recentes, novos clusters de usuário precisam ter o Controlplane V2 ativado. Para mais informações sobre as opções de balanceamento de carga disponíveis, consulte Visão geral do balanceador de carga.

A maioria dos exemplos usa os valores padrão para configurar os nós do plano de controle. Se você quiser alterar qualquer um dos padrões, inclua as flags descritas na seção flags do plano de controle. Se necessário, você também pode alterar algumas configurações do vSphere.

Antes de executar o comando gcloud para criar o cluster, inclua --validate-only para validar a configuração especificada nas flags para o comando gcloud. Quando estiver tudo pronto para criar o cluster, remova essa flags e execute o comando.

Se você receber um erro depois que o comando gcloud container vmware clusters create tiver sido executado por cerca de um minuto ou mais, verifique se o cluster foi parcialmente criado executando o comando a seguir:

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

Se o cluster não estiver listado na saída, corrija o erro e execute novamente gcloud container vmware clusters create.

Se o cluster estiver listado na saída, exclua-o usando o 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 gcloud container vmware clusters create novamente.

Depois que o cluster estiver em execução, adicione um pool de nós antes de implantar cargas de trabalho, conforme descrito na seção Criar um pool de nós.

MetalLB e DHCP

Esse exemplo mostra como criar um cluster de usuário com o balanceador de carga MetalLB agrupado e usar o servidor DHCP para receber endereços IP para os nós de trabalho do cluster.

Só é possível usar o MetalLB no cluster de usuário se o cluster de administrador estiver usando o MetalLB. Essa opção de balanceamento de carga requer configuração mínima. Executado diretamente nos nós do cluster e não requer VMs extras Para mais informações sobre os benefícios do uso do MetalLB e como ele se compara às outras opções de balanceamento de carga, consulte Balanceamento de carga em pacote com MetalLB.

O comando de exemplo cria um cluster de usuário com as seguintes características, que podem ser modificadas conforme necessário para seu ambiente.

Sinalizar	Descrição
`--admin-users`	Concede a você e a outro usuário direitos administrativos totais no cluster.
`--enable-control-plane-v2`	Ativa o Controlplane V2, que é recomendado e obrigatório na versão 1.30 e mais recentes.
`--control-plane-ip-block`	Um endereço IP para o nó do plano de controle. Para criar um cluster de usuário de alta disponibilidade (HA, na sigla em inglês), especifique três endereços IP e adicione a flag `--replicas=3`.
`--metal-lb-config-address-pools`	Dois pools de endereços para o balanceador de carga do MetalLB. É necessário ter pelo menos um pool de endereços> Você pode especificar mais, se for necessário. Para conveniência, o exemplo contém um pool de endereços com o nome ingress-vip-pool como um lembrete de que o endereço IP do VIP de entrada precisa estar em um dos pools de endereços. Especifique o CIDR de 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:

USER_CLUSTER_NAME: um nome de sua escolha pelo cluster de usuário. O nome não pode ser alterado após a criação do cluster. O nome precisa:
- conter no máximo 40 caracteres
- conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
- começam com um caractere alfabético
- terminar com um caractere alfanumérico.
FLEET_HOST_PROJECT_ID: o ID do projeto em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado. O projeto host da frota não pode ser alterado após a criação do cluster.
ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gerencia o cluster de usuário. Na flag --admin-cluster-membership, é possível 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
```
Como alternativa, defina --admin-cluster-membership como o nome do cluster de administrador, como no comando de exemplo. Quando você usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e o local com --admin-cluster-membership-location. O local do cluster de administrador é global ou uma região do Google Cloud. Se você precisar encontrar a região, execute gcloud container fleet memberships list.
REGION: a região do Google Cloud em que a API GKE On-Prem (gkeonprem.googleapis.com), o serviço do Fleet (gkehub.googleapis.com) e o serviço do Connect (gkeconnect.googleapis.com) são executados. Especifique us-west1 ou outra região compatível. Após a criação do cluster, não é possível alterar a região. Essa configuração especifica a região em que os itens a seguir estão armazenados:
- Os metadados do cluster de usuário de que a API GKE On-Prem precisa para gerenciar o ciclo de vida do cluster
- Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
- O registro de auditoria do administrador criado pelos registros de auditoria do Cloud
O nome, o projeto e o local do cluster identificam exclusivamente o cluster no Google Cloud.

Importante: se você planeja instalar o Cloud Service Mesh, instale a versão 1.19.3 ou mais recente. Isso é necessário porque os serviços de frota e Connect são executados em uma região.
VERSION: a versão do Google Distributed Cloud para o cluster de usuário.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se você não incluir a flag --admin-users como a criadora do cluster, por padrão, você receberá privilégios de administrador do cluster. No entanto, se você incluir --admin-users para designar outro usuário como administrador, o padrão será substituído e será necessário incluir seu endereço de e-mail e o endereço de e-mail do outro administrador. Por exemplo, para adicionar dois administradores:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando o cluster é criado, a API GKE On-Prem aplica as políticas de de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces.

Observação: além das políticas do RBAC do Kubernetes, você precisa conceder alguns papéis do Identity and Access Management (IAM) aos usuários que não são proprietários de projetos. Para detalhes sobre como conceder os papéis do IAM, consulte Conceder os papéis necessários.

SERVICE_CIDR_BLOCK: um intervalo de endereços IP no formato CIDR que será usado para serviços no cluster. Precisa ser pelo menos o intervalo /24.
Exemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, que será usado para pods no cluster. Precisa ser pelo menos um intervalo /18.
Exemplo: --pod-address-cidr-blocks=192.168.0.0/16

--metal-lb-config-address-pools: inclua essa flag para especificar a configuração de 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 de sua escolha para o pool.
- avoid-buggy-ips: se você definir isso como True, o controlador MetalLB não atribuirá endereços IP que terminam em .0 ou .255 aos Serviços. Isso evita o problema de dispositivos de consumo com bug que descartam o tráfego por erro enviado para esses endereços IP especiais. Se não for especificado, False será usado como padrão.
- manual-assign: se você não quiser que o controlador do MetalLB atribua automaticamente endereços IP deste pool aos Serviços, defina-o como True. Em seguida, um desenvolvedor pode criar um Serviço do tipo LoadBalancer e especificar manualmente um dos endereços do pool. Se não for especificado, manual-assign será definido como False.
- Na lista de addresses: cada endereço precisa ser um intervalo em notação CIDR ou hífen. Para especificar um único endereço IP em um pool (como o VIP de entrada), use /32 na notação CIDR (por exemplo, 192.0.2.1/32).
Observações:
- Coloque o valor inteiro entre aspas simples.
- Não é permitido usar 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 você decidiu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário.
Exemplo: --control-plane-vip=203.0.113.3
INGRESS_VIP: o endereço IP que você escolheu 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 precisa estar em um dos pools de endereços do MetalLB.

--enable-dhcp: inclua --enable-dhcp se quiser que os nós do cluster recebam o endereço IP de um servidor DHCP fornecido. Não inclua essa flag se quiser fornecer endereços IP estáticos para os nós do cluster ou se quiser configurar o balanceamento de carga manual.

MetalLB e IPs estáticos

Neste exemplo, mostramos como criar um cluster de usuário com o balanceador de carga MetalLB agrupado e atribuir endereços IP estáticos aos nós de trabalho do cluster.

O comando de exemplo cria um cluster de usuário com as seguintes características, que podem ser modificadas conforme necessário para seu ambiente.

Sinalizar	Descrição
`--admin-users`	Concede a você e a outro usuário direitos administrativos totais no cluster.
`--enable-control-plane-v2`	Ativa o Controlplane V2, que é recomendado e obrigatório na versão 1.30 e mais recentes.
`--control-plane-ip-block`	Um endereço IP para o nó do plano de controle. Para criar um cluster de usuário de alta disponibilidade (HA, na sigla em inglês), especifique três endereços IP e adicione a flag `--replicas=3`.
`--metal-lb-config-address-pools`	Dois pools de endereços para o balanceador de carga do MetalLB. É necessário ter pelo menos um pool de endereços> Você pode especificar mais, se for necessário. Para conveniência, o exemplo contém um pool de endereços com o nome ingress-vip-pool como um lembrete de que o endereço IP do VIP de entrada precisa estar em um dos pools de endereços. Especifique o CIDR de 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. Isso inclui um endereço para um nó extra que pode ser usado durante o upgrade e a atualização. É possível especificar mais endereços IP, se necessário. O nome do host é 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:

USER_CLUSTER_NAME: um nome de sua escolha pelo cluster de usuário. O nome não pode ser alterado após a criação do cluster. O nome precisa:
- conter no máximo 40 caracteres
- conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
- começam com um caractere alfabético
- terminar com um caractere alfanumérico.
FLEET_HOST_PROJECT_ID: o ID do projeto em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado. O projeto host da frota não pode ser alterado após a criação do cluster.
ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gerencia o cluster de usuário. Na flag --admin-cluster-membership, é possível 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
```
Como alternativa, defina --admin-cluster-membership como o nome do cluster de administrador, como no comando de exemplo. Quando você usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e o local com --admin-cluster-membership-location. O local do cluster de administrador é global ou uma região do Google Cloud. Se você precisar encontrar a região, execute gcloud container fleet memberships list.
REGION: a região do Google Cloud em que a API GKE On-Prem (gkeonprem.googleapis.com), o serviço do Fleet (gkehub.googleapis.com) e o serviço do Connect (gkeconnect.googleapis.com) são executados. Especifique us-west1 ou outra região compatível. Após a criação do cluster, não é possível alterar a região. Essa configuração especifica a região em que os itens a seguir estão armazenados:
- Os metadados do cluster de usuário de que a API GKE On-Prem precisa para gerenciar o ciclo de vida do cluster
- Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
- O registro de auditoria do administrador criado pelos registros de auditoria do Cloud
O nome, o projeto e o local do cluster identificam exclusivamente o cluster no Google Cloud.

Importante: se você planeja instalar o Cloud Service Mesh, instale a versão 1.19.3 ou mais recente. Isso é necessário porque os serviços de frota e Connect são executados em uma região.
VERSION: a versão do Google Distributed Cloud para o cluster de usuário.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se você não incluir a flag --admin-users como a criadora do cluster, por padrão, você receberá privilégios de administrador do cluster. No entanto, se você incluir --admin-users para designar outro usuário como administrador, o padrão será substituído e será necessário incluir seu endereço de e-mail e o endereço de e-mail do outro administrador. Por exemplo, para adicionar dois administradores:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando o cluster é criado, a API GKE On-Prem aplica as políticas de de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces.

Observação: além das políticas do RBAC do Kubernetes, você precisa conceder alguns papéis do Identity and Access Management (IAM) aos usuários que não são proprietários de projetos. Para detalhes sobre como conceder os papéis do IAM, consulte Conceder os papéis necessários.

SERVICE_CIDR_BLOCK: um intervalo de endereços IP no formato CIDR que será usado para serviços no cluster. Precisa ser pelo menos o intervalo /24.
Exemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, que será usado para pods no cluster. Precisa ser pelo menos um intervalo /18.
Exemplo: --pod-address-cidr-blocks=192.168.0.0/16

--metal-lb-config-address-pools: inclua essa flag para especificar a configuração de 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 de sua escolha para o pool.
- avoid-buggy-ips: se você definir isso como True, o controlador MetalLB não atribuirá endereços IP que terminam em .0 ou .255 aos Serviços. Isso evita o problema de dispositivos de consumo com bug que descartam o tráfego por erro enviado para esses endereços IP especiais. Se não for especificado, False será usado como padrão.
- manual-assign: se você não quiser que o controlador do MetalLB atribua automaticamente endereços IP deste pool aos Serviços, defina-o como True. Em seguida, um desenvolvedor pode criar um Serviço do tipo LoadBalancer e especificar manualmente um dos endereços do pool. Se não for especificado, manual-assign será definido como False.
- Na lista de addresses: cada endereço precisa ser um intervalo em notação CIDR ou hífen. Para especificar um único endereço IP em um pool (como o VIP de entrada), use /32 na notação CIDR (por exemplo, 192.0.2.1/32).
Observações:
- Coloque o valor inteiro entre aspas simples.
- Não é permitido usar 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 você decidiu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário.
Exemplo: --control-plane-vip=203.0.113.3
INGRESS_VIP: o endereço IP que você escolheu 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 precisa estar em um dos pools de endereços do MetalLB.

--static-ip-config-ip-blocks: especifica o gateway padrão, a máscara de sub-rede e uma lista dos endereços IP estáticos para os nós de trabalho no cluster de usuário. 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.

Observações:
- Coloque o valor inteiro entre aspas simples.
- Não é permitido usar espaços em branco, exceto entre um endereço IP e um nome do host.
Na lista de endereços IP:
- É possível 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, você tem a opção de especificar um nome do host após o endereço IP. Separe o endereço IP e o nome do host com um espaço. Se você não inserir um nome do host, o Google Distributed Cloud usará o nome da VM do vSphere como o nome do host.
- Se você especificar um bloco CIDR, não especifique um valor para o nome do host.
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 de servidores DNS para as VMs.
DNS_SEARCH_DOMAIN: uma lista separada por vírgulas dos domínios de pesquisa DNS que serão usados pelos hosts. Esses domínios são usados como parte de uma lista de pesquisa de domínio.
Por exemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: uma lista separada por vírgulas dos endereços IP de servidores de horário para uso das VMs.

LB manual e IPs estáticos

Neste exemplo, mostramos como criar um cluster de usuário com um balanceador de carga manual e atribuir endereços IP estáticos aos nós de trabalho do cluster.

Só é possível usar um balanceador de carga manual para o cluster de usuário se o cluster de administrador usar um balanceador de carga manual. No Google Distributed Cloud, o servidor da API Kubernetes, o proxy de entrada e o serviço de complemento para agregação de registros são expostos por um serviço do Kubernetes do tipo LoadBalancer. Escolha seus próprios valores de nodePort no intervalo 30000 - 32767 para esses Serviços. Para o proxy de entrada, escolha um valor de nodePort para tráfego HTTP e HTTPS. Consulte Como ativar o modo de balanceamento de carga manual para mais informações.

O comando de exemplo cria um cluster de usuário com as seguintes características, que podem ser modificadas conforme necessário para seu ambiente.

Sinalizar	Descrição
`--admin-users`	Concede a você e a outro usuário direitos administrativos totais no cluster.
`--enable-control-plane-v2`	Ativa o Controlplane V2, que é recomendado e obrigatório na versão 1.30 e mais recentes.
`--control-plane-ip-block`	Um endereço IP para o nó do plano de controle. Para criar um cluster de usuário de alta disponibilidade (HA, na sigla em inglês), 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. Isso inclui um endereço para um nó extra que pode ser usado durante o upgrade e a atualização. É possível especificar mais endereços IP, se necessário. O nome do host é 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:

USER_CLUSTER_NAME: um nome de sua escolha pelo cluster de usuário. O nome não pode ser alterado após a criação do cluster. O nome precisa:
- conter no máximo 40 caracteres
- conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
- começam com um caractere alfabético
- terminar com um caractere alfanumérico.
FLEET_HOST_PROJECT_ID: o ID do projeto em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado. O projeto host da frota não pode ser alterado após a criação do cluster.
ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gerencia o cluster de usuário. Na flag --admin-cluster-membership, é possível 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
```
Como alternativa, defina --admin-cluster-membership como o nome do cluster de administrador, como no comando de exemplo. Quando você usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e o local com --admin-cluster-membership-location. O local do cluster de administrador é global ou uma região do Google Cloud. Se você precisar encontrar a região, execute gcloud container fleet memberships list.
REGION: a região do Google Cloud em que a API GKE On-Prem (gkeonprem.googleapis.com), o serviço do Fleet (gkehub.googleapis.com) e o serviço do Connect (gkeconnect.googleapis.com) são executados. Especifique us-west1 ou outra região compatível. Após a criação do cluster, não é possível alterar a região. Essa configuração especifica a região em que os itens a seguir estão armazenados:
- Os metadados do cluster de usuário de que a API GKE On-Prem precisa para gerenciar o ciclo de vida do cluster
- Os dados do Cloud Logging e do Cloud Monitoring dos componentes do sistema
- O registro de auditoria do administrador criado pelos registros de auditoria do Cloud
O nome, o projeto e o local do cluster identificam exclusivamente o cluster no Google Cloud.

Importante: se você planeja instalar o Cloud Service Mesh, instale a versão 1.19.3 ou mais recente. Isso é necessário porque os serviços de frota e Connect são executados em uma região.
VERSION: a versão do Google Distributed Cloud para o cluster de usuário.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se você não incluir a flag --admin-users como a criadora do cluster, por padrão, você receberá privilégios de administrador do cluster. No entanto, se você incluir --admin-users para designar outro usuário como administrador, o padrão será substituído e será necessário incluir seu endereço de e-mail e o endereço de e-mail do outro administrador. Por exemplo, para adicionar dois administradores:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando o cluster é criado, a API GKE On-Prem aplica as políticas de de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces.

Observação: além das políticas do RBAC do Kubernetes, você precisa conceder alguns papéis do Identity and Access Management (IAM) aos usuários que não são proprietários de projetos. Para detalhes sobre como conceder os papéis do IAM, consulte Conceder os papéis necessários.

SERVICE_CIDR_BLOCK: um intervalo de endereços IP no formato CIDR que será usado para serviços no cluster. Precisa ser pelo menos o intervalo /24.
Exemplo: --service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, que será usado para pods no cluster. Precisa ser pelo menos um intervalo /18.
Exemplo: --pod-address-cidr-blocks=192.168.0.0/16

CONTROL_PLANE_VIP: o endereço IP que você decidiu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário.

Exemplo: --control-plane-vip=203.0.113.3
INGRESS_VIP: o endereço IP que você escolheu configurar no balanceador de carga para o proxy de entrada.

Exemplo: --ingress-vip=203.0.113.4
INGRESS_HTTP_NODE_PORT: um valor de nodePort do tráfego HTTP para o proxy de entrada (como 30243).
INGRESS_HTTPS_NODE_PORT: um valor de nodePort para tráfego HTTPS para o proxy de entrada (como 30879).

--static-ip-config-ip-blocks: especifica o gateway padrão, a máscara de sub-rede e uma lista dos endereços IP estáticos para os nós de trabalho no cluster de usuário. 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.

Observações:
- Coloque o valor inteiro entre aspas simples.
- Não é permitido usar espaços em branco, exceto entre um endereço IP e um nome do host.
Na lista de endereços IP:
- É possível 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, você tem a opção de especificar um nome do host após o endereço IP. Separe o endereço IP e o nome do host com um espaço. Se você não inserir um nome do host, o Google Distributed Cloud usará o nome da VM do vSphere como o nome do host.
- Se você especificar um bloco CIDR, não especifique um valor para o nome do host.
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 de servidores DNS para as VMs.
DNS_SEARCH_DOMAIN: uma lista separada por vírgulas dos domínios de pesquisa DNS que serão usados pelos hosts. Esses domínios são usados como parte de uma lista de pesquisa de domínio.
Por exemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
NTP_SERVER: uma lista separada por vírgulas dos endereços IP de servidores de horário para uso das VMs.

Flags do plano de controle

Se você quiser usar valores não padrão para a configuração do plano de controle, inclua uma ou mais das seguintes sinalizações:

--cpus=vCPUS: o número de vCPUs (mínimo de 4) para cada nó do plano de controle para o cluster de usuário. Se não for especificado, o padrão será quatro vCPUs.
--memory=MEMORY: o tamanho da memória em mebibytes (MiB) para cada plano de controle do cluster de usuário. O valor mínimo é 8.192 e precisa ser um múltiplo de 4. Se não for especificado, o padrão será 8.192.
--replicas=NODES: o número de nós do plano de controle para o cluster de usuário. Por exemplo, é possível selecionar um nó do plano de controle para um ambiente de desenvolvimento e três nós do plano para ambientes de alta disponibilidade (HA, na sigla em inglês).
--enable-auto-resize: se você quiser ativar o redimensionamento automático dos nós do plano de controle para o cluster de usuário, 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 controle para o cluster de usuário são redimensionados de acordo com o número de nós de trabalho no cluster de usuário. Portanto, à medida que você adiciona mais nós de trabalho ao cluster de usuário, os nós do plano de controle aumentam de tamanho.
--enable-control-plane-v2: para ativar o Controlplane V2, o que recomendamos, inclua essa flag. Quando o Controlplane V2 está ativado, o plano de controle de um cluster de usuário é executado em um ou mais nós no próprio cluster. Na versão 1.30 e mais recentes, o Controlplane V2 é necessário.

Se você ativar o Controlplane V2, também precisará especificar as seguintes flags:
- --dns-servers=DNS_SERVER_1,...: uma lista separada por vírgulas dos endereços IP de servidores DNS para as VMs.
- --ntp-servers=NTP_SERVER_1,...: uma lista separada por vírgulas dos endereços IP de servidores de horário para uso das VMs.
- --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.
  
  Observações:
  - Coloque o valor inteiro entre aspas simples.
  - Não é permitido usar espaços em branco, exceto entre um endereço IP e um nome do host.
    
    Na lista de endereços IP:
  - É possível 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, você tem a opção de especificar um nome do host após o endereço IP. Separe o endereço IP e o nome do host com um espaço.
  - Se você especificar um bloco CIDR, não especifique um valor para o nome do host.
    
    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 serão usados pelos hosts. Esses domínios são usados como parte de uma lista de pesquisa de domínio.
  
  Por exemplo:
```
--dns-search-domains example.com,examplepetstore.com
```
Para ver uma lista completa das sinalizações e as descrições delas, consulte a referência da CLI gcloud.

Flags do vSphere

Especifique as seguintes flags opcionais, se necessário:
--disable-aag-config: se você não incluir essa flag, as regras de antiafinidade do Distributed Resource Scheduler (DRS) do VMware serão criadas automaticamente para os nós do cluster de usuário, fazendo com que eles sejam distribuídos em pelo menos três hosts físicos no data center. Verifique se o ambiente vSphere atende aos requisitos. Se o cluster não atender aos requisitos, inclua esta flag.

Observação: se você seguiu a etapa Configurar infraestrutura mínima, haverá apenas um host ESXi, então inclua essa flag.
--disable-vsphere-csi: se você não incluir essa flag, os componentes do vSphere Container Storage Interface (CSI) serão implantados no cluster de usuário. O driver CSI é executado em um cluster nativo do Kubernetes implantado no vSphere para provisionar volumes permanentes no armazenamento do vSphere. Para mais informações, consulte Como usar o driver da interface de armazenamento do contêiner do vSphere. Se você não quiser implantar os componentes da CSI, inclua essa flag.

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

Acompanhar o progresso da criação do cluster

A saída do comando de criação de cluster é semelhante a esta:
```
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. Descubra o status 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 gcloud container vmware operations.

Leva 15 minutos ou mais para criar o cluster de usuário. É possível visualizar o cluster no Console do Google Cloud na página Clusters do GKE.

Crie um pool de nós.

Depois que o cluster for criado, você precisará criar pelo menos um pool de nós antes de implantar 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:
NODE_POOL_NAME: um nome de sua escolha para o pool de nós. O nome precisa:
- conter no máximo 40 caracteres
- conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
- começam com um caractere alfabético
- terminar com um caractere alfanumérico.
USER_CLUSTER_NAME: o nome do cluster de usuário recém-criado.
FLEET_HOST_PROJECT_ID: o ID do projeto em que o cluster está registrado.
REGION: a região do Google Cloud que você especificou ao criar o cluster.
IMAGE_TYPE: o tipo de imagem do SO a ser executado nas VMs no pool de nós Defina como ubuntu_containerd ou cos.
BOOT_DISK_SIZE: o tamanho do disco de inicialização em gigabytes (GiB) para cada nó do pool. O mínimo é de 40 GiB.
vCPUs: o número de vCPUs de cada nó no pool de nós. O mínimo é 4.
MEMORY: o tamanho da memória em mebibytes (MiB) para cada nó no pool. O mínimo é 8.192 MiB por nó de trabalho do cluster de usuário, e o valor precisa ser um múltiplo de 4.
NODES: o número de nós no pool de nós. O mínimo é 3.
Se você estiver usando o MetalLB como balanceador de carga, inclua --enable-load-balancer se quiser que o alto-falante do MetalLB seja executado nos nós do pool. O MetalLB precisa estar ativado em pelo menos um pool de nós. Se você não incluir essa flags, precisará criar outro pool de nós para usar no MetalLB.

Para informações sobre sinalizações opcionais, consulte Adicionar um pool 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.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --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

Para uma descrição da sinalização --metal-lb-config-address-pools, consulte Balanceador de carga.

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.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --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

LB 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.30.0-gke.1930 \
    --admin-users=sara@example.com \
    --admin-users=amal@example.com \
    --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

Confira o nome e o local da assinatura da frota do cluster de administrador:
```
gcloud container fleet memberships list \
    --project=FLEET_HOST_PROJECT_ID
```
Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto em que o cluster de administrador está registrado.

O resultado será assim:
```
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
```
O local especifica onde os serviços Fleet e Connect são executados. Os clusters de administrador criados antes da versão 1.28 são gerenciados pelos serviços globais do Fleet e do Connect. Na versão 1.28 e mais recentes, é possível especificar global ou uma região do Google Cloud ao criar o cluster.
Veja 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:
- ADMIN_CLUSTER_NAME: o nome do cluster de administrador.
- FLEET_HOST_PROJECT_ID: o ID do projeto em que o cluster está registrado.
- ADMIN_CLUSTER_REGION: a região de associação à frota do cluster de administrador. É uma região global ou do Google Cloud. Use o local do cluster de administrador da saída de gcloud container fleet memberships list.
- REGION: a região do Google Cloud que você vai usar ao criar o cluster. É a região em que a API GKE On-Prem e os serviços Fleet e Connect são executados. Especifique us-west1 ou outra região compatível.
A saída deste comando é semelhante a:
```
versions:
- isInstalled: true
  version: 1.14.3-gke.25
- version: 1.14.4-gke.54
- version: 1.15.0-gke.581
```
As versões que podem ser usadas para criar um cluster de usuário são anotadas com isInstalled=true, o que significa que o cluster de administrador tem os componentes específicos da versão necessários para gerenciar os clusters de usuário dessa versão. Se você quiser criar um cluster de usuário com outra versão disponível, consulte Instalar uma versão posterior à versão do cluster de administrador.

Exemplo

Use a amostra de configuração básica a seguir para criar um cluster de usuário com o balanceador de carga MetalLB empacotado e um pool de nós.

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

Definir variáveis em `terraform.tfvars`

O exemplo fornece um arquivo de variáveis de exemplo para passar paramain.tf, que mostra como configurar o balanceador de carga MetalLB empacotado e ativar os nós do cluster para receber os endereços IP de um servidor DHCP fornecido por você.

Clone o repositório anthos-samples e mude para o diretório em que a amostra do Terraform está localizada:

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

terraform.tfvars.samplefaça uma cópia do arquivo;
```
cp terraform.tfvars.sample terraform.tfvars
```
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 a seguir descreve as variáveis:
- project_id: o ID do projeto em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado. O projeto host da frota não pode ser alterado após a criação do cluster.
- region: a região do Google Cloud em que 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 compatível.
- admin_cluster_name: o nome do cluster de administrador que gerencia o cluster de usuário. O exemplo pressupõe que o cluster de administrador usa global como a região. Se você tiver um cluster de administrador regional:
  1. Abra main.tf em um editor de texto.
  2. Pesquise admin_cluster_membership com esta aparência:
```
admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
```
  1. Mude global para a região que o cluster de administrador usa e salve o arquivo.
- on_prem_version: a versão do Google Distributed Cloud para o cluster de usuário. Normalmente, você especifica a mesma versão do cluster de administrador. Para especificar uma versão posterior, instale uma versão posterior à versão do cluster de administrador. Se você não souber a versão do cluster de administrador, execute gcloud container vmware clusters query-version-config, que é a primeira etapa em Instalar uma versão posterior do que a versão do cluster de administrador.
- admin_user_emails: uma lista de endereços de e-mail dos usuários que receberão privilégios administrativos no cluster. Adicione seu endereço de e-mail se você pretende administrar o cluster.
  
  Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces. Isso também permite que os usuários façam login no console usando a identidade do Google.
- cluster_name: um nome de sua escolha pelo cluster de usuário. O nome não pode ser alterado após a criação do cluster. O nome precisa:
  - conter no máximo 40 caracteres
  - conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
  - começam com um caractere alfabético
  - terminar com um caractere alfanumérico.
- control_plane_node_cpus: o número de vCPUs de cada nó do plano de controle para o cluster de usuário. O mínimo é 4 vCPUs.
- control_plane_node_memory: o tamanho da memória em mebibytes (MiB) para cada plano de controle do cluster de usuário. O valor mínimo é 8.192 e precisa ser um múltiplo de 4.
- control_plane_node_replicas: o número de nós do plano de controle para o cluster de usuário. Por exemplo, é possível inserir um nó do plano de controle para um ambiente de desenvolvimento e três nós do plano para ambientes de alta disponibilidade (HA, na sigla em inglês).
- control_plane_vip: o endereço IP virtual (VIP) que você escolheu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário.
- ingress_vip: o endereço IP que você escolheu configurar no balanceador de carga para o proxy de entrada.
- lb_address_pools: uma lista de mapas que definem os pools de endereços a serem usados pelo balanceador de carga do MetalLB. O VIP de entrada precisa estar em um desses pools. Especifique o seguinte:
  - name: um nome para o pool.
  - 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 em um pool (como o VIP de entrada), use /32 na notação CIDR (por exemplo: 192.0.2.1/32).
  Substitua os endereços IP de exemplo pelos seus valores e adicione outros pools de endereços, se necessário.
Salve as alterações em terraform.tfvars. Se você não quiser fazer alterações opcionais em main.tf, pule para a seção a seguir: Criar o cluster e um pool de nós.

Opcional: defina as configurações do cluster em `main.tf`

Essa seção explica algumas mudanças de configuração opcionais que podem ser feitas em main.tf. Antes de fazer mudanças, faça um backup de main.tf:

cp main.tf main.tf.bak

Modo de endereçamento IP de nó de trabalho

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

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"
        }
      }
    }
  }

Substitua o seguinte por seus valores:
- service_address_cidr_blocks: um intervalo de endereços IP no formato CIDR que será usado para serviços no cluster. Precisa ser pelo menos o intervalo /24.
- pod_address_cidr_blocks: um intervalo de endereços IP, no formato CIDR, que será usado para pods no cluster. Precisa ser pelo menos um intervalo /18.
- dns_servers: uma lista dos endereços IP dos servidores DNS das VMs.
- ntp_servers: uma lista dos endereços IP dos servidores de horário a serem usados pelas VMs.
- No bloco static_ip_config, substitua os valores de netmask e gateway pelos endereços da sua rede. Substitua ip e hostname pelos endereços IP e nomes de host dos nós de trabalho.

Configurar Controlplane V2

Por padrão, main.tf configura o plano de controle para que o cluster de usuário seja executado em um ou mais nós no cluster de administrador (chamado de modelo kubeception). Se preferir, ative o Controlplane V2. Quando o Controlplane V2 está ativado, o plano de controle de um cluster de usuário é executado em um ou mais nós no próprio cluster. Para configurar o Controlplane V2, faça as seguintes alterações no main.tf:

Adicione a seguinte linha após a linha com admin_cluster_membership:
```
  enable_control_plane_v2 = "true"
```

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"
      }
    }
  }

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

Criar o cluster e um pool de nós

Inicialize e crie o plano do Terraform:
```
terraform init
```
O Terraform instala todas as bibliotecas necessárias, como o provedor do Google Cloud.
Revise a configuração e faça alterações, se necessário:
```
terraform plan
```
Aplique o plano do Terraform para criar o cluster de usuário:
```
terraform apply
```
Leva cerca de 15 minutos ou mais para criar o cluster de usuário e outros 15 minutos para criar o pool de nós. É possível visualizar o cluster no Console do Google Cloud na página Clusters do GKE.

Solução de problemas

Consulte Solução de problemas na criação e no upgrade de clusters.

Criar um cluster de usuário

Antes de começar

Criar um cluster de usuário

gkectl

Visão geral do procedimento

Preencher os arquivos de configuração

name

gkeOnPremVersion

enableControlplaneV2

kubeception

enableDataplaneV2

vCenter

Como usar um data center e um cluster do vSphere

Como usar clusters do vSphere separados

Como usar data centers separados do vSphere

Como usar contas do vCenter separadas

Como usar instâncias separadas do vCenter Server

network

loadBalancer

advancedNetworking

multipleNetworkInterfaces

storage

masterNode

nodePools

antiAffinityGroups

stackdriver

gkeConnect

gkeOnPremAPI

usageMetering

cloudAuditLogging

Exemplo de arquivos de configuração preenchidos

usuario-ipblock.yaml

user-cluster.yaml

Validar o arquivo de configuração

3. (Opcional) Importe imagens do SO para o vSphere e envie imagens de contêiner para um registro particular

4. Criar um cluster de usuário

Crie um cluster de usuário:

Localizar o arquivo kubeconfig do cluster de usuário

5. Verificar se o cluster de usuário está em execução

Console

Começar

Noções básicas sobre clusters

Plano de controle

Rede

Balanceador de carga

Empacotado com MetalLB

F5 BIG-IP

Manual

Recursos

Pools de nós

CLI da gcloud

Coletar informações

Instalar uma versão mais recente

Exemplos

MetalLB e DHCP

MetalLB e IPs estáticos

LB manual e IPs estáticos

Flags do plano de controle

Flags do vSphere

Acompanhar o progresso da criação do cluster

Crie um pool de nós.

Exemplos de comandos gcloud

MetalLB e DHCP

MetalLB e IPs estáticos

LB manual e IPs estáticos

Terraform

Antes de começar

Exemplo

Definir variáveis em terraform.tfvars

Opcional: defina as configurações do cluster em main.tf

Modo de endereçamento IP de nó de trabalho

Configurar Controlplane V2

Criar o cluster e um pool de nós

Solução de problemas

A seguir

`name`

`gkeOnPremVersion`

`enableControlplaneV2`

`enableDataplaneV2`

`vCenter`

`network`

`loadBalancer`

`advancedNetworking`

`multipleNetworkInterfaces`

`storage`

`masterNode`

`nodePools`

`antiAffinityGroups`

`stackdriver`

`gkeConnect`

`gkeOnPremAPI`

`usageMetering`

`cloudAuditLogging`

Definir variáveis em `terraform.tfvars`

Opcional: defina as configurações do cluster em `main.tf`