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

Criar um cluster de administrador usando clientes da API GKE On-Prem

Nesta página, descrevemos como criar um cluster de administrador usando o console do Google Cloud ou Google Cloud CLI (CLI gcloud). Esses dois clientes padrão do Google Cloud usam a API GKE On-Prem para criar o cluster.

O que é a API GKE On-Prem?

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

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 criar o cluster. Esses metadados permitem que a API gerencie o ciclo de vida do cluster e não incluem dados específicos de 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, crie um cluster de administrador criando um arquivo de configuração e usando bmctl, conforme descrito em Como criar um cluster de administrador.

Se você quiser usar o console ou a gcloud CLI para gerenciar o ciclo de vida de clusters criados com o bmctl, consulte Configurar clusters para serem gerenciados pela API GKE On-Prem.

Permissões do IAM

Se você não for um proprietário de projeto do Google Cloud, é necessário ter um proprietário de projeto para conceder a você os seguintes papéis:

Se você quiser acessar as páginas do GKE Enterprise e do GKE no console, também precisará ter o papel roles/container.viewer.

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

Acesso à linha de comando

Após a criação do cluster, se você quiser usar o gateway do Connect para executar comandos kubectl no cluster em computadores que não sejam a estação de trabalho do administrador, instale as ferramentas de linha de comando a seguir no computador que você planeja usar.

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

Escolha o cliente para criar o cluster de administrador

É possível usar o console ou a gcloud CLI para criar um cluster de administrador gerenciado pela API GKE On-Prem. Para quem está instalando o Google Distributed Cloud pela primeira vez, o console é mais fácil de usar do que a gcloud CLI.

Depois de se familiarizar com as informações necessárias para criar os clusters, a gcloud CLI pode se tornar mais conveniente, porque é possível salvar o comando com argumentos em um arquivo de texto. Se você estiver usando uma ferramenta de CI/CD, como o Cloud Build, poderá usar os comandos gcloud para criar um cluster e especificar a flag --impersonate-service-account para automatizar a criação.

Pré-requisitos

Console

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

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

A página Pré-requisitos mostra os requisitos da estação de trabalho do administrador e das máquinas de nós do cluster. O planejador de endereço IP na seção Requisitos de rede ajuda a planejar os endereços IP necessários para uma instalação mínima de um cluster de administrador e um cluster de usuário.

Pré-requisitos da estação de trabalho do administrador

Expanda esta seção para exibir os requisitos de hardware, sistema operacional e conectividade da estação de trabalho do administrador.

Pré-requisitos da máquina do nó do cluster

Expanda esta seção para exibir os requisitos de hardware, sistema operacional e conectividade das máquinas de nó do cluster.

Requisitos de rede

Esta seção ajuda você a planejar os endereços IP necessários para um ambiente mínimo. Opcionalmente, na seção Endereços IP de nó e IP virtual, é possível fornecer um endereço IP de nó inicial e um endereço IP virtual (VIP), e o console exibir uma tabela de endereços IP necessários. Esses endereços IP não são aplicados à configuração do cluster de administrador. Eles servem como um guia para ajudar você a planejar os endereços IP necessários para sua instalação. É possível fazer o download da tabela em um arquivo CSV e importá-la para uma planilha ou ferramenta de planejamento de endereços IP para usar como ponto de partida para acompanhar os endereços IP necessários para os clusters.

Confira os recursos do Google Cloud:

Verifique se todas as APIs do Google necessárias estão ativadas no projeto host da frota. Além disso, você precisa ativar a API GKE On-Prem:

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

Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto host da frota.

Antes de criar o cluster, execute o comando bmctl register bootstrap na estação de trabalho do administrador, conforme descrito em Preparar o ambiente de inicialização. Esse comando pode criar as contas de serviço necessárias com as permissões mínimas necessárias do IAM para criar o cluster de administrador. Se preferir, configure as contas de serviço manualmente.

Quando estiver pronto para começar, clique em Instalar ambiente de inicialização na barra de navegação à esquerda.

gcloud CLI

Pré-requisitos de hardware, rede e sistema operacional

Para criar um cluster de administrador com um cliente da API GKE On-Prem, os pré-requisitos de hardware, rede e sistema operacional são os mesmos da criação com o bmctl. Saiba mais em Pré-requisitos de instalação.

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, você precisa ativar a API GKE On-Prem:

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

Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto host da frota.

