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

Esta página descreve como criar um cluster de utilizadores através da Google Cloud consola, da Google Cloud CLI (gcloud CLI) ou do Terraform.

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 utilizadores criando um ficheiro de configuração de cluster de utilizadores e usando bmctl, conforme descrito no artigo Criar um cluster de utilizadores.

Se quiser usar o Terraform, a consola ou a CLI gcloud para gerir o ciclo de vida dos clusters criados com o bmctl, consulte o artigo Configure um cluster de utilizador para ser gerido pela API GKE On-Prem.

Antes de começar

Esta secção descreve os requisitos para criar um cluster de utilizadores através de clientes da API GKE On-Prem.

Conceda autorizações de IAM

Se não for proprietário de um projeto, tem de ter roles/gkeonprem.admin.

Se quiser aceder às páginas do Google Kubernetes Engine na consola, também tem de ter as seguintes funções:

Após a criação do cluster, se não for proprietário do projeto e quiser usar o gateway de ligação para ligar-se ao cluster de utilizadores através da linha de comandos, são necessárias as seguintes funções:

  • roles/gkehub.gatewayAdmin: Esta função permite-lhe aceder à API Connect Gateway. Se só precisar de acesso de leitura ao cluster, o roles/gkehub.gatewayReader é suficiente.

  • roles/gkehub.viewer: esta função permite-lhe obter credenciais do cluster.

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.

APIs Google necessárias

Certifique-se de que todas as APIs Google necessárias estão ativadas no projeto anfitrião da frota.

Se usar a CLI gcloud para criar o cluster, tem de ativar a API GKE On-Prem. Se estiver a usar a consola para criar o cluster, esta ativa automaticamente a API GKE On-Prem.

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

Pré-requisitos do cluster de administrador

Precisa de um cluster de administrador funcional antes de poder criar um cluster de utilizador. O cluster de administrador tem de:

  • Ter acesso ao servidor da API Kubernetes no cluster de utilizadores após a sua criação.

  • Ter conetividade de rede a todos os nós no cluster de utilizadores após a sua criação.

  • Tem de estar registado numa frota. O ID do projeto configurado no campo gkeConnect.projectID do cluster de administrador, que é denominado projeto anfitrião da frota, tem de ser o mesmo projeto no qual vai criar o cluster de utilizadores.

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

Reveja os pré-requisitos da máquina do nó do cluster para se certificar de que as máquinas que vão executar o cluster de utilizadores cumprem os pré-requisitos.

Acesso à linha de comandos

Depois de criar o cluster, se quiser usar o gateway de ligação para executar o comando kubectl no cluster de utilizadores 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.

Crie um cluster de utilizadores

Pode usar o Terraform, a Google Cloud consola ou a CLI do Google Cloud (CLI gcloud) para criar um cluster gerido pela API GKE On-Prem. Se for a primeira vez que instala o Google Distributed Cloud, pode considerar a consola a ferramenta mais fácil de usar.

Depois de se familiarizar mais com as informações que tem de fornecer para criar clusters, pode achar o Terraform ou a CLI gcloud mais convenientes, especialmente se for criar mais do que um cluster. O Terraform é uma ferramenta de infraestrutura como código padrão da indústria. Se a sua organização já usar o Terraform, é provável que queira usá-lo para criar clusters e gerir o ciclo de vida do cluster.

Com a CLI gcloud, pode guardar o comando com os respetivos argumentos num ficheiro de texto e fazer alterações conforme necessário para criar clusters adicionais. Se estiver a usar uma ferramenta de CI/CD, como o Cloud Build, pode usar os comandos gcloud para criar um cluster e um conjunto de nós, e especificar a flag --impersonate-service-account para automatizar a criação.

Consola

A maioria das definições na consola corresponde aos campos no ficheiro de configuração do cluster.

  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. Tem de ser o mesmo projeto no qual o cluster de administrador está registado. Depois de criar o cluster de utilizadores, este é registado automaticamente na frota do projeto selecionado.

  3. Clique em Seguinte para começar a configurar o cluster.

As secções seguintes explicam como configurar o cluster de utilizadores.

Noções básicas sobre clusters

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

  1. Introduza um nome para o cluster de utilizadores.

  2. Em Cluster de administração, selecione o cluster de administração na lista.

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

  4. Selecione a versão para o cluster de utilizadores. Os clusters de utilizadores têm de ter a mesma versão secundária que o cluster de administrador ou uma versão secundária inferior à do cluster de administrador.

  5. Como criador do cluster, recebe privilégios de administrador do cluster para o cluster. Opcionalmente, introduza o endereço de email de outro utilizador que vai administrar o cluster no campo Utilizador administrador.

    Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para lhe conceder, bem como a outros utilizadores administradores, a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.

  6. Na secção Configuração do nó, especifique o seguinte:

    • Máximo de agrupamentos por nó: introduza o número máximo de agrupamentos que podem ser executados num único nó. Os valores permitidos estão entre 32 e 250, inclusive. O Kubernetes atribui um bloco Classless Inter-Domain Routing (CIDR) a cada nó para que cada pod possa ter um endereço IP único. O tamanho do bloco CIDR corresponde ao número máximo de pods por nó. Para mais informações sobre como definir o número máximo de pods por nó, consulte o artigo Redes de pods.

    • Tempo de execução do contentor: o containerd é o único tempo de execução do contentor disponível para o seu cluster.

  7. Clique em Seguinte para aceder à secção Rede.

