Versão 1.15. Esta versão não é mais compatível. Para mais informações, consulte a política de suporte da versão.

Criar um cluster de usuário com clientes da API GKE On-Prem

Esta página descreve como criar um cluster de usuário usando o console do Google Cloud, a CLI do Google Cloud (gcloud CLI) ou o Terraform.

O que é a API GKE On-Prem?

A API GKE On-Prem é uma API hospedada no Google Cloud que permite gerenciar o ciclo de vida dos clusters no local usando o Terraform e aplicativos padrão do Google Cloud. A API GKE On-Prem é executada na infraestrutura do Google Cloud. Terraform, o console e a CLI gcloud são clientes da API e usam a API para criar clusters no data center.

Para gerenciar o ciclo de vida dos clusters, a API GKE On-Prem precisa armazenar metadados sobre o estado do cluster no Google Cloud, usando a região do Google Cloud especificada ao criá-lo. Esses metadados permitem que a API gerencie o ciclo de vida do cluster e não incluem dados específicos da carga de trabalho.

Ao criar um cluster usando um cliente da API GKE On-Prem, você especifica um projeto do Google Cloud. Depois de criado, o cluster é automaticamente registrado na frota do projeto especificado. Esse projeto é chamado de projeto host da frota. O projeto host da frota não pode ser alterado após a criação do cluster.

Se preferir, é possível criar um cluster de usuário criando um arquivo de configuração de cluster de usuário e usando gkectl, conforme descrito em Como criar um cluster de usuário usando a gkectl.

Se você quiser usar o Terraform, o console ou a CLI gcloud para gerenciar o ciclo de vida dos clusters que foram criados usando gkectl, consulte Configurar um cluster de usuário para ser gerenciado pela API GKE On-Prem.

Antes de começar

Nesta seção, descrevemos os requisitos para criar um cluster de usuário usando clientes da API GKE On-Prem.

Conceder permissões do IAM

Se você não for proprietário do projeto, precisará receber o papel roles/gkeonprem.admin.

Se você quiser acessar as páginas do GKE Enterprise e do Google Kubernetes Engine no console, também precisará ter os seguintes papéis:

Após a criação do cluster, se você não for um proprietário do projeto e quiser usar o gateway do Connect para conectar-se ao cluster de usuário pela linha de comando, os seguintes papéis são obrigatórios:

roles/gkehub.gatewayAdmin: esse papel permite acessar a API Connect Gateway. Se você precisar apenas de acesso somente leitura ao cluster, roles/gkehub.gatewayReader será suficiente.
roles/gkehub.viewer: esse papel permite recuperar credenciais de cluster.

Para saber mais sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Registrar o cluster de administrador

Você precisa ter um cluster de administrador e registrá-lo em uma frota antes de criar clusters de usuário usando clientes da API GKE On-Prem.

Se você ainda não criou um cluster de administrador, preencha a seção gkeConnect no arquivo de configuração do cluster de administrador.
Se você tiver um cluster de administrador, mas não tiver registrado ele, consulte Registrar um cluster de administrador.

Ativar os registros de auditoria de atividade do administrador no cluster de administrador

A geração de registros de atividade do administrador para os registros de auditoria do Cloud precisa estar ativada no cluster de administrador.

Se você ainda não criou um cluster de administrador, preencha a seção cloudAuditLogging no arquivo de configuração do cluster de administrador.
Para atualizar um cluster de administrador atual, consulte Ativar ou desativar a geração de registros para o Cloud Audit Logging para o cluster de administrador.

Ativar a geração de registros e o monitoramento no nível do sistema para o cluster de administrador

O Cloud Logging e o Cloud Monitoring precisam estar ativados no cluster de administrador.

Se você ainda não criou um cluster de administrador, preencha a seção stackdriver no arquivo de configuração do cluster de administrador.
Para atualizar um cluster de administrador atual, consulte Ativar ou desativar a geração de registros e o monitoramento do cluster de administrador.

APIs do Google obrigatórias

Verifique se todas as APIs do Google necessárias estão ativadas no projeto host da frota.

Além disso, é necessário ativar a API GKE On-Prem:

gcloud services enable --project FLEET_HOST_PROJECT_ID \
    gkeonprem.googleapis.com

Acesso à linha de comando

