Crie um cluster de administrador com clientes da API GKE On-Prem

Esta página descreve como criar um cluster de administrador através da Google Cloud consola ou da CLI Google Cloud (CLI gcloud). Ambos os clientes padrão Google Cloud usam a API GKE On-Prem para criar o cluster.

O que é a API GKE On-Prem?

A API GKE On-Prem é uma API alojada na Google Cloud que lhe permite gerir o ciclo de vida dos seus clusters no local através do Terraform e de aplicações padrão da Google Cloud. Google CloudGoogle Cloud A API GKE On-Prem é executada na infraestrutura da Google. Google CloudO Terraform, a consola e a CLI gcloud são clientes da API e usam a API para criar clusters no seu centro de dados.

Para gerir o ciclo de vida dos seus clusters, a API GKE On-Prem tem de armazenar metadados sobre o estado do seu cluster em Google Cloud, usando a região que especifica quando cria o cluster.Google Cloud Estes metadados permitem à API gerir o ciclo de vida do cluster e não incluem dados específicos da carga de trabalho.

Quando cria um cluster através de um cliente da API GKE On-Prem, especifica um Google Cloud projeto. Após a criação, o cluster é automaticamente registado na frota do projeto especificado. Este projeto é denominado projeto anfitrião da frota. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.

Se preferir, pode criar um cluster de administrador criando um ficheiro de configuração do cluster de administrador e usando bmctl, conforme descrito no artigo Criar um cluster de administrador.

Se quiser usar a consola ou a CLI gcloud para gerir o ciclo de vida dos clusters criados com o bmctl, consulte Configure clusters to be managed by the GKE On-Prem API (Configure clusters to be managed by the GKE On-Prem API).

Autorizações de IAM

Se não for o Google Cloud proprietário do projeto, tem de pedir ao proprietário do projeto que lhe atribua as seguintes funções:

Se quiser aceder às páginas do Google Kubernetes Engine na consola, também tem de ter roles/container.viewer.

Para obter informações sobre como conceder as funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Acesso à linha de comandos

Depois de criar o cluster, se quiser usar o gateway de ligação para executar comandos kubectl no cluster em computadores que não sejam a estação de trabalho de administração, instale as seguintes ferramentas de linha de comandos no computador que planeia usar.

  • A versão mais recente da CLI gcloud.

  • kubectl para executar comandos em clusters do Kubernetes. Se precisar de instalar o kubectl, siga estas instruções.

Escolha o cliente para criar o cluster de administrador

Pode usar a consola ou a CLI gcloud para criar um cluster de administrador gerido pela API GKE On-Prem. Se for a primeira vez que instala o Google Distributed Cloud (apenas software) em hardware não processado, pode achar a consola mais fácil de usar do que a CLI gcloud.

Depois de se familiarizar mais com as informações que tem de fornecer para criar clusters, pode considerar a CLI gcloud mais conveniente, porque pode guardar o comando com os respetivos argumentos num ficheiro de texto. Se estiver a usar uma ferramenta de CI/CD, como o Cloud Build, pode usar os comandos gcloud para criar um cluster e especificar a flag --impersonate-service-account para automatizar a criação.

Pré-requisitos

Consola

  1. Na consola, aceda à página Criar um cluster bare metal.

    Aceda a Crie um cluster bare metal

  2. Selecione o Google Cloud projeto no qual quer criar o cluster. O projeto selecionado também é usado como o projeto anfitrião da frota.

A página Pré-requisitos apresenta os requisitos para a estação de trabalho do administrador e as máquinas dos nós do cluster. O planeador de endereços IP na secção Requisitos de rede ajuda a planear os endereços IP necessários para uma instalação mínima de um cluster de administrador e um cluster de utilizador.

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

Expanda esta secção para apresentar os requisitos de hardware, sistema operativo e conectividade para a sua estação de trabalho de administração.

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

Expanda esta secção para apresentar os requisitos de hardware, sistema operativo e conectividade para as máquinas de nós do cluster.

Requisitos de rede