Redes

Nesta secção, especifica os endereços IP dos nós, dos pods e dos serviços do cluster. Se estiver a usar o equilíbrio de carga integrado com o MetalLB, também tem de o configurar.

  1. Na secção do nó do plano de controlo, introduza o endereço IPv4 de cada nó do plano de controlo. Os nós do plano de controlo executam a carga de trabalho do sistema. Normalmente, trata-se de 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. Este campo pode ser alterado sempre que atualiza ou faz uma atualização de um cluster.

    Clique em + Adicionar endereço IP conforme necessário para introduzir mais endereços IP.

  2. Na secção Balanceador de carga, selecione o balanceador de carga na lista Modo para configurar para o seu cluster. Consulte a Vista geral dos balanceadores de carga para mais informações.

    Incluído no MetalLB

    Configure o balanceamento de carga com o balanceador de carga MetalLB integrado. Com esta opção, o Google Distributed Cloud implementa equilibradores de carga da camada 4 que são executados num conjunto dedicado de nós de trabalho ou nos mesmos nós que o plano de controlo.

    1. Na secção Load balancer node pools, selecione uma das seguintes opções:

      • Usar nós do plano de controlo: escolha esta opção para executar os balanceadores de carga nos mesmos nós que o plano de controlo.

      • Criar node pool do balanceador de carga: escolha esta opção avançada se precisar de executar os balanceadores de carga num pool dedicado de nós de trabalho. Todos os nós no conjunto de nós do equilibrador de carga têm de estar na mesma sub-rede da camada 2 que os IPs virtuais (VIPs) do equilibrador de carga que configura na secção Conjuntos de endereços do equilibrador de carga.

        1. No campo IP 1 do conjunto de nós do equilibrador de carga, introduza um endereço IPv4 para um nó no conjunto de nós do equilibrador de carga.

        2. Clique em + Adicionar endereço IP, conforme necessário, para introduzir endereços IP adicionais.

    2. Na secção Load balancer address pools, adicione um ou mais conjuntos de endereços para o controlador MetalLB escolher e atribuir a serviços do tipo LoadBalancer. O VIP de entrada, que especifica na secção IPs virtuais, tem de estar num destes conjuntos.

      1. Introduza um nome para o conjunto de endereços.

      2. Introduza um intervalo de endereços IP na notação CIDR (por exemplo: 192.0.2.0/26) ou na notação de intervalo (por exemplo: 192.0.2.64-192.0.2.72). Para especificar um único endereço IP num conjunto, use /32 na notação CIDR (por exemplo: 192.0.2.1/32).

      3. Se o VIP de entrada não estiver no intervalo de endereços, selecione + Adicionar intervalo de endereços IP e introduza outro intervalo de endereços que inclua o VIP de entrada.

        Os endereços IP em cada conjunto não podem sobrepor-se e têm de 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 esta opção se quiser que o controlador do MetalLB atribua automaticamente endereços IP do conjunto de endereços aos serviços do tipo LoadBalancer.
        • Manual: escolha esta opção se pretender usar endereços do conjunto para especificar manualmente endereços para serviços do tipo LoadBalancer.

      5. Clique em Evitar endereços IP com erros se quiser que o controlador MetalLB não use endereços do conjunto que terminam em .0 ou .255. Isto evita o problema de dispositivos de consumo com erros que eliminam por engano o tráfego enviado para esses endereços IP especiais.

      6. Quando terminar, clique em Concluído.

      7. Se necessário, clique em Adicionar conjunto de endereços.

    Balanceador de carga manual

    Com o equilíbrio de carga manual, configura as suas próprias soluções de equilíbrio de carga para o tráfego do plano de controlo e do plano de dados. Tem de configurar o VIP do plano de controlo no balanceador de carga externo antes de criar um cluster. O balanceador de carga do plano de controlo externo também pode ser usado para o tráfego do plano de dados ou pode configurar um balanceador de carga separado para o plano de dados. Para mais informações, consulte o artigo Configure o equilíbrio de carga manual.

  3. Na secção IPs virtuais, introduza o seguinte:

    • VIP do plano de controlo: o endereço IP de destino a usar para o tráfego enviado para o servidor da API Kubernetes do cluster de utilizadores. O VIP do plano de controlo tem de estar na mesma sub-rede que os nós do balanceador de carga e não pode estar em nenhum dos intervalos de endereços usados para os conjuntos de endereços do balanceador de carga.

    • Porta: a porta de destino usada para o tráfego enviado para o servidor da API Kubernetes. A predefinição é 443.

    • VIP de entrada: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada. Introduza um endereço de um dos conjuntos de endereços do equilibrador de carga.

  4. Na secção CIDRs de serviços e pods, especifique os intervalos de endereços IP de serviços e pods do Kubernetes na notação CIDR. Não podem sobrepor-se entre si nem a qualquer endereço fora do cluster que quer alcançar a partir do interior do cluster. Recomendamos que use os intervalos de endereços IP privados definidos pela RFC 1918. A consola fornece os seguintes intervalos de endereços predefinidos, mas pode alterá-los:

    • CIDR do serviço: 10.96.0.0/20 se não aceitar a predefinição, introduza um intervalo CIDR entre /24 e /12, em que /12 fornece o maior número de endereços IP.

    • CIDR do pod: 192.168.0.0/16 se não aceitar a predefinição, introduza um intervalo CIDR entre /18 e /8, em que /8 fornece o maior número de endereços IP.

  5. Na secção de atributos Atributos avançados, especifique opcionalmente o seguinte:

    • URL do proxy: o endereço HTTP do seu servidor proxy. Inclua o número da porta, mesmo que seja o mesmo que a porta predefinida do esquema, por exemplo: http://my-proxy.example.local:80

    • URLs: uma lista separada por vírgulas de endereços IP, intervalos de endereços IP, nomes de anfitriões e nomes de domínios que não devem passar pelo servidor proxy. Quando o Google Distributed Cloud envia um pedido para um destes endereços, anfitriões ou domínios, o pedido é enviado diretamente.

  6. Clicar em Seguinte.

