Criar um cluster de administrador usando clientes da API Anthos 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 Anthos On-Prem para criar o cluster.

O que é a API Anthos On-Prem?

A API Anthos On-Prem é uma API hospedada no Google Cloud que permite gerenciar o ciclo de vida dos clusters no local usando aplicativos padrão do Google Cloud e Terraform. A API Anthos 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 Anthos 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 da carga de trabalho.

Ao criar um cluster usando um cliente da API Anthos 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 de cluster de administrador e usando bmctl, conforme descrito em Como criar um cluster de administrador.

Se você quiser usar o console ou a CLI gcloud para gerenciar o ciclo de vida dos clusters que foram criados usando bmctl, consulte Configurar clusters para serem gerenciados pela API Anthos 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 Anthos e do Google Kubernetes Engine no console, também precisará ter 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 CLI gcloud para criar um cluster de administrador gerenciado pela API Anthos On-Prem. Se esta for a primeira vez que você instala clusters do Anthos em bare metal, talvez ache o console mais fácil de usar do que a CLI gcloud.

Depois de se familiarizar com as informações necessárias para criar os clusters, a CLI gcloud 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

  1. No console do Google Cloud, acesse a página Clusters do Anthos.

    Acesse a página de clusters do Anthos

  2. Selecione o projeto do Google Cloud em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota.

  3. Clique em Criar cluster.

  4. Na caixa de diálogo, clique em No local.

  5. Ao lado de Bare Metal, clique em Configurar. Verifique se Criar um cluster de administrador está selecionado.

A página Pré-requisitos exibe os requisitos para a estação de trabalho do administrador e as 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 Anthos 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.

CLI gcloud

Pré-requisitos de hardware, rede e sistema operacional

A criação de um cluster de administrador usando um cliente da API Anthos On-Prem requer os mesmos pré-requisitos de hardware, rede e sistema operacional que a criação do cluster usando bmctl. Para detalhes, consulte 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 Anthos 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

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.

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

  1. Digite um Nome para o cluster de administrador. Observe que o nome do cluster de inicialização é derivado adicionando o prefixo bootstrap- ao nome do cluster de administrador.

  2. Selecione a versão dos clusters do Anthos em bare metal para o cluster de administrador.

  3. No campo Local da API Google Cloud, selecione a região do Google Cloud na lista. Essa configuração especifica a região em que a API Anthos On-Prem é executada e a região em que os itens a seguir são armazenados:

    • Os metadados do cluster de que a API Anthos 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.

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

CLI gcloud

  1. Verifique se você tem a versão mais recente da CLI gcloud, incluindo os componentes beta da CLI gcloud.

  2. Se você ainda não tiver os componentes beta, execute o seguinte comando para instalá-los:

    gcloud components install beta

  3. Atualize os componentes da CLI gcloud, se necessário:

    gcloud components update

  4. Execute este comando para fazer login com sua Conta do Google:

    gcloud auth login

  5. Liste as versões disponíveis dos clusters do Anthos em bare metal que podem ser instaladas. A versão bmctl que você transfere por download para criar o ambiente de inicialização precisa corresponder à versão que você instalará no cluster de administrador.

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

    Substitua REGION pela região do Google Cloud em que a API Anthos On-Prem é executada. 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.

  1. Defina suas credenciais de usuário como Application Default Credentials (ADC):

    gcloud auth application-default login

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

  2. Se necessário, faça o download da ferramenta de linha de comando bmctl para o diretório de trabalho atual.

    gsutil cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl .
chmod a+x ./bmctl

    Substitua VERSION pela versão dos clusters do Anthos em bare metal que você quer instalar. Se você copiou o comando do console, a versão já está no comando.

  3. 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 \
  --name=bootstrap-ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID

Substitua:

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. O formato do nome do cluster de inicialização precisa ser bootstrap-ADMIN_CLUSTER_NAME.

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

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 Objetivo Papéis do IAM
anthos-baremetal-gcr O Anthos em bare metal usa esta conta de serviço para fazer o download de 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 e pressupõe que bmctl e os arquivos de chave estejam no diretório de trabalho atual.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --name=bootstrap-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. O formato do nome do cluster de inicialização precisa ser bootstrap-ADMIN_CLUSTER_NAME.

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

As flags a seguir especificam o caminho para os arquivos de chave:

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

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

  • --gke-register-service-account-key: o caminho para o 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 para o 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, você verá uma saída semelhante a 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

  1. 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 --name corresponde ao Nome de inicialização derivado exibido na seção Noções básicas 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.

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

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

  4. Clique em Próximo.

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

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

CLI gcloud

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

  • VERSION: a versão dos clusters do Anthos em bare metal. A versão precisa corresponder à versão 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, 172.26.232.0/24.

  • 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. Para saber mais, consulte 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 beta container bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

Para mais informações, consulte gcloud beta 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.alpha.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

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

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

    gcloud beta 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 beta 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 credenciais de autenticação para o cluster.

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

  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 em uma variável de ambiente:

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

  3. 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 a partir do console usando sua identidade do Google. Além disso, é possível executar comandos kubectl somente leitura em computadores diferentes da estação de trabalho de administrador usando um kubeconfig especial que encaminha solicitações por meio do gateway do Connect.

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

  2. Agora é possível executar comandos kubectl pelo gateway do Connect:

    kubectl get pods -A

A seguir