Após a criação do cluster, se você quiser usar o gateway do Connect para se conectar ao cluster de usuário pela linha de comando, faça o seguinte:

Verifique se você tem as seguintes ferramentas de linha de comando instaladas:

A versão mais recente da CLI gcloud.
kubectl para executar comandos em clusters do Kubernetes. Se precisar instalar kubectl, siga estas instruções

Se você estiver usando o Cloud Shell como ambiente shell para interagir com o Google Cloud, essas ferramentas estarão instaladas.

Versões disponíveis para novas instalações

Quando você cria um cluster de usuário, normalmente instala a versão do GKE no VMware que corresponde ao cluster de administrador. Mas é possível instalar uma versão de patch posterior ou uma versão secundária posterior. Por exemplo, convém instalar a versão mais recente do patch ao criar um cluster de usuário para coletar correções de bugs. Leva cerca de 7 a 10 dias após o lançamento do GKE no VMware para que a versão seja disponibilizada na API GKE On-Prem.

Se você quiser criar um cluster de usuário que seja uma versão posterior ao cluster de administrador, primeiro faça o download de um pacote específico de versões dos componentes que o cluster de administrador precisa para gerenciar clusters de usuários nessa versão. Em seguida, implante os componentes. Para mais informações, consulte Instalar uma versão posterior à versão do cluster de administrador.

Escolher uma ferramenta para criar o cluster

É possível usar o Terraform, o console do Google Cloud ou a Google Cloud CLI (CLI gcloud) para criar um cluster gerenciado pela API GKE On-Prem. Se esta é a primeira vez que você instala o GKE no VMware, talvez você ache o console a ferramenta mais fácil de usar.

Depois que você estiver mais familiarizado com as informações necessárias para criar clusters, poderá achar o Terraform ou a CLI gcloud mais conveniente, especialmente se for criar mais de um cluster. O Terraform é uma infraestrutura padrão do setor, como uma ferramenta de código. Se sua organização já usa o Terraform, convém usá-lo para criar clusters e gerenciar o ciclo de vida deles.

Com a CLI da gcloud, você pode salvar o comando com os argumentos dele em um arquivo de texto e fazer alterações conforme necessário para criar clusters adicionais. Se você estiver usando uma ferramenta de CI/CD, como o Cloud Build, poderá usar os comandos gcloud para criar um cluster e o pool de nós, bem como especificar as flags --impersonate-service-account e para automatizar a criação.

Criar um cluster de usuário

Console

A maioria dos campos no console do Google Cloud corresponde aos campos no arquivo de configuração do cluster de usuário.

No console do Google Cloud, acesse a página Criar um cluster do GKE no VMware.

Acessar "Criar um cluster do GKE no VMware
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.

As seções a seguir orientam você na configuração do cluster de usuários.

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 a API GKE On-Prem é executada e a região em que os itens a seguir 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 Google Cloud.
Selecione a versão do GKE no VMware 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 modelo 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 GKE no VMware 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.

Balanceador de carga F5 Big-IP

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.

Balanceador de carga manual

Configure o balanceamento de carga 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. Em GKE no VMware, 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.

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. O servidor da API Kubernetes de um cluster de usuário é executado no cluster de administrador.
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 infraestrutura mínima, você tem apenas um host ESXi. Portanto, não se esqueça de desmarcar Ativar grupos antiafinidade.
Clique em Próxima para configurar um pool de nós.

Pools de nós

O cluster será criado com pelo menos um pool de nós. Um pool de nós é um modelo para os grupos de nós 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.
NaMetadados do pool de nós (opcional) seção, se quiser adicionar o Kubernetes rótulos e taints , 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.

Antes de começar

Faça login com sua Conta do Google:
```
gcloud auth login
```
Atualize os componentes:
```
gcloud components update
```
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 \
  --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.
- REGION: a região do Google Cloud que você especificou quando registrou o cluster na API GKE On-Prem.
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.

Examples

Os exemplos a seguir mostram como criar um cluster de usuário com diferentes balanceadores de carga. Para mais informações sobre as opções de balanceamento de carga disponíveis, consulte Visão geral do balanceador de carga.

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

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 do cluster.

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 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.