Armazenamento

O software Google Distributed Cloud apenas fornece interfaces de armazenamento de blocos e ficheiros. Têm opções predefinidas, mas pode personalizar as configurações. Para mais informações, consulte o artigo Configure o armazenamento local.

  1. Opcionalmente, pode configurar o seguinte:

    • Montagens de nós de aprovisionamento de volumes locais: especifica a configuração para PersistentVolumes locais (PVs) suportados por discos montados. Tem de formatar e montar estes discos, o que pode fazer antes ou depois da criação do cluster.

    • Partilha do aprovisionador de volumes locais: especifica a configuração para o volume local PersistentVolumes suportado por subdiretórios num sistema de ficheiros partilhado. Estas subdiretorias são criadas automaticamente durante a criação do cluster.

  2. Clicar em Seguinte.

Funcionalidades

Para ajudar a monitorizar, resolver problemas e operar o cluster, o seguinte é ativado automaticamente e não pode ser desativado:

Crie um node pool na consola

O cluster tem de ter, pelo menos, um conjunto de nós para nós de trabalho. Um conjunto de nós é um modelo para os grupos de nós de trabalho criados neste cluster.

Na consola, configura, pelo menos, um conjunto de nós (ou aceita os valores predefinidos) e, em seguida, cria o cluster. Pode adicionar pools de nós adicionais depois de criar o cluster. Com a CLI gcloud, cria primeiro o cluster e, em seguida, adiciona um ou mais conjuntos de nós ao cluster recém-criado.

  1. Clique em conjunto predefinido na barra de navegação do lado esquerdo.

  2. Na secção Predefinições do conjunto de nós, introduza o Nome do conjunto de nós ou aceite "default-pool" como nome.

  3. Na secção Nós de trabalho, introduza os endereços IP das máquinas nas quais o cluster vai ser executado.

  4. Na secção Metadados do node pool (opcional), se quiser adicionar etiquetas do Kubernetes e restrições faça o seguinte:

    1. Clique em + Adicionar etiquetas do Kubernetes. Introduza a Chave e o Valor da etiqueta. Repita estes passos conforme necessário.
    2. Clique em + Adicionar contaminação. Introduza a Chave, o Valor e o Efeito da contaminação. Repita estes passos conforme necessário.

  5. Clique em Validar e concluir para criar o cluster de utilizadores. A criação do cluster de utilizadores demora 15 minutos ou mais. 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

Use o seguinte comando para criar um cluster de utilizadores:

gcloud container bare-metal clusters create

Depois de criar o cluster, tem de criar, pelo menos, um node pool com o seguinte comando:

gcloud container bare-metal node-pools create

A maioria das flags para criar o cluster e o node pool corresponde aos campos no ficheiro de configuração do cluster de utilizadores. Para ajudar a começar, pode testar o comando completo na secção Exemplos. Para ver informações sobre as flags, consulte as secções que seguem os exemplos ou consulte a referência da CLI gcloud.

Antes de começar