Contas de serviço e permissões necessárias

Planejar endereços IP

Antes de criar o cluster de administrador, você precisa planejar os endereços IP dos clusters. Consulte Planejar seus endereços IP para ter um exemplo de como alocar endereços IP para um cluster de administrador de alta disponibilidade (HA, na sigla em inglês) e dois clusters de usuário de alta disponibilidade. Mesmo que você use a CLI gcloud para criar o cluster de administrador, é recomendado seguir as etapas do console nesta seção para usar o planejador de endereço IP.

Preparar o ambiente de inicialização

Antes de criar o cluster de administrador, você precisa executar o comando bmctl register bootstrap na estação de trabalho do administrador. Esse comando implanta um cluster do Kubernetes no Docker (tipo) na estação de trabalho do administrador. Esse cluster de inicialização hospeda os controladores do Kubernetes necessários para criar o cluster de administrador. Quando você cria o cluster de administrador, os controladores no cluster de inicialização provisionam os nós, executam verificações de simulação e registram o cluster de administrador na frota. O cluster de inicialização é excluído automaticamente após a criação dele.

Console

Digite um Nome para o cluster de administrador. Para gerar o nome do cluster de inicialização, o sistema adiciona o prefixo bootstrap- ao nome do cluster de administrador.
Selecione a versão do Google Distributed Cloud do cluster de administrador.
No campo Local da API do Google Cloud, 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 executados:
- API GKE On-Prem (gkeonprem.googleapis.com)
- Serviço de frota (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 que a API GKE On-Prem precisa para gerenciar o ciclo de vida do cluster
- Os dados do Cloud Logging e do Cloud Monitoring referentes aos 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.
O console exibe os comandos que você precisa executar na estação de trabalho do administrador. A ferramenta de linha de comando bmctl precisa corresponder à versão do cluster que você está criando. Se você já tiver feito o download da versão aplicável do bmctl na estação de trabalho do administrador, não será necessário fazer o download outra vez.

gcloud CLI

Atualize os componentes:
```
gcloud components update
```
Execute este comando para fazer login com sua Conta do Google:
```
gcloud auth login
```
Confira quais são as versões do Google Distributed Cloud disponíveis para instalação. A versão do bmctl baixada para criar o ambiente de inicialização precisa ser igual à versão instalada no cluster de administrador.
```
gcloud container bare-metal admin-clusters query-version-config \
  --location=REGION
```
Substitua REGION pela 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 de frota e Connect são executados. Especifique us-west1 ou outra região compatível.

Criar o cluster de inicialização

Execute as etapas a seguir na estação de trabalho do administrador. Esses comandos são exibidos no console.

Defina suas credenciais de usuário como Application Default Credentials (ADC, na sigla em inglês):
```
gcloud auth application-default login
```
Siga as instruções para selecionar sua Conta do Google para ADC.
Se necessário, baixe a ferramenta de linha de comando bmctl para o diretório de trabalho atual.
```
gcloud storage cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl .
chmod a+x ./bmctl
```
Substitua VERSION pela versão do Google Distributed Cloud que você quer instalar. Se você copiou o comando do console, a versão já está no comando.
Crie o cluster de inicialização. É possível permitir que bmctl crie as contas de serviço (SAs) necessárias ou criar as contas de serviço e os arquivos de chaves e transmiti-los para o comando bmctl register bootstrap.

`bmctl` cria SAs

Use o comando a seguir se quiser que bmctl crie as contas de serviço necessárias com as permissões mínimas necessárias para criar o cluster de administrador. Esse comando pressupõe que bmctl esteja no diretório de trabalho atual.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID

Substitua:

YOUR_PRIVATE_KEY: o caminho para sua chave SSH privada. Você criou a chave SSH ao configurar o acesso SSH raiz aos nós.

Se você copiou o comando exibido no console, os campos a seguir já estão preenchidos.

ADMIN_CLUSTER_NAME: o nome do cluster de administrador.
FLEET_HOST_PROJECT_ID: o projeto em que o cluster de administrador será registrado automaticamente após a criação.

O comando bmctl register bootstrap cria as contas de serviço a seguir. As chaves da conta de serviço são armazenadas no diretório bmctl-workspace/.sa-keys.

Conta de serviço	Finalidade	Papéis do IAM
anthos-baremetal-gcr	O Google Distributed Cloud usa essa conta de serviço para baixar imagens de contêiner do Google Container Registry.	Nenhum
anthos-baremetal-connect	O Agente do Connect usa esta conta de serviço para manter uma conexão entre o cluster e o Google Cloud.	roles/gkehub.connect
anthos-baremetal-register	O Agente do Connect usa essa conta de serviço para registrar os clusters na frota do Google Cloud.	roles/gkehub.admin
anthos-baremetal-cloud-ops	O Agente do Stackdriver usa essa conta de serviço para exportar registros e métricas de clusters para o Cloud Logging e o Cloud Monitoring.	roles/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor

Especificar arquivos de chave SA

Se preferir, transmita bmctl aos arquivos de chave da conta de serviço que você criou. O comando a seguir usa os nomes de arquivo de chave em Configurar contas de serviço manualmente. Para o comando funcionar, o bmctl e os arquivos de chave precisam estar no diretório de trabalho atual.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --target-cluster-name=ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID \
  --gcr-service-account-key=anthos-baremetal-gcr.json \
  --gke-agent-service-account-key=connect-agent.json \
  --gke-register-service-account-key=connect-register.json \
  --cloud-operation-service-account-key=anthos-baremetal-cloud-ops.json

Substitua:

YOUR_PRIVATE_KEY: o caminho para sua chave SSH privada. Você criou a chave SSH ao configurar o acesso SSH raiz aos nós.
ADMIN_CLUSTER_NAME: o nome do cluster de administrador.
FLEET_HOST_PROJECT_ID: o projeto em que o cluster de administrador será registrado automaticamente após a criação do cluster.

As flags abaixo especificam o caminho para os arquivos de chave:

-gcr-service-account-key: o caminho do arquivo de chave da conta de serviço que extrai imagens de contêiner (anthos-baremetal-gcr).
--gke-agent-service-account-key: o caminho do arquivo de chave da conta de serviço do Agente do Connect (anthos-baremetal-connect).
--gke-register-service-account-key: o caminho do arquivo de chave da conta de serviço do Agente do Connect que registra o cluster na frota (anthos-baremetal-register).
--cloud-operation-service-account-key: o caminho do arquivo de chave da conta de serviço para auditar registros e monitorar projetos (anthos-baremetal-cloud-ops).

Depois que bmctl criar o cluster de inicialização, será exibida uma saída como esta:

[2023-03-22 17:35:24+0000] Waiting for the temporary cluster to be registered... OK
[2023-03-22 17:35:37+0000] Please go to https://console.cloud.google.com/home/dashboard?project=example-project-12345 to create the cluster
[2023-03-22 17:35:37+0000] Waiting for preflight checks and cluster to run..

Crie o cluster de administrador

Console

Na página Instalar ambiente de inicialização, clique em Verificar conexão.

Se o processo for bem-sucedido, o console exibirá Conexão estabelecida.

A conexão com o cluster de inicialização precisa ser estabelecida antes de você continuar. Se a conexão não estiver estabelecida, verifique os argumentos especificados para o comando bmctl register bootstrap:
- Verifique se o valor de --target-cluster-name corresponde ao Nome do cluster de administrador exibido na seção Princípios básicos do ambiente de inicialização.
- Verifique se o valor de --project-id corresponde ao ID do projeto selecionado no console.
Se você precisar alterar o nome do cluster de inicialização ou o ID do projeto, insira Ctrl-C para sair de bmctl register bootstrap e execute o comando outra vez.
Clique em Próxima para começar a configurar o cluster de administrador. A maioria das configurações no console corresponde aos campos no arquivo de configuração do cluster.
Em Configuração do nó, insira um valor entre 64 e 250 em Máximo de pods por nó ou aceite o padrão, 110. Após a criação do cluster, não é possível atualizar esse valor.

O número máximo de pods por nó (chamado de densidade do pod) também é limitado pelos recursos de IP disponíveis no cluster. Para detalhes, consulte Rede de pod.
Clique em Próxima.
Na página Rede, defina como os nós e componentes no cluster se comunicam entre si e com o plano de controle do Kubernetes.

Para informações detalhadas, mantenha o ponteiro sobre ao lado de cada campo.
Clique em Verificar e criar.

O console exibe mensagens de status durante a verificação das configurações e a criação do cluster no data center.

Se houver um problema com a configuração, o console exibirá uma mensagem de erro que deve estar clara o suficiente para que você possa corrigi-lo e tente criar o cluster novamente.

gcloud CLI

Antes de criar o cluster de administrador, confirme se o cluster de inicialização foi registrado como membro da frota:

gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

Se o cluster de inicialização não estiver listado, verifique o nome dele e o ID do projeto especificado em bmctl register bootstrap. Se você precisar alterar o nome do cluster de inicialização ou o ID do projeto, insira Ctrl-C para sair de bmctl register bootstrap e execute o comando outra vez.

Use o seguinte comando para criar um cluster de administrador:

gcloud container bare-metal admin-clusters create

A maioria das flags especificadas para o comando corresponde aos campos no arquivo de configuração do cluster de usuário.

Para criar um cluster de administrador com o balanceador de carga em pacote, faça o seguinte:

gcloud container bare-metal admin-clusters create ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --version=VERSION \
  --max-pods-per-node=MAX_PODS_PER_NODE \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LOAD_BALANCER_PORT \
  --control-plane-node-configs 'CONTROL_PLANE_NODE_CONFIG' \
  --island-mode-service-address-cidr-blocks=SERVICE_ADDR_CIDR \
  --island-mode-pod-address-cidr-blocks=POD_ADDR_CIDR \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

Se você quiser usar o balanceamento de carga manual, adicione --enable-manual-lb ao comando.

Substitua:

ADMIN_CLUSTER_NAME: o nome do cluster de administrador. O nome não pode ser alterado após a criação do cluster.
FLEET_HOST_PROJECT_ID: o projeto em que o cluster de administrador será registrado automaticamente após a criação do cluster. 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. 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 que a API GKE On-Prem precisa para gerenciar o ciclo de vida do cluster
- Os dados do Cloud Logging e do Cloud Monitoring referentes aos 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.
VERSION: a versão do Google Distributed Cloud. A versão precisa ser igual à versão do bmctl usada para executar bmctl register bootstrap. Para verificar a versão do bmctl, execute bmctl version na estação de trabalho do administrador.
MAX_PODS_PER_NODE : para clusters de administrador, os valores permitidos são 32-250 e 64-250 para clusters não HA. O valor padrão se --max-pods-per-node não for incluído no comando será 110. Depois que o cluster for criado, esse valor não poderá ser atualizado.

O número máximo de pods por nó (chamado de densidade do pod) também é limitado pelos recursos de IP disponíveis do cluster. Para detalhes, consulte Rede de pod.
CONTROL_PLANE_VIP: o IP virtual (VIP) no balanceador de carga do servidor da API Kubernetes do cluster. Inclua o VIP do plano de controle na mesma sub-rede que os nós do balanceador de carga. Não inclua o VIP do plano de controle nos pools de endereços do balanceador de carga.
CONTROL_PLANE_LOAD_BALANCER_PORT: a porta em que o balanceador de carga exibe o plano de controle. Embora seja possível configurar outro valor, a porta 443 é a porta padrão usada para conexões HTTPS.
CONTROL_PLANE_NODE_CONFIG: o endereço IPv4 de um nó do plano de controle. Os nós do plano de controle executam a carga de trabalho do sistema. Especifique essa flag para cada nó do plano de controle. Normalmente, você tem uma única máquina, se estiver usando uma implantação mínima, ou três máquinas, se estiver usando uma implantação de alta disponibilidade (HA). Especifique um número ímpar de nós para poder ter uma maioria de quórum de alta disponibilidade. É possível alterar esses endereços sempre que atualizar ou fizer upgrade do cluster.

O valor da flag tem o seguinte formato:
```
'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
```
O valor tem segmentos que começam com as palavras-chave node-ip e labels.. Separe cada segmento com uma vírgula..
- node-ip: o endereço IP de um nó do plano de controle. É possível especificar apenas um node-ip por sinalização. Se você precisar especificar mais de um nó, inclua a sinalização novamente para cada nó.
- labels: um ou mais pares de chave-valor anexados ao nó.
Observe as seguintes regras de sintaxe::
- Coloque o valor inteiro entre aspas simples.
- Não é permitido usar espaços em branco.
- Separe cada par de chave-valor no segmento labels com um ponto e vírgula.
Exemplo:
```
--control-plane-node-configs 'node-ip=192.0.2.1' \
--control-plane-node-configs 'node-ip=192.0.2.2,labels=key2.1=value2.1' \
--control-plane-node-configs 'node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
```
SERVICE_ADDR_CIDR: um intervalo de endereços IPv4, no formato CIDR, para serviços no cluster. O intervalo CIDR precisa estar entre /24 e /12, em que /12 fornece mais endereços IP. Recomendamos que você use um intervalo no espaço de endereços IP para Internet particular, definido no RFC 1918, por exemplo, 10.96.0.0/20.
POD_ADDR_CIDR: um intervalo de endereços IPv4, no formato CIDR, a serem usados para pods no cluster de usuário. O intervalo CIDR precisa estar entre /18 e /8, sendo que /8 apresenta mais endereços IP. Recomendamos que você use um intervalo no espaço de endereços IP para Internet particular, definido no RFC 1918, por exemplo, 192.168.0.0/16.

Você precisa especificar as seguintes flags de armazenamento. O comando de exemplo inclui valores típicos. Saiba mais em Configurar o armazenamento local.

--lvp-share-path: é o caminho da máquina host em que os subdiretórios podem ser criados. Um PersistentVolume (PV) local é criado para cada subdiretório.
--lvp-share-storage-class: esse é o StorageClass a ser usado para criar volumes permanentes. O StorageClass é criado durante a criação do cluster.
--lvp-node-mounts-config-path: é o caminho da máquina host em que os discos montados podem ser descobertos. Um PersistentVolume (PV) local é criado para cada montagem.
--lvp-node-mounts-config-storage: a classe de armazenamento com a qual os PVs são criados durante a criação do cluster.

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

A saída deste comando terá esta aparência:

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 bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

Para mais informações, consulte gcloud container bare-metal operations.

Corrigir erros de simulação

Antes de criar o cluster, o bmctl executa uma série de verificações de simulação para conferir a configuração. Se houver um problema com a configuração, o comando gcloud ... create será encerrado com um erro semelhante a este:

ERROR: (gcloud.container.bare-metal.admin-clusters.create) Invalid resource state for "projects/694677185633/locations/us-west1/bareMetalAdminClusters/abm-cluster-1": cluster preflight checks failed

Por exemplo, suponha que uma verificação de simulação falhou porque não foi possível acessar o nó do plano de controle. Na estação de trabalho do administrador, você verá algo semelhante ao seguinte:

[2023-03-27 20:34:38+0000] Waiting for preflight check job to finish... OK
[2023-03-27 20:35:58+0000] - Validation Category: machines and network
[2023-03-27 20:35:58+0000]    - [PASSED] pod-cidr
[2023-03-27 20:35:58+0000]    - [FAILED] node-network (log: bmctl-workspace/log/register-bootstrap-20230327-201548/node-network)
[2023-03-27 20:35:58+0000]        - Failed to connect to the host via ssh: ssh: connect to host 10.100.0.5 port 22: Connection timed out
[2023-03-27 20:35:58+0000] Flushing logs... OK
[2023-03-27 20:35:58+0000] Error polling the preflight check abm-cluster-mar-27 in the cluster-abm-cluster-mar-27: preflight check failed

Na estação de trabalho do administrador, verifique se o processo bmctl register bootstrap ainda está em execução. Caso contrário, execute outra vez o comando com os mesmos argumentos e adicione a flag --reuse-bootstrap-cluster=true.

Execute gcloud ... update para corrigir o endereço IP inválido:

gcloud container bare-metal admin-clusters update ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --control-plane-node-configs 'node-ip=NEW_NODE_ID_ADDRESS'

Para mais informações, consulte gcloud container bare-metal admin-clusters update.

Os detalhes sobre o processo de criação do cluster são gerados na estação de trabalho do administrador. Se as verificações de simulação forem aprovadas, você verá algo como:

[2023-03-22 23:12:47+0000] Waiting for cluster kubeconfig to become ready OK
[2023-03-22 23:15:47+0000] Writing kubeconfig file
[2023-03-22 23:15:47+0000] kubeconfig of cluster being created is present at bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig
[2023-03-22 23:15:47+0000] Please restrict access to this file as it contains authentication credentials of your cluster.
[2023-03-22 23:15:47+0000] Waiting for cluster to become ready OK
[2023-03-22 23:20:17+0000] Please run
[2023-03-22 23:20:17+0000] kubectl --kubeconfig bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig get nodes
[2023-03-22 23:20:17+0000] to get cluster nodes status.
[2023-03-22 23:20:17+0000] Waiting for node pools to become ready OK
[2023-03-22 23:20:37+0000] Waiting for metrics to become ready in GCP OK
[2023-03-22 23:25:38+0000] Waiting for cluster API provider to install in the created admin cluster OK
[2023-03-22 23:25:48+0000] Moving admin cluster resources to the created admin cluster
[2023-03-22 23:25:51+0000] Waiting for node update jobs to finish OK
[2023-03-22 23:27:41+0000] Flushing logs... OK
[2023-03-22 23:27:41+0000] Deleting membership... OK
[2023-03-22 23:27:42+0000] Deleting bootstrap cluster.

Conectar-se ao cluster de administrador

O comando bmctl register bootstrap cria um arquivo kubeconfig para o cluster de administrador na estação de trabalho do administrador. O diretório em que kubeconfig está localizado e o nome do arquivo são baseados no nome do cluster de administrador da seguinte maneira:

bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

É necessário restringir o acesso a esse kubeconfig, porque ele contém as credenciais de autenticação do cluster.

Se você quiser usar sua identidade do Google para fazer login no cluster, configure o gateway do Connect da seguinte maneira:

Na estação de trabalho do administrador, defina a variável de ambiente KUBECONFIG:

export KUBECONFIG=$HOME/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

Defina o contexto atual em uma variável de ambiente:

export CONTEXT="$(kubectl config current-context)"

Execute o seguinte comando gcloud. Este comando faz o seguinte:

Concede à conta de usuário o papel clusterrole/view do Kubernetes no cluster.
Configura o cluster para que você possa executar os comandos kubectl somente leitura no computador local sem precisar executar o SSH na estação de trabalho do administrador.

Substitua GOOGLE_ACCOUNT_EMAIL pelo endereço de e-mail associado à sua conta do Google Cloud. Por exemplo, --users=alex@example.com.

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=ADMIN_CLUSTER_NAME \
    --role=clusterrole/view \
    --users=GOOGLE_ACCOUNT_EMAIL \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=$KUBECONFIG \
    --context=$CONTEXT\
    --apply

A saída desse comando é semelhante à seguinte, truncada para facilitar a leitura:

Validating input arguments.
Specified Cluster Role is: clusterrole/view
Generated RBAC policy is:
--------------------------------------------
...

Writing RBAC policy for user: GOOGLE_ACCOUNT_EMAIL to cluster.
Successfully applied the RBAC policy to cluster.

Com essas políticas de RBAC em vigor, você pode fazer login no cluster pelo console usando sua identidade do Google. Além disso, você pode executar comandos kubectl somente leitura em outros computadores além da estação de trabalho de administrador. Para isso, você usa um kubeconfig especial, que encaminha solicitações por meio do gateway do Connect.

Execute o comando a seguir em um computador que não seja a estação de trabalho de administrador para receber a entrada kubeconfig, que pode acessar o cluster por meio do gateway do Connect.

gcloud container fleet memberships get-credentials ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID

O resultado será assim:

Starting to build Gateway kubeconfig...
Current project_id: FLEET_HOST_PROJECT_ID
A new kubeconfig entry "connectgateway_FLEET_HOST_PROJECT_ID_global_ADMIN_CLUSTER_NAME" has been generated and set as the current context.

Agora é possível executar comandos kubectl pelo gateway de conexão:
```
kubectl get pods -A
```

Criar um cluster de administrador usando clientes da API GKE On-Prem

O que é a API GKE On-Prem?

Permissões do IAM

Acesso à linha de comando

Escolha o cliente para criar o cluster de administrador

Pré-requisitos

Console

gcloud CLI

Preparar o ambiente de inicialização

Console

gcloud CLI

Criar o cluster de inicialização

bmctl cria SAs

Especificar arquivos de chave SA

Crie o cluster de administrador

Console

gcloud CLI

Conectar-se ao cluster de administrador

A seguir

`bmctl` cria SAs