Esta secção ajuda a planear os endereços IP de que precisa para um ambiente mínimo. Opcionalmente, na secção Endereços IP do nó e IP virtual, pode indicar um endereço IP do nó inicial e um endereço IP virtual (VIP), e a consola apresenta uma tabela de endereços IP de que precisa. Estes endereços IP não são aplicados à configuração do cluster de administrador. Destinam-se a ser um guia para ajudar a planear os endereços IP de que precisa para a sua instalação. Pode transferir a tabela para um ficheiro CSV e importá-la para uma folha de cálculo ou uma ferramenta de planeamento de endereços IP para usar como ponto de partida para acompanhar os endereços IP necessários para os seus clusters.

Reveja os recursos do Google Cloud:

Certifique-se de que todas as APIs Google necessárias estão ativadas no projeto anfitrião da frota. Além disso, tem de 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 do projeto anfitrião da frota.

Antes de criar o cluster, execute o comando bmctl register bootstrap na estação de trabalho do administrador, conforme descrito em Prepare o ambiente de arranque. Este comando pode criar as contas de serviço necessárias com as autorizações do IAM necessárias para criar o cluster de administrador. Se preferir, pode configurar manualmente as contas de serviço.

Quando tiver tudo pronto para começar, clique em Instalar ambiente de arranque na barra de navegação do lado esquerdo.

CLI gcloud

Pré-requisitos de hardware, rede e sistema operativo

A criação de um cluster de administrador com um cliente da API GKE On-Prem requer os mesmos pré-requisitos de hardware, rede e sistema operativo que a criação do cluster com bmctl. Para mais detalhes, consulte os Pré-requisitos de instalação.

APIs Google necessárias

Certifique-se de que todas as APIs Google necessárias estão ativadas no projeto anfitrião da frota. Além disso, tem de 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 do projeto anfitrião da frota.

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

Antes de criar o cluster, execute o comando bmctl register bootstrap na estação de trabalho do administrador, conforme descrito em Prepare o ambiente de arranque. Este comando pode criar as contas de serviço necessárias com as autorizações do IAM necessárias para criar o cluster de administrador. Se preferir, pode configurar manualmente as contas de serviço.

Planeie endereços IP

Antes de criar o cluster de administrador, tem de planear os endereços IP dos seus clusters. Reveja o artigo Planeie os seus endereços IP para ver um exemplo de como atribuir endereços IP a um cluster de administrador de alta disponibilidade (HA) e a dois clusters de utilizadores de HA. Mesmo que use a CLI gcloud para criar o cluster de administrador, recomendamos que siga os passos da consola nesta secção para usar o planeador de endereços IP.

Prepare o ambiente de arranque

Antes de criar o cluster de administrador, tem de executar o comando bmctl register bootstrap na estação de trabalho de administrador. Este comando implementa um cluster do Kubernetes no Docker (kind) na estação de trabalho do administrador. Este cluster de bootstrap aloja os controladores do Kubernetes necessários para criar o cluster de administrador. Quando cria o cluster de administrador, os controladores no cluster de arranque aprovisionam nós, executam verificações prévias e registam o cluster de administrador na frota. O cluster de arranque é eliminado automaticamente após a criação bem-sucedida do cluster.

Consola

  1. Introduza um nome para o cluster de administrador. Tenha em atenção que o nome do cluster de arranque é derivado da adição de bootstrap- ao nome do cluster de administrador.

  2. Selecione a versão para o cluster de administrador.

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

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

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

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

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

  4. A consola apresenta os comandos que tem de executar na sua estação de trabalho de administrador. A ferramenta de linha de comandos bmctl tem de corresponder à versão do cluster que está a criar. Se já tiver transferido a versão aplicável do bmctl para a sua estação de trabalho de administrador, não precisa de a transferir novamente.

CLI gcloud

  1. Certifique-se de que atualiza os componentes:

    gcloud components update

  2. Execute o seguinte comando para iniciar sessão com a sua Conta Google:

    gcloud auth login

  3. Liste as versões de cluster bare metal disponíveis que pode instalar:

    A versão do bmctl que transfere para criar o ambiente de arranque tem de corresponder à versão que vai instalar no cluster de administrador.

    gcloud container bare-metal admin-clusters query-version-config \
  --location=REGION

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

Crie o cluster de arranque