A versão que selecionar quando criar um cluster de utilizadores tem de ser uma versão suportada pelo cluster de administrador. Além disso, as versões secundárias ou de patch mais recentes não estão disponíveis na API GKE On-Prem até 7 a 14 dias após o lançamento. Pode executar um comando gcloud para obter uma lista de versões de clusters suportadas que pode instalar.

  1. Certifique-se de que atualiza os componentes:

    gcloud components update

  2. Obtenha o nome e a localização da associação à frota do cluster de administrador:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto no qual o cluster de administrador está registado.

    O resultado é semelhante ao seguinte:

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    A localização especifica onde os serviços Fleet e Connect são executados. Os clusters de administrador criados antes da versão 1.28 são geridos pelos serviços globais da frota e do Connect. Na versão 1.28 e posteriores, pode especificar global ou uma Google Cloud região quando cria o cluster de administrador. Especifica a região no comando --admin-cluster-membership-location no exemplo de comandos que se segue.

  3. Obtenha uma lista de versões disponíveis para instalar no cluster de utilizadores:

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION

    Substitua o seguinte:

    • ADMIN_CLUSTER_NAME: o nome do cluster de administrador.

    • FLEET_HOST_PROJECT_ID: o ID do projeto no qual o cluster de administrador está registado.

    • ADMIN_CLUSTER_REGION: a região de associação da frota do cluster de administrador. Esta opção é global ou de uma Google Cloud região. Use a localização do cluster de administrador a partir do resultado de gcloud container fleet memberships list.

    • REGION: a 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.

    O resultado do comando é semelhante ao seguinte:

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

Sugerimos que use a versão suportada mais elevada para obter as correções e as melhorias mais recentes.

Exemplos

Esta secção fornece um exemplo de um comando que cria um cluster através do balanceador de carga do MetalLB e um exemplo através de um balanceador de carga manual. As informações que especificar variam consoante o tipo de equilibrador de carga que vai usar. Consulte a vista geral dos equilibradores de carga para mais informações.

Os exemplos criam o cluster sem node pools. Depois de o cluster estar em execução, tem de adicionar um conjunto de nós antes de implementar cargas de trabalho.

MetalLB

Este exemplo mostra como criar um cluster de utilizadores com o balanceador de carga MetalLB incluído.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Substitua o seguinte:

  • USER_CLUSTER_NAME: um nome à sua escolha para o cluster de utilizadores. Não é possível alterar o nome após a criação do cluster. O nome tem de:
    • Conter, no máximo, 40 carateres
    • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
    • Começar com um caráter alfabético
    • Terminar com um caráter alfanumérico
  • FLEET_HOST_PROJECT_ID: o ID do projeto no qual quer criar o cluster. O projeto especificado também é usado como o projeto de anfitrião da frota. Tem de ser o mesmo projeto no qual o cluster de administrador está registado. Após a criação do cluster de utilizadores, este é automaticamente registado na frota do projeto selecionado. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.
  • ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gere o cluster de utilizadores. Na flag --admin-cluster-membership, pode usar o nome do cluster totalmente especificado, que tem o seguinte formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Em alternativa, pode definir --admin-cluster-membership para o nome do cluster de administração, como no comando de exemplo. Quando usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e a localização com --admin-cluster-membership-location. A localização do cluster de administrador é global ou uma região Google Cloud . Se precisar de encontrar a região, execute gcloud container fleet memberships list.

  • REGION: A Google Cloud região na qual 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 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 utilizadores 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 em conjunto o cluster de forma exclusiva em Google Cloud.

  • VERSION: a versão do Google Distributed Cloud para o seu cluster de utilizador.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se não incluir a flag --admin-users, como criador do cluster, são-lhe concedidos privilégios de administrador do cluster por predefinição. No entanto, se incluir --admin-users para designar outro utilizador como administrador, substitui o valor predefinido e tem de incluir o seu endereço de email e o endereço de email 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 controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para lhe conceder a si e a outros utilizadores administradores a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.

Pools de endereços do MetalLB

  • --metal-lb-address-pools: especifique a configuração dos conjuntos de endereços a serem usados pelo equilibrador de carga do MetalLB. O valor da flag tem o seguinte formato:
'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 à sua escolha para o grupo.

  • avoid-buggy-ips: se definir esta opção como True, o controlador MetalLB não atribui endereços IP que terminem em .0 ou .255 aos serviços. Isto evita o problema de dispositivos de consumo com erros que eliminam por engano o tráfego enviado para esses endereços IP especiais. Se não for especificado, o fuso horário predefinido é False.

  • manual-assign: Se não quiser que o controlador MetalLB atribua automaticamente endereços IP deste conjunto a serviços, defina esta opção como True. Em seguida, um programador pode criar um serviço do tipo LoadBalancer e especificar manualmente um dos endereços do conjunto. Se não for especificado, manual-assign é definido como False.

  • Na lista de addresses: cada endereço tem de ser um intervalo no formato CIDR ou com hífen. Para especificar um único endereço IP num conjunto (como para o VIP de entrada), use /32 na notação CIDR (por exemplo, 192.0.2.1/32).

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 intervalo de endereços IP com um ponto e vírgula.

Pode especificar mais do que uma instância da flag, conforme mostrado no exemplo seguinte:

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