Role a tela para cima, se necessário, para preencher o marcador ADMIN_CLUSTER_NAME para a flag --admin-cluster-membership. Este exemplo usa o nome do cluster de administrador totalmente especificado. Portanto, não é necessário incluir --admin-cluster-membership-location e --admin-cluster-membership-project.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp

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 sinalização --admin-cluster-membership, é possível usar o nome de cluster totalmente especificado, que tem o seguinte formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Outra opção é definir --admin-cluster-membership como o nome do cluster de administrador, como no comando de exemplo. Quando você usar apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com o --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 Fleet (gkehub.googleapis.com) e o serviço 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 onde os itens a seguir são armazenados:
- Os metadados do cluster de usuário 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 Anthos Service Mesh, precisa instalar a versão 1.19.3 ou mais recente. Isso é necessário porque os serviços Fleet e Connect são executados em uma região.
VERSION: a versão do GKE no VMware 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 controle de acesso com base em papéis (RBAC) do Kubernetes ao cluster para conceder a você e 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.
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 do cluster.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --metal-lb-config-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --static-ip-config-ip-blocks='gateway=GATEWAY,netmask=NETMASK,ips=IP_ADDRESS_1;IP_ADDRESS_2 HOST_2;...' \
  --dns-servers=DNS_SERVER,... \
  --dns-search-domains=DNS_SEARCH_DOMAIN,... \
  --ntp-servers=NTP_SERVER,...

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 sinalização --admin-cluster-membership, é possível usar o nome de cluster totalmente especificado, que tem o seguinte formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Outra opção é definir --admin-cluster-membership como o nome do cluster de administrador, como no comando de exemplo. Quando você usar apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com o --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 Fleet (gkehub.googleapis.com) e o serviço 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 onde os itens a seguir são armazenados:
- Os metadados do cluster de usuário 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 Anthos Service Mesh, precisa instalar a versão 1.19.3 ou mais recente. Isso é necessário porque os serviços Fleet e Connect são executados em uma região.
VERSION: a versão do GKE no VMware 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 controle de acesso com base em papéis (RBAC) do Kubernetes ao cluster para conceder a você e 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.
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 GKE no VMware 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.
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.
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.

F5 BIG-IP e DHCP

Neste exemplo, mostramos como criar um cluster de usuário com o balanceador de carga F5 BIG-IP e usar o servidor DHCP para receber endereços IP para os nós do cluster.

Só é possível usar o F5 para o cluster de usuário se o cluster de administrador estiver usando o F5. Não se esqueça de instalar e configurar o ADC F5 BIG-IP antes da integração com o GKE no VMware. Consulte o Guia de instalação do ADC F5 BIG-IP para mais informações. O nome de usuário e a senha F5 são herdados do cluster de administrador.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --f5-config-address=F5_CONFIG_ADDRESS \
  --f5-config-partition=F5_CONFIG_PARTITION \
  --f5-config-snat-pool=F5_CONFIG_SNAT_POOL \
  --control-plane-vipCONTROL_PLANE_VIP \
  --ingress-vip=INGRESS_VIP \
  --enable-dhcp

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 sinalização --admin-cluster-membership, é possível usar o nome de cluster totalmente especificado, que tem o seguinte formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Outra opção é definir --admin-cluster-membership como o nome do cluster de administrador, como no comando de exemplo. Quando você usar apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com o --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 Fleet (gkehub.googleapis.com) e o serviço 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 onde os itens a seguir são armazenados:
- Os metadados do cluster de usuário 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 Anthos Service Mesh, precisa instalar a versão 1.19.3 ou mais recente. Isso é necessário porque os serviços Fleet e Connect são executados em uma região.
VERSION: a versão do GKE no VMware 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 controle de acesso com base em papéis (RBAC) do Kubernetes ao cluster para conceder a você e 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

F5_CONFIG_ADDRESS: o endereço do balanceador de carga F5 BIG-IP.
F5_CONFIG_PARTITION: o nome de uma partição BIG-IP que você criou para o cluster de administrador.
F5_CONFIG_SNAT_POOL: o nome do pool de SNAT, se aplicável

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.

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 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. Em GKE no VMware, 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.