Siga os passos abaixo na estação de trabalho de administração. Estes comandos são apresentados na consola.

  1. Defina as suas credenciais de utilizador como credenciais padrão da aplicação (ADC):

    gcloud auth application-default login

    Siga as instruções para selecionar a sua Conta Google para o ADC.

  2. Se necessário, transfira a ferramenta de linha de comandos 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 cluster bare metal que quer instalar. Se copiou o comando da consola, a versão já está no comando.

  3. Crie o cluster de arranque. Pode permitir que o bmctl crie as contas de serviço (CS) necessárias ou criar as contas de serviço e os ficheiros de chaves, e transmiti-los ao comando bmctl register bootstrap.

bmctl cria SAs

Use o seguinte comando se quiser que o bmctl crie as contas de serviço necessárias com as autorizações mínimas necessárias para criar o cluster de administrador. Este comando pressupõe que o bmctl está 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 o seguinte:

Se copiou o comando apresentado na consola, os seguintes campos já estão preenchidos.

  • ADMIN_CLUSTER_NAME: o nome do cluster de administrador.

  • FLEET_HOST_PROJECT_ID: o projeto no qual o cluster de administrador vai ser registado automaticamente após a criação do cluster.

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

Conta de serviço Finalidade Funções de IAM
anthos-baremetal-gcr O Google Distributed Cloud usa esta conta de serviço para transferir imagens de contentores do Artifact Registry. Nenhum
anthos-baremetal-connect O Connect Agent usa esta conta de serviço para manter uma ligação entre o seu cluster e o Google Cloud. roles/gkehub.connect
anthos-baremetal-register O Connect Agent usa esta conta de serviço para registar os seus clusters na Google Cloud frota. roles/gkehub.admin
anthos-baremetal-cloud-ops O agente do Stackdriver usa esta conta de serviço para exportar registos 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
roles/monitoring.viewer
roles/serviceusage.serviceUsageViewer
roles/kubernetesmetadata.publisher

Especifique ficheiros de chaves de SA

Se preferir, pode transmitir bmctl os ficheiros de chaves de contas de serviço que criou. O comando seguinte usa os nomes dos ficheiros de chaves em Configure as contas de serviço manualmente e pressupõe que bmctl e os ficheiros de chaves estão 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 o seguinte:

  • YOUR_PRIVATE_KEY: o caminho para a sua chave SSH privada. Criou a chave SSH quando configurou o acesso SSH de raiz aos nós.

  • ADMIN_CLUSTER_NAME: o nome do cluster de administrador.

  • FLEET_HOST_PROJECT_ID: o projeto no qual o cluster de administrador vai ser registado automaticamente após a criação do cluster.

As seguintes flags especificam o caminho para os ficheiros de chaves:

  • -gcr-service-account-key: o caminho para o ficheiro de chave da conta de serviço que extrai imagens de contentores (anthos-baremetal-gcr).

  • --gke-agent-service-account-key: o caminho para o ficheiro de chave da conta de serviço do agente do Connect (anthos-baremetal-connect).

  • --gke-register-service-account-key: o caminho para o ficheiro de chave da conta de serviço do agente Connect que regista o cluster na frota (anthos-baremetal-register).

  • --cloud-operation-service-account-key: o caminho para o ficheiro de chave da conta de serviço para auditar registos e monitorizar projetos (anthos-baremetal-cloud-ops).

Depois de bmctl criar com êxito o cluster de arranque, é apresentado um resultado semelhante ao seguinte:

[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

Consola

  1. Na página Instalar ambiente de arranque, clique em Verificar ligação.

    Se for bem-sucedida, a consola apresenta a mensagem Ligação estabelecida.

    A ligação ao cluster de arranque tem de ser estabelecida antes de continuar. Se a ligação não for estabelecida, verifique os argumentos que especificou no comando bmctl register bootstrap:

    • Certifique-se de que o valor de --target-cluster-name corresponde ao nome do cluster de administrador apresentado na secção Noções básicas do ambiente de arranque.

    • Certifique-se de que o valor de --project-id corresponde ao ID do projeto que selecionou na consola.

    Se precisar de alterar o nome do cluster de arranque ou o ID do projeto, introduza Ctrl-C para sair de bmctl register bootstrap e voltar a executar o comando.

  2. Clique em Seguinte para começar a configurar o cluster de administrador. A maioria das definições na consola corresponde aos campos no ficheiro de configuração do cluster.

  3. Em Configuração do nó, introduza um valor entre 64 e 250 em Máximo de agrupamentos por nó ou aceite o valor predefinido, 110. Depois de criar o cluster, não pode atualizar este valor.

    O número máximo de pods por nó (denominado densidade de pods) também é limitado pelos recursos de IP disponíveis do cluster. Para ver detalhes, consulte o artigo Redes de pods.

  4. Clicar em Seguinte.

  5. Na página Redes, defina como os seus nós e componentes no cluster comunicam entre si e com o plano de controlo do Kubernetes.

    Para ver informações detalhadas, mantenha o ponteiro sobre o ícone junto a cada campo.

  6. Clique em Validar e criar.

    A consola apresenta mensagens de estado à medida que valida as definições e cria o cluster no seu centro de dados.

    Se existir um problema com a configuração, a consola apresenta uma mensagem de erro que deve ser suficientemente clara para corrigir o problema de configuração e tentar novamente criar o cluster.

CLI gcloud

Antes de criar o cluster de administrador, confirme que o cluster de arranque foi registado como membro da frota:

gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

Se o cluster de arranque não estiver listado, verifique o nome do cluster de arranque e o ID do projeto que especificou para bmctl register bootstrap. Se precisar de alterar o nome do cluster de arranque ou o ID do projeto, introduza Ctrl-C para sair de bmctl register bootstrap e execute novamente o comando.

Use o seguinte comando para criar um cluster de administrador:

gcloud container bare-metal admin-clusters create

A maioria das flags que especifica para o comando corresponde aos campos no ficheiro de configuração do cluster de utilizadores.

Para criar um cluster de administrador com o balanceador de carga integrado:

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 quiser usar o equilíbrio de carga manual, adicione --enable-manual-lb ao comando.

Substitua o seguinte:

  • ADMIN_CLUSTER_NAME: o nome do cluster de administrador. Não é possível alterar o nome após a criação do cluster.

  • FLEET_HOST_PROJECT_ID: o projeto no qual o cluster de administrador vai ser registado automaticamente após a criação do cluster. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.

  • REGION: A Google Cloud região em que a API GKE On-Prem é executada. Especifique us-west1 ou outra região suportada. Não é possível alterar a região após a criação do cluster. Esta definição especifica a região onde os seguintes elementos são armazenados:

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

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

  • VERSION: a versão do cluster bare metal. A versão tem de corresponder à versão do bmctl que usou para executar o bmctl register bootstrap. Pode verificar a versão do bmctl executando bmctl version na estação de trabalho do administrador.

  • MAX_PODS_PER_NODE : para clusters de administração, os valores permitidos são 32 a 250 e 64 a 250 para clusters não HA. O valor predefinido se --max-pods-per-node não estiver incluído no comando é 110. Depois de criar o cluster, não é possível atualizar este valor.

    O número máximo de pods por nó (denominado densidade de pods) também é limitado pelos recursos de IP disponíveis do cluster. Para ver detalhes, consulte o artigo Redes de pods.

  • CONTROL_PLANE_VIP: o IP virtual (VIP) no balanceador de carga para o servidor da API Kubernetes do cluster. Inclua o VIP do plano de controlo na mesma sub-rede que os nós do equilibrador de carga. Não inclua o VIP do plano de controlo nos conjuntos de endereços do equilibrador de carga.

  • CONTROL_PLANE_LOAD_BALANCER_PORT: a porta na qual o balanceador de carga serve o plano de controlo. Embora possa configurar outro valor, a porta 443 é a porta padrão usada para ligações HTTPS.

  • CONTROL_PLANE_NODE_CONFIG: O endereço IPv4 de um nó do plano de controlo. Os nós do plano de controlo executam a carga de trabalho do sistema. Especifique esta flag para cada nó do plano de controlo. Normalmente, tem uma única máquina se usar uma implementação mínima ou três máquinas se usar uma implementação de alta disponibilidade (HA). Especifique um número ímpar de nós para ter um quórum maioritário para a HA. Pode alterar estas moradas sempre que atualizar ou atualizar o 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 controlo. Pode especificar apenas um node-ip por indicação. Se precisar de especificar mais do que um nó, inclua novamente a flag para cada nó.

    • labels: um ou mais pares chave=valor anexados ao nó.

    Tenha em atenção as seguintes regras de sintaxe:

    • Coloque todo o valor entre aspas simples.
    • Não são permitidos espaços em branco.
    • Separe cada par chave=valor no segmento labels com um ponto e vírgula.

    Por 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 seu cluster. O intervalo CIDR tem de estar entre /24 e /12, em que /12 fornece o maior número de endereços IP. Recomendamos que use um intervalo no espaço de endereço IP para redes privadas, definido na RFC 1918, por exemplo, 10.96.0.0/20.

  • POD_ADDR_CIDR: Um intervalo de endereços IPv4, no formato CIDR, a usar para os pods no cluster de utilizadores. O intervalo CIDR tem de estar entre /18 e /8, em que /8 fornece o maior número de endereços IP. Recomendamos que use um intervalo no espaço de endereço IP para redes privadas, definido na RFC 1918, por exemplo, 192.168.0.0/16.

Tem de especificar as seguintes flags de armazenamento. O comando de exemplo inclui valores típicos. Para mais informações, consulte o artigo Configure o armazenamento local.

  • --lvp-share-path: este é o caminho da máquina anfitriã onde é possível criar subdiretórios. É criado um PersistentVolume (PV) local para cada subdiretório.

  • --lvp-share-storage-class: esta é a StorageClass a usar para criar volumes persistentes. A StorageClass é criada durante a criação do cluster.

  • --lvp-node-mounts-config-path: este é o caminho da máquina anfitriã onde é possível descobrir discos montados. É criado um PersistentVolume (PV) local para cada montagem.

  • --lvp-node-mounts-config-storage: a classe de armazenamento com que os PVs são criados durante a criação do cluster.

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

O resultado do comando é semelhante ao seguinte:

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

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

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

Para mais informações, consulte o artigo Operações bare-metal do gcloud container.

Corrija erros de pré-publicação

Antes de criar o cluster, o bmctl executa uma série de verificações prévias para validar a configuração. Se existir um problema com a configuração, o comando gcloud ... create termina com um erro semelhante ao seguinte:

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 prévia falhou porque não foi possível alcançar o nó do plano de controlo. Na estação de trabalho do administrador, vai 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

  1. Na estação de trabalho de administração, certifique-se de que o bmctl register bootstrap processo ainda está em execução. Caso contrário, volte a executar o comando com os mesmos argumentos e adicione a flag --reuse-bootstrap-cluster=true.

  2. 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 o artigo gcloud container bare-metal admin-clusters update.

Os detalhes sobre o processo de criação de clusters são apresentados na estação de trabalho do administrador. Se as verificações pré-voo forem aprovadas, é apresentado algo semelhante ao seguinte:

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

Ligue-se ao cluster de administrador

O comando bmctl register bootstrap cria um ficheiro kubeconfig para o cluster de administração na sua estação de trabalho de administração. O diretório onde o ficheiro kubeconfig está localizado e o nome do ficheiro baseiam-se no nome do cluster de administrador da seguinte forma:

bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

Tem de restringir o acesso a este kubeconfig porque contém credenciais de autenticação para o cluster.

Se quiser usar a sua identidade Google para iniciar sessão no cluster, pode configurar o gateway de ligação da seguinte forma:

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

  2. Defina o contexto atual numa variável de ambiente:

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

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

    • Concede à sua conta de utilizador a função do Kubernetes no cluster.clusterrole/view
    • Configura o cluster para que possa executar comandos kubectl só de leitura no seu computador local sem ter de usar SSH na estação de trabalho de administração.

    Substitua GOOGLE_ACCOUNT_EMAIL pelo endereço de email associado à sua conta 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

    O resultado deste comando é semelhante ao seguinte, que é truncado 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 estas políticas de RBAC implementadas, pode iniciar sessão no cluster a partir da consola com a sua identidade Google. Além disso, pode executar comandos de kubectlapenas leitura em computadores que não sejam a estação de trabalho do administrador através de um kubeconfig especial que encaminha pedidos através do gateway de ligação.

  1. Execute o seguinte comando num computador que não seja a estação de trabalho de administrador para obter a entrada kubeconfig que pode aceder ao cluster através do gateway de ligação.

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

    O resultado é semelhante ao seguinte:

    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.

  2. Agora, pode executar comandos kubectl através do gateway de ligação:

    kubectl get pods -A

O que se segue?