Nós do MetalLB

  • Opcional: --metal-lb-load-balancer-node-configs: por predefinição, o balanceador de carga é executado nos mesmos nós que o plano de controlo. Se precisar de executar o balanceador de carga num conjunto dedicado de nós de trabalho, especifique esta flag para cada nó. Todos os nós no conjunto de nós do balanceador de carga têm de estar na mesma sub-rede da camada 2 que os IPs virtuais (VIPs) do balanceador de carga.

    O valor da flag tem o seguinte formato:

    'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_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ó no conjunto de nós do balanceador de carga. Só pode especificar um node-ip por flag. 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.

    Se especificar --metal-lb-load-balancer-node-configs, pode incluir opcionalmente as seguintes flags:

    • --metal-lb-load-balancer-node-labels: use esta flag para adicionar etiquetas a todos os nós no conjunto de nós do balanceador de carga. Separe a lista de pares chave=valor com uma vírgula.

      --metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

    • --metal-lb-load-balancer-node-taints: use esta flag para adicionar taints a todos os nós no conjunto de nós do balanceador de carga. Cada contaminação é um par chave=valor associado a um efeito, que tem de ser um dos seguintes: PreferNoSchedule, NoSchedule ou NoExecute.

      --metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2

    O exemplo seguinte adiciona três nós ao conjunto de nós do balanceador de carga. Todos os nós estão etiquetados com lb-pool-key=lb-pool-value e têm a contaminação dedicated=experimental:PreferNoSchedule,

    --metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \

Nós do plano de controlo

  • --control-plane-node-configs: 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 estes endereços sempre que atualizar ou fizer uma atualização de um 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. Só pode especificar um node-ip por flag. 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.

    Opcionalmente, inclua as seguintes flags:

  • --control-plane-node-labels: use esta flag para adicionar etiquetas a todos os nós do plano de controlo. Separe a lista de pares chave=valor com uma vírgula. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: use esta flag para adicionar taints a todos os nós do plano de controlo. Cada mancha é um par chave=valor associado a um efeito, que tem de ser um dos seguintes: PreferNoSchedule, NoSchedule ou NoExecute.

    O exemplo seguinte adiciona três nós aos nós do plano de controlo. Todos os nós estão etiquetados com cp-node-pool-key=cp-node-pool-value e têm a contaminação dedicated=experimental:PreferNoSchedule.

      --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

IPs virtuais

  • CONTROL_PLANE_VIP: o endereço IP que escolheu para configurar no equilibrador de carga para o servidor da API Kubernetes do cluster de utilizadores.

    Exemplo: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: a porta na qual o balanceador de carga serve o servidor da API Kubernetes.

    Exemplo: -control-plane-load-balancer-port=443

  • INGRESS_VIP: o endereço IP que escolheu para 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 tem de estar num dos conjuntos de endereços do MetalLB.

CIDRs de serviços e pods

  • SERVICE_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para serviços no seu cluster. O intervalo CIDR tem de estar entre /24 e /12, sendo que /12 fornece o maior número de endereços IP.

    Exemplo: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para pods no seu cluster. O intervalo CIDR tem de estar entre /18 e /8, em que /8 fornece o maior número de endereços IP.

    Exemplo: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Armazenamento

  1. --lvp-share-path: este é o caminho do computador anfitrião onde podem ser criados subdiretórios. É criado um PersistentVolume (PV) local para cada subdiretório.
  2. --lvp-share-storage-class: esta é a StorageClass a usar para criar volumes persistentes. A StorageClass é criada durante a criação do cluster.
  3. --lvp-node-mounts-config-path: este é o caminho da máquina anfitriã onde os discos montados podem ser descobertos. É criado um PersistentVolume (PV) local para cada montagem.
  4. --lvp-node-mounts-config-storage: a classe de armazenamento com que os PVs são criados durante a criação do cluster.

Para mais informações sobre o armazenamento, consulte o artigo Configure o armazenamento local.

Manual

Com o equilíbrio de carga manual, configura as suas próprias soluções de equilíbrio de carga para o tráfego do plano de controlo e do plano de dados. Tem de configurar o VIP do plano de controlo no balanceador de carga externo antes de criar um cluster. O balanceador de carga do plano de controlo externo também pode ser usado para o tráfego do plano de dados ou pode configurar um balanceador de carga separado para o plano de dados. Para mais informações, consulte o artigo Configure o equilíbrio de carga manual.

Certifique-se de que desloca a página, se necessário, para preencher o marcador de posição ADMIN_CLUSTER_NAME para a flag --admin-cluster-membership.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Substitua o seguinte:

  • USER_CLUSTER_NAME: um nome à sua escolha para o cluster de utilizadores. Não é possível alterar o nome após a criação do cluster. O nome tem de:
    • Conter, no máximo, 40 carateres
    • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
    • Começar com um caráter alfabético
    • Terminar com um caráter alfanumérico
  • FLEET_HOST_PROJECT_ID: o ID do projeto no qual quer criar o cluster. O projeto especificado também é usado como o projeto de anfitrião da frota. Tem de ser o mesmo projeto no qual o cluster de administrador está registado. Após a criação do cluster de utilizadores, este é automaticamente registado na frota do projeto selecionado. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.
  • ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gere o cluster de utilizadores. Na flag --admin-cluster-membership, pode usar o nome do cluster totalmente especificado, que tem o seguinte formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    Em alternativa, pode definir --admin-cluster-membership para o nome do cluster de administração, como no comando de exemplo. Quando usa apenas o nome do cluster de administrador, defina o ID do projeto do cluster de administrador com --admin-cluster-membership-project e a localização com --admin-cluster-membership-location. A localização do cluster de administrador é global ou uma região Google Cloud . Se precisar de encontrar a região, execute gcloud container fleet memberships list.

  • REGION: A Google Cloud região na qual 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 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 utilizadores 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 em conjunto o cluster de forma exclusiva em Google Cloud.

  • VERSION: a versão do Google Distributed Cloud para o seu cluster de utilizador.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se não incluir a flag --admin-users, como criador do cluster, são-lhe concedidos privilégios de administrador do cluster por predefinição. No entanto, se incluir --admin-users para designar outro utilizador como administrador, substitui o valor predefinido e tem de incluir o seu endereço de email e o endereço de email 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 controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para lhe conceder a si e a outros utilizadores administradores a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes.