gcloud container vmware clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-node-port=CONTROL_PLANE_NODE_PORT \
  --ingress-vip=INGRESS_VIP \
  --ingress-http-node-port=INGRESS_HTTP_NODE_PORT \
  --ingress-https-node-port=INGRESS_HTTPS_NODE_PORT \
  --konnectivity-server-node-port=KONNECTIVITY_SERVER_NODE_PORT

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 sinalização --admin-cluster-membership, é possível usar o nome de cluster totalmente especificado, que tem o seguinte formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
Outra opção é definir --admin-cluster-membership como o nome do cluster de administrador, como no comando de exemplo. Quando você usar apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com o --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 Fleet (gkehub.googleapis.com) e o serviço 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 onde os itens a seguir são armazenados:
- Os metadados do cluster de usuário 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 Anthos Service Mesh, precisa instalar a versão 1.19.3 ou mais recente. Isso é necessário porque os serviços Fleet e Connect são executados em uma região.
VERSION: a versão do GKE no VMware 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 controle de acesso com base em papéis (RBAC) do Kubernetes ao cluster para conceder a você e 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
CONTROL_PLANE_NODE_PORT: um valor nodePort para o servidor da API Kubernetes.
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
INGRESS_HTTPS_NODE_PORT: um valor de nodePort do tráfego HTTPS para o proxy de entrada
KONNECTIVITY_SERVER_NODE_PORT: um valor de nodePort do servidor Konnectivity

--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 GKE no VMware 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.
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.
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.

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

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: se você quiser ativar o Controlplane V2, inclua --enable-control-plane-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. Por padrão, o plano de controle de um cluster de usuário é executado em um ou mais nós no cluster de administrador (chamado de modelo kubeception). Quando o Controlplane V2 está ativado, os valores de --cpus e --memory 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 inseridos em --control-plane-ip-block. Quando o plano de controle V2 não está ativado, os valores de --cpus, --memory e --replicas se aplicam aos nós do plano de controle no cluster de administrador. Reserve endereços IP suficientes para o cluster de administrador.

Se você ativar o Controlplane V2, também precisará especificar as seguintes sinalizações:
- --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.
  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.
  
  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.

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.

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 Anthos.

Criar 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: o local 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 para cada nó do pool. O mínimo é de 40 GiB.
vCPUs: o número de CPUs de cada nó no pool de nós. O mínimo é 4.
MEMORY: o tamanho da memória em mebibytes (MiB) de cada nó no pool. O mínimo é 8.192 MiB por nó de trabalho de 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.

Terraform

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.

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

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ê.

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 é executada. 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.
- on_prem_version: a versão do GKE no VMware 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 papéis (RBAC) do Kubernetes ao cluster para conceder aos 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. 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 Anthos.

conecte-se ao cluster de usuário

Ao criar um cluster de usuário usando um cliente da API GKE On-Prem, é possível adicionar você e outros usuários como facilitadores de cluster especificando endereços de e-mail da conta do Google Cloud:

No console, seu endereço de e-mail é adicionado automaticamente na página Princípios básicos do cluster, na seção Autorização, e você tem a opção de adicionar outro usuário administrador de cluster.
Com a CLI gcloud, inclua a flag --admin-users definida para seu endereço de e-mail. A flag não aceita uma lista. Adicione a sinalização --admin-users para cada usuário administrador de cluster.
Com a amostra do Terraform, é possível especificar você e outros usuários administradores na variável admin_user_emails no arquivo terraform.tvars.sample.

O cluster é configurado com as políticas de controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes que concedem aos usuários administradores o papel cluster-admin e permitem que eles façam login no cluster a partir do console usando a identidade do Google Cloud. Para mais informações, consulte Configurar a autenticação de identidade do Google.

Todos os clusters têm um endpoint canônico. O endpoint expõe o servidor da API Kubernetes que kubectl e outros serviços usam para se comunicar com o plano de controle do cluster pela porta TCP 443. Esse endpoint não pode ser acessado na Internet pública. Se você tiver acesso ao endpoint particular do cluster por meio da VPC, poderá se conectar diretamente ao endpoint particular e gerar um arquivo kubeconfig diretamente. Caso contrário, use o gateway do Connect. Nesse caso, kubectl usa o Connect, que encaminha o tráfego para o endpoint particular em seu nome com segurança.

Para acessar o cluster de usuário pela linha de comando, você precisa de um arquivo kubeconfig. Há duas maneiras de gerar um arquivo kubeconfig:

Use o gateway do Connect para acessar o cluster em um computador que tenha a CLI do Google Cloud instalada. O gateway do Connect permite gerenciar seus clusters com facilidade e segurança. Para mais informações, consulte Como se conectar a clusters registrados com o gateway do Connect.
Para acesso direto a endpoints particulares, crie um arquivo kubeconfig na estação de trabalho do administrador e gerencie o cluster.

Aguarde até que o console indique que o status do cluster de usuário está íntegro.

Conectar gateway

initialize a CLI gcloud para uso com o projeto host da frota ou execute os seguintes comandos para fazer login com sua Conta do Google, defina o projeto host da frota como o padrão e atualize os componentes:
```
gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update
```
Busque as credenciais de cluster usadas para interagir com o gateway do Connect. No comando a seguir, substitua MEMBERSHIP_NAME pelo nome do seu cluster. No GKE no VMware, o nome da assinatura é o mesmo do cluster.
```
gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
```
Esse comando retorna um Conectar-se específico ao gatewaykubeconfig especial que permite a conexão com o cluster por meio do gateway.

Depois de ter as credenciais necessárias, é possível executar comandos usando kubectl normalmente para qualquer cluster do Kubernetes. Não é necessário especificar o nome do arquivo kubeconfig, por exemplo:
```
kubectl get namespaces
```

Estação de trabalho do administrador

Para criar o arquivo kubeconfig do cluster de usuário na estação de trabalho de administrador, execute o comando a seguir para salvar um novo arquivo kubeconfig para o cluster de usuário localmente. Substitua:

CLUSTER_NAME: o nome do cluster de usuário recém-criado
ADMIN_CLUSTER_KUBECONFIG especifica o caminho até o arquivo kubeconfig do cluster de administrador;
USER_CLUSTER_KUBECONFIG: o nome do arquivo kubeconfig do cluster de usuário gerado pelo comando

kubectl get secret admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  -n CLUSTER_NAME \
  -o=jsonpath='{.data.admin\.conf}' | base64 -d > USER_CLUSTER_KUBECONFIG

Depois de salvar o arquivo, comece a acessar o cluster de usuário usando kubectl na estação de trabalho de administrador, por exemplo:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get namespaces

Instalar uma versão posterior à versão do cluster de administrador

Um cluster de administrador pode gerenciar clusters de usuários em diferentes versões. 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:

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 \
    --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.
- REGION: a região do Google Cloud em que a API GKE On-Prem é executada. Essa é a região que você especificará ao criar o cluster de usuário. 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 instaladas no cluster de administrador são anotadas com isInstalled=true.
Se você ainda não tiver feito isso, registre o cluster de administrador na API GKE On-Prem. Depois que o cluster for registrado na API GKE On-Prem, não será necessário fazer esta etapa novamente.
Faça o download da nova versão dos componentes e implante-os no cluster de administrador:
```
gcloud beta vmware admin-clusters update ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID \
    --location=REGION \
    --required-platform-version=VERSION
```
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.

Criar um cluster de usuário com clientes da API GKE On-Prem

O que é a API GKE On-Prem?

Antes de começar

Conceder permissões do IAM

Registrar o cluster de administrador

Ativar os registros de auditoria de atividade do administrador no cluster de administrador

Ativar a geração de registros e o monitoramento no nível do sistema para o cluster de administrador

APIs do Google obrigatórias

Acesso à linha de comando

Versões disponíveis para novas instalações

Escolher uma ferramenta para criar o cluster

Criar um cluster de usuário

Console

Noções básicas sobre clusters

Plano de controle

Rede

Balanceador de carga

Empacotado com MetalLB

Balanceador de carga F5 Big-IP

Balanceador de carga manual

Recursos

Pools de nós

CLI da gcloud

Antes de começar

Examples

MetalLB e DHCP

MetalLB e IPs estáticos

F5 BIG-IP e DHCP

LB manual e IPs estáticos

Flags do plano de controle

Flags do vSphere

Criar um pool de nós

Terraform

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

conecte-se ao cluster de usuário

Conectar gateway

Estação de trabalho do administrador

Instalar uma versão posterior à versão do cluster de administrador

A seguir

Definir variáveis em `terraform.tfvars`

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