Nós do plano de controlo

  • --control-plane-node-configs: 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 estes endereços sempre que atualizar ou fizer uma atualização de um 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. Só pode especificar um node-ip por flag. 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.

    Opcionalmente, inclua as seguintes flags:

  • --control-plane-node-labels: use esta flag para adicionar etiquetas a todos os nós do plano de controlo. Separe a lista de pares chave=valor com uma vírgula. 
      --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
  • --control-plane-node-taints: use esta flag para adicionar taints a todos os nós do plano de controlo. Cada mancha é um par chave=valor associado a um efeito, que tem de ser um dos seguintes: PreferNoSchedule, NoSchedule ou NoExecute.

    O exemplo seguinte adiciona três nós aos nós do plano de controlo. Todos os nós estão etiquetados com cp-node-pool-key=cp-node-pool-value e têm a contaminação dedicated=experimental:PreferNoSchedule.

      --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \

IPs virtuais

  • CONTROL_PLANE_VIP: o endereço IP que escolheu para configurar no equilibrador de carga para o servidor da API Kubernetes do cluster de utilizadores.

    Exemplo: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: a porta na qual o balanceador de carga serve o servidor da API Kubernetes.

    Exemplo: -control-plane-load-balancer-port=443

  • INGRESS_VIP: o endereço IP que escolheu para 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 tem de estar num dos conjuntos de endereços do MetalLB.

CIDRs de serviços e pods

  • SERVICE_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para serviços no seu cluster. O intervalo CIDR tem de estar entre /24 e /12, sendo que /12 fornece o maior número de endereços IP.

    Exemplo: --island-mode-service-address-cidr-blocks=10.96.0.0/20

  • POD_CIDR_BLOCK: um intervalo de endereços IP, no formato CIDR, a usar para pods no seu cluster. O intervalo CIDR tem de estar entre /18 e /8, em que /8 fornece o maior número de endereços IP.

    Exemplo: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Armazenamento

  1. --lvp-share-path: este é o caminho do computador anfitrião onde podem ser criados subdiretórios. É criado um PersistentVolume (PV) local para cada subdiretório.
  2. --lvp-share-storage-class: esta é a StorageClass a usar para criar volumes persistentes. A StorageClass é criada durante a criação do cluster.
  3. --lvp-node-mounts-config-path: este é o caminho da máquina anfitriã onde os discos montados podem ser descobertos. É criado um PersistentVolume (PV) local para cada montagem.
  4. --lvp-node-mounts-config-storage: a classe de armazenamento com que os PVs são criados durante a criação do cluster.

Para mais informações sobre o armazenamento, consulte o artigo Configure o armazenamento local.

Antes de executar o comando gcloud para criar o cluster, recomendamos que inclua --validate-only para validar a configuração especificada nas flags do comando gcloud. Quando tiver tudo pronto para criar o cluster, remova esta flag e execute o comando.

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

A criação do cluster de utilizadores demora 15 minutos ou mais. Pode ver o cluster na Google Cloud consola na página Clusters do GKE.

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

Crie um node pool

Depois de criar o cluster, tem de criar, pelo menos, um conjunto de nós antes de implementar cargas de trabalho. Um conjunto de nós é um modelo para os grupos de nós de trabalho criados neste cluster. Com a CLI gcloud, cria primeiro o cluster e, em seguida, adiciona um ou mais conjuntos de nós ao cluster recém-criado.

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

Substitua o seguinte:

  • NODE_POOL_NAME: um nome à sua escolha para o node pool. O nome tem de:

    • Conter, no máximo, 40 carateres
    • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
    • Começar com um caráter alfabético
    • Terminar com um caráter alfanumérico

  • USER_CLUSTER_NAME: o nome do cluster de utilizadores criado recentemente.

  • FLEET_HOST_PROJECT_ID: o ID do projeto no qual o cluster está registado.

  • REGION: a Google Cloud região que especificou quando criou o cluster.

  • --node-configs: O endereço IPv4 de uma máquina de nó de trabalho. Especifique este sinalizador para cada nó. O valor da flag tem o seguinte formato:

    'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_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ó de trabalho. Pode especificar apenas um node-ip por indicação. Adicione novamente esta flag para cada nó no conjunto de nós.

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

    Opcionalmente, pode especificar o seguinte:

    • --node-labels=KEY=VALUE,...: uma lista separada por vírgulas de etiquetas do Kubernetes (pares de chave-valor) aplicadas a cada nó no pool.

    • --node-taints=KEY=VALUE:EFFECT,... Uma lista separada por vírgulas de Kubernetes taints aplicados a cada nó no conjunto. As restrições são pares de chave=valor associados a um efeito. As restrições são usadas com tolerâncias para o agendamento de pods. Especifique um dos seguintes para EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

O exemplo seguinte cria um node pool denominado default-pool em user-cluster- e adiciona dois nós ao node pool. Todos os nós estão etiquetados com node-pool-key=node-pool-value e têm a contaminação dedicated=experimental:PreferNoSchedule,

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

Para mais informações, consulte a referência da CLI gcloud.

Terraform

Antes de começar

A versão do Google Distributed Cloud (apenas software) em bare metal que selecionar quando criar um cluster de utilizador tem de ser uma versão suportada pelo cluster de administrador. Além disso, as versões secundárias ou de patch mais recentes não estão disponíveis na API GKE On-Prem até 7 a 14 dias após o lançamento. Pode executar o comando gcloud para obter uma lista de versões suportadas que pode usar para instalar o cluster de utilizadores.

  1. Certifique-se de que atualiza os componentes:

    gcloud components update

  2. Obtenha o nome e a localização da associação à frota do cluster de administrador:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Substitua FLEET_HOST_PROJECT_ID pelo ID do projeto no qual o cluster de administrador está registado.

    O resultado é semelhante ao seguinte:

    NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1

    A localização especifica onde os serviços Fleet e Connect são executados. Os clusters de administrador criados antes da versão 1.28 são geridos pelos serviços globais da frota e do Connect. Na versão 1.28 e posteriores, pode especificar global ou uma Google Cloud região quando cria o cluster de administrador. Especifica a região no comando --admin-cluster-membership-location no exemplo de comandos que se segue.

  3. Obtenha uma lista de versões disponíveis para instalar no cluster de utilizadores:

    gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION

    Substitua o seguinte:

    • ADMIN_CLUSTER_NAME: o nome do cluster de administrador.

    • FLEET_HOST_PROJECT_ID: o ID do projeto no qual o cluster de administrador está registado.

    • ADMIN_CLUSTER_REGION: a região de associação da frota do cluster de administrador. Esta opção é global ou de uma Google Cloud região. Use a localização do cluster de administrador a partir do resultado de gcloud container fleet memberships list.

    • REGION: a 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.

    O resultado do comando é semelhante ao seguinte:

    versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5

Sugerimos que use a versão suportada mais elevada para obter as correções e as melhorias mais recentes.

Exemplo

Pode usar o seguinte exemplo de configuração básica para criar um cluster de utilizadores com o balanceador de carga MetalLB incluído. Para mais informações, consulte a google_gkeonprem_bare_metal_cluster documentação de referência.

Defina variáveis em terraform.tfvars

O exemplo fornece um ficheiro de variáveis de exemplo para transmitir a main.tf, que mostra como configurar o equilibrador de carga MetalLB incluído.

  1. Clone o repositório anthos-samples e mude para o diretório onde se encontra o exemplo do Terraform:

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

    A amostra fornece um ficheiro de variáveis de exemplo para transmitir ao main.tf.

  2. Crie uma cópia do ficheiro terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars

  3. Modifique os valores dos parâmetros em terraform.tfvars e guarde o ficheiro.

    
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
lb_address_pools    = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]

    A lista seguinte descreve as variáveis:

    • project_id: o ID do projeto no qual quer criar o cluster. O projeto especificado também é usado como o projeto anfitrião da frota. Este tem de ser o mesmo projeto no qual o cluster de administrador está registado. Depois de o cluster de utilizadores ser criado, é registado automaticamente na frota do projeto selecionado. Não é possível alterar o projeto anfitrião da frota após a criação do cluster.

    • region: A Google Cloud região na qual 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 suportada.

    • admin_cluster_name: o nome do cluster de administrador que gere o cluster de utilizadores. O exemplo pressupõe que o cluster de administrador usa global como a região. Se tiver um cluster de administração regional:

      1. Abra main.tf num editor de texto.

      2. Pesquise admin_cluster_membership, que tem o seguinte aspeto:

        admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

      3. Altere global para a região que o cluster de administrador usa e guarde o ficheiro.

    • bare_metal_version: a versão do Google Distributed Cloud para o seu cluster de utilizadores. Especifique a mesma versão que o cluster de administrador ou uma versão que seja, no máximo, uma versão secundária inferior à do cluster de administrador.

    • admin_user_emails: uma lista de endereços de email dos utilizadores aos quais devem ser concedidos privilégios administrativos no cluster. Certifique-se de que adiciona o seu endereço de email se pretender administrar o cluster.

      Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes ao cluster para conceder aos utilizadores administradores a função clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos no cluster em todos os espaços de nomes. Isto também permite que os utilizadores iniciem sessão na consola através da respetiva identidade Google.

    • cluster_name: um nome à sua escolha para o cluster de utilizadores. Não é possível alterar o nome após a criação do cluster. O nome tem de:

      • Conter, no máximo, 40 carateres
      • conter apenas carateres alfanuméricos minúsculos ou um hífen (-)
      • Começar com um caráter alfabético
      • Terminar com um caráter alfanumérico

    • control_plane_ips: uma lista de um ou mais endereços IPv4 para os nós do plano de controlo. Os nós do plano de controlo executam a carga de trabalho do sistema. 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 estes endereços sempre que atualizar um cluster.

    • worker_node_ips: Uma lista de um ou mais endereços IPv4 para as máquinas dos nós de trabalho.

    • control_plane_vip: O endereço IP virtual (VIP) que escolheu para configurar no balanceador de carga para o servidor da API Kubernetes do cluster de utilizadores.

    • ingress_vip: o endereço IP que escolheu para configurar no balanceador de carga para o proxy de entrada.

    • lb_address_pools: uma lista de mapas que definem os conjuntos de endereços a serem usados pelo equilibrador de carga do MetalLB. O VIP de entrada tem de estar num destes conjuntos.

  4. Guarde as alterações em terraform.tfvars.

  5. Inicialize e crie o plano do Terraform:

    terraform init

    O Terraform instala todas as bibliotecas necessárias, como o Google Cloud fornecedor.

  6. Reveja a configuração e faça alterações, se necessário:

    terraform plan

  7. Aplique o plano do Terraform para criar o cluster de utilizadores:

    terraform apply

    A criação do cluster de utilizadores demora 15 minutos ou mais. Pode ver o cluster na Google Cloud consola na página Clusters do GKE.

Estabeleça ligação ao cluster de utilizadores

Quando cria um cluster de utilizadores na consola, o cluster é configurado com as políticas de controlo de acesso baseado em funções (RBAC) do Kubernetes para que possa iniciar sessão no cluster através da sua Google Cloud identidade. Quando cria um cluster de utilizadores com a CLI gcloud, são-lhe concedidas estas políticas de RBAC por predefinição, se não incluir a flag --admin-users. Se incluir --admin-users para designar outro utilizador como administrador, substitui a predefinição e tem de incluir o seu endereço de email e o endereço de email do outro administrador. Para mais informações sobre as políticas de IAM e RBAC necessárias, consulte o artigo Configure a autenticação de identidade da Google.

Todos os clusters têm um ponto final canónico. O ponto final expõe o servidor da API Kubernetes que o kubectl e outros serviços usam para comunicar com o plano de controlo do cluster através da porta TCP 443. Este ponto final não está acessível na Internet pública. Se tiver acesso ao ponto final privado do cluster através da VPC, pode estabelecer ligação diretamente ao ponto final privado e gerar um ficheiro kubeconfig diretamente. Caso contrário, pode usar o gateway de ligação.

Para aceder ao cluster de utilizadores a partir da linha de comandos, precisa de um ficheiro kubeconfig. Existem duas formas de obter um ficheiro kubeconfig:

  • Use o gateway de ligação para aceder ao cluster a partir de um computador que tenha a Google Cloud CLI instalada. Neste caso, o kubectl usa o kubeconfig do gateway Connect, que encaminha o tráfego de forma segura para o ponto final privado em seu nome.

  • Para aceder diretamente a pontos finais privados, crie um ficheiro kubeconfig na estação de trabalho do administrador e faça a gestão do cluster a partir da estação de trabalho do administrador.

Certifique-se de que aguarda até a consola Google Cloud indicar que o estado do cluster de utilizadores está em bom estado.

Ligue o gateway

  1. Inicialize a CLI gcloud para utilização com o projeto anfitrião da frota ou execute os seguintes comandos para iniciar sessão com a sua Conta Google, defina o projeto anfitrião da frota como predefinição e atualize os componentes:

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Obtenha as credenciais do cluster usadas para interagir com o gateway de ligação. No comando seguinte, substitua MEMBERSHIP_NAME pelo nome do cluster. Para o Google Distributed Cloud (apenas software) em bare metal, o nome da associação é o mesmo que o nome do cluster.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Este comando devolve um gateway específico de ligaçãokubeconfig especial que lhe permite ligar-se ao cluster através do gateway.

Depois de ter as credenciais necessárias, pode executar comandos usando kubectl como faria normalmente para qualquer cluster do Kubernetes e não precisa de especificar o nome do ficheiro kubeconfig, por exemplo:

kubectl get namespaces

Estação de trabalho do administrador

Use o comando bmctl get credentials para obter um ficheiro kubeconfig para o cluster de utilizadores criado recentemente.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster de utilizadores-alvo.

  • ADMIN_KUBECONFIG_PATH: o caminho para o ficheiro kubeconfig do cluster de administrador.

Um kubeconfig com as credenciais do cluster de utilizadores é escrito num ficheiro, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. O TIMESTAMP no nome do ficheiro indica a data e a hora em que o ficheiro foi criado.

Uma vez que este ficheiro contém credenciais de autenticação para o seu cluster, deve armazená-lo num local seguro com acesso restrito.

O que se segue?