Criar um cluster de usuário usando clientes da API Anthos On-Prem

Version 1.13 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

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

O que é a API 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, é possível criar um cluster de usuário criando um arquivo de configuração de cluster de usuário e usando bmctl, conforme descrito em Como criar um cluster de usuário.

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 um cluster de usuário para ser gerenciado pela API Anthos On-Prem.

Antes de começar

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

Conceder permissões do IAM

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

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

• roles/container.viewer.
• roles/gkehub.viewer

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

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

• roles/gkehub.viewer: esse papel permite recuperar credenciais de cluster.

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

APIs do Google obrigatórias

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

Se você quiser usar a CLI gcloud para criar o cluster, ative a API Anthos On-Prem. Se você estiver usando o console para criar o cluster, ele ativará a API Anthos On-Prem automaticamente.

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

Pré-requisitos do cluster de administrador

É necessário ter um cluster de administrador em funcionamento para criar um de usuário. O cluster de administrador precisa:

• Tenha acesso ao servidor da API Kubernetes no cluster de usuário após a criação.

• Ter conectividade de rede com todos os nós no cluster de usuário após a criação.

• Precisa ser registrado em uma frota. O ID do projeto configurado no campo gkeConnect.projectID desse cluster de administrador, chamado de projeto host da frota precisa ser o mesmo projeto em que você criará o cluster de usuário.

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

Revise os Pré-requisitos da máquina do nó do cluster para garantir que as máquinas que executarão o cluster do usuário atendam aos pré-requisitos.

Acesso à linha de comando

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

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

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

Criar um cluster de usuário

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

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

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

Console

A maioria das configurações no console corresponde aos campos no arquivo de configuração do cluster.

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. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado.

3. Clique em Criar cluster.

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

5. Ao lado de Bare Metal, clique em Configurar.

6. Analise os pré-requisitos e a arquitetura de amostra. Quando estiver tudo pronto, clique em Continuar para começar a configurar o cluster.

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

Noções básicas sobre clusters

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

1. Insira um nome para o cluster de usuário.

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

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 usuário 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. Selecione os clusters do Anthos em bare metal para o cluster de usuário. Os clusters de usuário precisam ser a mesma versão secundária do cluster de administrador ou uma versão secundária anterior ao cluster de administrador.

5. Como criador do cluster, você recebe privilégios de administrador. Se quiser, insira o endereço de e-mail de outro usuário que administrará o cluster no campo Usuário administrador.

   Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces.

   Observação: além das políticas do RBAC do Kubernetes, você precisa conceder alguns papéis do Identity and Access Management (IAM) aos usuários que não são proprietários de projetos. Para detalhes sobre como conceder os papéis do IAM, consulte Conceder os papéis necessários.

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

   • Máximo de pods por nó: insira o número máximo de pods que podem ser executados em um único nó. Os valores permitidos estão entre 32 e 250, inclusive. O Kubernetes atribui um bloco de roteamento entre domínios sem classe (CIDR) para cada nó. Assim, cada pod tem um endereço IP exclusivo. 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 Rede de pods.

   • Ambiente de execução do contêiner: containerd é o único ambiente de execução do contêiner disponível para seu cluster.

7. Clique em Continuar para acessar a seção Rede.

Rede

Nesta seção, você especificará os endereços IP para os nós, pods e serviços do cluster. Se você estiver usando o balanceamento de carga em pacote com o MetalLB, também será possível configurá-lo.

1. Na seção de nós do Plano de controle, insira o endereço IPv4 de cada nó do plano de controle. Os nós do plano de controle executam a carga de trabalho do sistema. Normalmente, pode ser uma máquina única usando uma implantação mínima ou três máquinas 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. Este campo pode ser alterado sempre que você atualizar ou fizer upgrade de um cluster.

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

2. Na seção Balanceador de carga, selecione o balanceador de carga na lista Modo a ser configurado para o cluster. Consulte Visão geral dos balanceadores de carga para mais informações.

   Empacotado com MetalLB

   Configurar o balanceamento de carga com o balanceador de carga MetalLB empacotado. Com essa opção, os clusters do Anthos em bare metal implantam balanceadores de carga da camada 4 que são executados em um pool de nós de trabalho dedicado ou nos mesmos nós do plano de controle.

   1. Na seção Pools de nós do balanceador de carga, selecione uma das seguintes opções:

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

      • Criar pool de nós do balanceador de carga: escolha essa opção avançada se precisar executar os balanceadores de carga em um pool dedicado de nós de trabalho. Todos os nós no pool de nós do balanceador de carga precisam estar na mesma sub-rede da camada 2 dos IPs virtuais (VIPs) do balanceador de carga que você configura na seção Pools de endereços do balanceador de carga.

        1. No campo IP 1 do pool de nós do balanceador de carga, insira um endereço IPv4 para um nó no pool de nós do balanceador de carga.

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

   2. Na seção Pools de endereços do balanceador de carga, adicione um ou mais pools de endereços para que o controlador do MetalLB escolha e atribua a serviços do tipo LoadBalancer. O VIP de entrada especificado na seção IPs virtuais precisa estar em um desses pools.

      1. Insira um Nome para o pool de nós.

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

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

         Os endereços IP de cada pool não podem se sobrepor e precisam estar na mesma sub-rede que os nós do cluster.

      4. Em Atribuição de endereços IP, selecione uma das seguintes opções:

         • Automático: escolha essa opção se quiser que o controlador do MetalLB atribua automaticamente endereços IP do pool de endereços aos serviços do tipo LoadBalancer.
         • Manual: escolha essa opção se você pretende usar endereços do pool para especificar manualmente os endereços para serviços do tipo LoadBalancer.

      5. Clique em Evitar endereços IP com bugs se quiser que o controlador MetalLB não use endereços do pool que terminam em .0 ou .255. Isso evita o problema de dispositivos com bug de consumo que descartam o tráfego enviado para esses endereços IP especiais.

      6. Quando terminar, clique em Concluído.

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

   Balanceador de carga manual

   Com o balanceamento de carga manual, você configura suas próprias soluções para balanceamento de carga do plano de controle e do tráfego do plano de dados. É necessário configurar o VIP do plano de controle no balanceador de carga externo antes de criar um cluster. O balanceador de carga do plano de controle externo também pode ser usado para o tráfego do plano de dados, ou um balanceador de carga separado para o plano de dados. Para mais informações, consulte Configurar balanceamento de carga manual.

3. Na seção IPs virtuais, digite o seguinte:

   • VIP do plano de controle: o endereço IP de destino a ser usado para o tráfego enviado ao servidor da API Kubernetes do cluster de usuário. O VIP do plano de controle precisa 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 pools de endereços do balanceador de carga.

   • Porta: a porta de destino usada para o tráfego enviado ao servidor da API Kubernetes. O padrão é 443.

   • Ingress VIP: o endereço IP a ser configurado no balanceador de carga para o proxy de entrada. Insira um endereço de um dos pools de endereços do balanceador de carga.

4. Na seção CIDRs de serviço e pod, especifique os intervalos de endereços IP do Serviço e do pod do Kubernetes na notação CIDR. Eles não podem sobrepor uns aos outros nem qualquer endereço fora do cluster que você queira alcançar de dentro do cluster. Recomendamos que você use os intervalos de endereços IP particulares definidos pela RFC 1918. O console fornece os seguintes intervalos de endereços padrão, mas você pode alterá-los:

   • CIDR de serviço: 10.96.0.0/20 se você não aceitar o padrão, insira um intervalo CIDR entre /24 e /12, em que /12 fornece a maioria dos endereços IP.

   • Pod CIDR: 192.168.0.0/16 se você não aceitar o padrão, insira um intervalo CIDR entre /18 e /8, em que /8 fornece a maioria dos endereços IP.

5. Na seção Atributos avançados, você também pode especificar:

   • URL do proxy: é o endereço HTTP do servidor proxy. Inclua o número da porta mesmo que ele seja igual à porta padrão 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 host e nomes de domínio que não podem passar pelo servidor proxy. Quando os clusters do Anthos em bare metal enviam uma solicitação para um desses endereços, hosts ou domínios, a solicitação é enviada diretamente.

6. Clique em Next.

Armazenamento

Clusters do Anthos em bare metal oferecem interfaces de armazenamento em blocos e arquivos. Eles contam com opções padrão, mas as configurações são personalizáveis. Para saber mais, consulte Configurar o armazenamento local.

1. Também é possível configurar o seguinte:

   • Ativações de nós do provisionador de volume local: especifica a configuração das PersistentVolumes (PVs) locais compatíveis com discos montados. Esses discos precisam ser formatados e montados, e isso pode ser feito antes ou depois de criar o cluster.

   • Compartilhamento local do provisionador de volume: especifica a configuração para o PersistentVolumes local com suporte de subdiretórios em um sistema de arquivos compartilhados. Esses subdiretórios são criados automaticamente durante a criação do cluster.

2. Clique em Next.

Recursos

Para ajudar você a monitorar, solucionar problemas e operar seu cluster, os recursos a seguir são ativados automaticamente e não podem ser desativados:

• Cloud Logging de serviços do sistema
• Cloud Monitoring dos serviços do sistema
• O registro de auditoria da atividade do administrador

Criar um pool de nós

O cluster precisa ter pelo menos um pool de nós para nós de trabalho. Um pool de nós é um modelo para os grupos de nós criados nesse cluster.

No console, configure pelo menos um pool de nós (ou aceite os valores padrão) e crie o cluster. É possível adicionar mais pools de nós depois que o cluster é criado. Com a CLI gcloud, primeiro você cria o cluster e depois adiciona um ou mais pools de nós ao cluster recém-criado.

1. Clique em Pool padrão na barra de navegação à esquerda.

2. Na seção Padrões de pool de nós, insira o Nome do pool de nós ou aceite "default-pool" como o nome.

3. Na seção Nós de trabalho, insira os endereços IP das máquinas para executar o cluster.

4. NaMetadados do pool de nós (opcional) seção, se quiser adicionar o Kubernetes rótulos e taints , faça o seguinte:

   1. Clique em + Adicionar rótulos do Kubernetes. Insira a Chave e o Valor do rótulo. Repita quantas vezes forem necessárias.
   2. Clique em + Adicionar taint. Insira Key, Value e Effect para o taint. Repita quantas vezes forem necessárias.

5. Clique em Verificar e concluir para criar o cluster de usuário. Leva 15 minutos ou mais para criar o cluster de usuário. O console exibe mensagens de status durante a verificação das configurações e a criação do cluster no data center.

   Se 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 da gcloud

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Use o seguinte comando para criar um cluster de usuário:

gcloud beta container bare-metal clusters create

Após criar o cluster, você precisa criar pelo menos um pool de nós usando o seguinte comando:

gcloud beta container bare-metal node-pools create

A maioria das flags para criar o cluster e o pool de nós corresponde aos campos no arquivo de configuração do cluster de usuário. Para ajudar você a começar, teste o comando completo na seção exemplos. Para mais informações sobre as flags, consulte as seções que seguem os exemplos ou consulte a referência da CLI gcloud.

Antes de começar

1. Faça login com sua Conta do Google:

   gcloud auth login
   

2. Atualize os componentes:

   gcloud components update
   

Examples

Nesta seção, mostramos um exemplo de um comando que cria um cluster usando o balanceador de carga MetalLB e um exemplo usando um balanceador de carga manual. As informações especificadas variam de acordo com o tipo de balanceador de carga que você usará. Consulte Visão geral dos balanceadores de carga para mais informações.

Os exemplos criam o cluster sem pools de nós. Depois que o cluster estiver em execução, adicione um pool de nós antes de implantar cargas de trabalho.

Metal lb

Role a tela para cima, se necessário, para preencher o marcador ADMIN_CLUSTER_NAME para a flag --admin-cluster-membership.

gcloud beta container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --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:

• USER_CLUSTER_NAME: um nome de sua escolha pelo cluster de usuário. O nome não pode ser alterado após a criação do cluster. O nome precisa:
  • conter no máximo 40 caracteres
  • conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
  • começam com um caractere alfabético
  • terminar com um caractere alfanumérico.
• FLEET_HOST_PROJECT_ID: o ID do projeto em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado. O projeto host da frota não pode ser alterado após a criação do cluster.
• ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gerencia o cluster de usuário. O nome do cluster de administrador é o último segmento do nome totalmente especificado que identifica o cluster no Google Cloud: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
• 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 usuário 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: os clusters do Anthos na versão bare metal para o cluster de usuário.
• YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se você não incluir a flag --admin-users como a criadora do cluster, por padrão, você receberá privilégios de administrador do cluster. No entanto, se você incluir --admin-users para designar outro usuário como administrador, o padrão será substituído e será necessário incluir seu endereço de e-mail e o endereço de e-mail do outro administrador. Por exemplo, para adicionar dois administradores:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

  Quando o cluster é criado, a API Anthos On-Prem aplica as políticas de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces.

  Observação: além das políticas do RBAC do Kubernetes, você precisa conceder alguns papéis do Identity and Access Management (IAM) aos usuários que não são proprietários de projetos. Para detalhes sobre como conceder os papéis do IAM, consulte Conceder os papéis necessários.

Pools de endereços do MetalLB

• --metal-lb-address-pools: especifica a configuração dos pools de endereços a serem usados pelo balanceador de carga MetalLB. O valor da sinalização 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 de sua escolha para o pool.

• avoid-buggy-ips: se você definir isso como True, o controlador MetalLB não atribuirá endereços IP que terminam em .0 ou .255 aos Serviços. Isso evita o problema de dispositivos de consumo com bug que descartam o tráfego por erro enviado para esses endereços IP especiais. Se não for especificado, False será usado como padrão.

• manual-assign: se você não quiser que o controlador do MetalLB atribua automaticamente endereços IP deste pool aos Serviços, defina-o como True. Em seguida, um desenvolvedor pode criar um Serviço do tipo LoadBalancer e especificar manualmente um dos endereços do pool. Se não for especificado, manual-assign será definido como False.

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

Observe as seguintes regras de sintaxe::

• Coloque o valor inteiro entre aspas simples..
• Não é permitido usar espaços em branco.
• Separe cada intervalo de endereços IP com um ponto e vírgula.

É possível especificar mais de uma instância da sinalização, conforme mostrado no exemplo a seguir:

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

• --metal-lb-load-balancer-node-configs: opcional: por padrão, o balanceador de carga é executado nos mesmos nós que o plano de controle. Se for necessário executar o balanceador de carga em um pool dedicado de nós de trabalho, especifique essa sinalização para cada nó. Todos os nós no pool de nós do balanceador de carga precisam estar na mesma sub-rede da camada 2 dos IPs virtuais (VIPs) do balanceador de carga.

  Importante: se você criar seu cluster sem um pool de nós do balanceador de carga dedicado, não será possível adicioná-lo mais tarde. Para clusters configurados com pelo menos um nó do balanceador de carga, é possível atualizá-lo para adicionar mais nós ao pool de nós do balanceador de carga.

  O valor da sinalização 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 pool de nós do balanceador de carga. É 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.

  Se você especificar --metal-lb-load-balancer-node-configs, será possível incluir as seguintes sinalizações:

  • --metal-lb-load-balancer-node-labels: use essa sinalização para adicionar rótulos a todos os nós no pool de nós do balanceador de carga. Separe a lista de pares de 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 essa sinalização para adicionar taints a todos os nós no pool de nós do balanceador de carga. Cada taint é um par de chave-valor associado a um efeito, que precisa 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 a seguir adiciona três nós ao pool de nós do balanceador de carga. Todos os nós são rotulados com lb-pool-key=lb-pool-value e têm o taint 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 controle

• --control-plane-node-configs: 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 sinalização 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 de um cluster.

  O valor do 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.

  Também é possível incluir as seguintes sinalizações:

• --control-plane-node-labels: use essa sinalização para adicionar rótulos a todos os nós do plano de controle. Separe a lista de pares de chave-valor com vírgulas.

    --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

• --control-plane-node-taints: use essa sinalização para adicionar taints a todos os nós do plano de controle. Cada taint é um par de chave-valor associado a um efeito, que precisa ser um dos seguintes: PreferNoSchedule, NoSchedule ou NoExecute.

  O exemplo a seguir adiciona três nós aos nós do plano de controle. Todos os nós são rotulados com cp-node-pool-key=cp-node-pool-value e têm o taint 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 você decidiu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário.

  Exemplo: --control-plane-vip=203.0.113.3

• CONTROL_PLANE_LB_PORT: a porta em que o balanceador de carga veicula o servidor da API Kubernetes.

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

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

  Exemplo: --ingress-vip=10.251.134.80

  O endereço IP do VIP de entrada precisa estar em um dos pools de endereços do MetalLB.

CIDRs de pods e serviços

• SERVICE_CIDR_BLOCK: um intervalo de endereços IP no formato CIDR que será usado para serviços no cluster. O intervalo CIDR precisa estar entre /18 e /8, em que /8 fornece mais 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, que será usado para pods no cluster. O intervalo CIDR precisa estar entre /18 e /8, em que /8 fornece mais endereços IP.

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

Armazenamento

1. --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.
2. --lvp-share-storage-class: esse é o StorageClass a ser usado para criar volumes permanentes. O StorageClass é criado durante a criação do cluster.
3. --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.
4. --lvp-node-mounts-config-storage: a classe de armazenamento com a qual os PVs são criados durante a criação do cluster.

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

Manual

Com o balanceamento de carga manual, você configura suas próprias soluções para balanceamento de carga do plano de controle e do tráfego do plano de dados. É necessário configurar o VIP do plano de controle no balanceador de carga externo antes de criar um cluster. O balanceador de carga do plano de controle externo também pode ser usado para o tráfego do plano de dados, ou um balanceador de carga separado para o plano de dados. Para mais informações, consulte Configurar balanceamento de carga manual.

Role a tela para cima, se necessário, para preencher o marcador ADMIN_CLUSTER_NAME para a flag --admin-cluster-membership.

gcloud beta container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --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:

• USER_CLUSTER_NAME: um nome de sua escolha pelo cluster de usuário. O nome não pode ser alterado após a criação do cluster. O nome precisa:
  • conter no máximo 40 caracteres
  • conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
  • começam com um caractere alfabético
  • terminar com um caractere alfanumérico.
• FLEET_HOST_PROJECT_ID: o ID do projeto em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado. O projeto host da frota não pode ser alterado após a criação do cluster.
• ADMIN_CLUSTER_NAME: o nome do cluster de administrador que gerencia o cluster de usuário. O nome do cluster de administrador é o último segmento do nome totalmente especificado que identifica o cluster no Google Cloud: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
• 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 usuário 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: os clusters do Anthos na versão bare metal para o cluster de usuário.
• YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se você não incluir a flag --admin-users como a criadora do cluster, por padrão, você receberá privilégios de administrador do cluster. No entanto, se você incluir --admin-users para designar outro usuário como administrador, o padrão será substituído e será necessário incluir seu endereço de e-mail e o endereço de e-mail do outro administrador. Por exemplo, para adicionar dois administradores:

      --admin-users=[e-mail] \
      --admin-users=[e-mail]

  Quando o cluster é criado, a API Anthos On-Prem aplica as políticas de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces.

  Observação: além das políticas do RBAC do Kubernetes, você precisa conceder alguns papéis do Identity and Access Management (IAM) aos usuários que não são proprietários de projetos. Para detalhes sobre como conceder os papéis do IAM, consulte Conceder os papéis necessários.

Nós do plano de controle

• --control-plane-node-configs: 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 sinalização 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 de um cluster.

  O valor do 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.

  Também é possível incluir as seguintes sinalizações:

• --control-plane-node-labels: use essa sinalização para adicionar rótulos a todos os nós do plano de controle. Separe a lista de pares de chave-valor com vírgulas.

    --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2

• --control-plane-node-taints: use essa sinalização para adicionar taints a todos os nós do plano de controle. Cada taint é um par de chave-valor associado a um efeito, que precisa ser um dos seguintes: PreferNoSchedule, NoSchedule ou NoExecute.

  O exemplo a seguir adiciona três nós aos nós do plano de controle. Todos os nós são rotulados com cp-node-pool-key=cp-node-pool-value e têm o taint 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 você decidiu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário.

  Exemplo: --control-plane-vip=203.0.113.3

• CONTROL_PLANE_LB_PORT: a porta em que o balanceador de carga veicula o servidor da API Kubernetes.

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

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

  Exemplo: --ingress-vip=10.251.134.80

  O endereço IP do VIP de entrada precisa estar em um dos pools de endereços do MetalLB.

CIDRs de pods e serviços

• SERVICE_CIDR_BLOCK: um intervalo de endereços IP no formato CIDR que será usado para serviços no cluster. O intervalo CIDR precisa estar entre /18 e /8, em que /8 fornece mais 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, que será usado para pods no cluster. O intervalo CIDR precisa estar entre /18 e /8, em que /8 fornece mais endereços IP.

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

Armazenamento

1. --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.
2. --lvp-share-storage-class: esse é o StorageClass a ser usado para criar volumes permanentes. O StorageClass é criado durante a criação do cluster.
3. --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.
4. --lvp-node-mounts-config-storage: a classe de armazenamento com a qual os PVs são criados durante a criação do cluster.

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

Antes de executar o comando gcloud para criar o cluster, inclua --validate-only para validar a configuração especificada nas flags para o comando gcloud. Quando estiver tudo pronto para criar o cluster, remova essa flags e execute o comando.

Leva 15 minutos ou mais para criar o cluster de usuário. É possível visualizar o cluster no Console do Google Cloud na página Clusters do Anthos.

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

Criar um pool de nós

Depois que o cluster for criado, você precisará criar pelo menos um pool de nós antes de implantar cargas de trabalho. Um pool de nós é um modelo para os grupos de nós de trabalho criados nesse cluster. Com a CLI gcloud, primeiro você cria o cluster e depois adiciona um ou mais pools de nós ao cluster recém-criado.

gcloud beta 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:

• NODE_POOL_NAME: um nome de sua escolha para o pool de nós. O nome precisa:

  • conter no máximo 40 caracteres
  • conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
  • começam com um caractere alfabético
  • terminar com um caractere alfanumérico.

• USER_CLUSTER_NAME: o nome do cluster de usuário recém-criado

• FLEET_HOST_PROJECT_ID: o ID do projeto em que o cluster está registrado.

• REGION: a região do Google Cloud que você especificou ao criar o cluster.

• --node-configs: o endereço IPv4 de uma máquina de nó de worker. Especifique essa sinalização para cada nó. O valor da sinalização 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. É possível especificar apenas um node-ip por sinalização. Adicione essa sinalização novamente a cada nó do pool.

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

  Também é possível especificar o seguinte:

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

  • --node-taints=KEY=VALUE:EFFECT,... Uma lista separada por vírgulas de taints do Kubernetes aplicados a cada nó no pool. Os taints são pares de chave-valor associados a um efeito. Taints são usados com tolerâncias para a programação de pods. Especifique um dos seguintes para EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

O exemplo a seguir cria um pool de nós chamado default-pool em user-cluster- e adiciona dois nós ao pool. Todos os dois nós são rotulados com node-pool-key=node-pool-value e têm o taint dedicated=experimental:PreferNoSchedule,

gcloud beta 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

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Use a amostra de configuração básica a seguir para criar um cluster de usuário com o balanceador de carga MetalLB empacotado. Para mais informações, consulte a documentação de referência do google_gkeonprem_bare_metal_cluster.

1. Clone o repositório anthos-samples e mude para o diretório em que a amostra do Terraform está localizada:

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

   A amostra fornece um arquivo de variáveis de exemplo a ser transmitido para main.tf.

2. terraform.tfvars.samplefaça uma cópia do arquivo;

   cp terraform.tfvars.sample terraform.tfvars
   

   anthos-onprem-terraform/abm_user_cluster_metallb/terraform.tfvars.sample

   Ver no GitHub

   
   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"] }
   ]
   

3. Modifique os valores dos parâmetros em terraform.tfvars e salve o arquivo.

   A lista a seguir descreve as variáveis:

   • project_id: o ID do projeto em que você quer criar o cluster. O projeto selecionado também é usado como projeto host da frota. Precisa ser o mesmo projeto em que o cluster de administrador está registrado. Depois que o cluster de usuário é criado, ele é registrado automaticamente na frota do projeto selecionado. O projeto host da frota não pode ser alterado após a criação do cluster.

   • region: a região do Google Cloud em que a API Anthos On-Prem é executada. Especifique us-west1 ou outra região compatível.

   • admin_cluster_name: o nome do cluster de administrador que gerencia o cluster de usuário.

   • bare_metal_version: os clusters do Anthos na versão bare metal para o cluster de usuário. Especifique a mesma versão que o cluster de administrador ou uma versão não superior a uma versão secundária menor que o cluster de administrador.

   • cluster_name: um nome de sua escolha pelo cluster de usuário. O nome não pode ser alterado após a criação do cluster. O nome precisa:

     • conter no máximo 40 caracteres
     • conter apenas caracteres alfanuméricos minúsculos ou um hífen (-)
     • começam com um caractere alfabético
     • terminar com um caractere alfanumérico.

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

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

   • control_plane_vip: o endereço IP virtual (VIP) que você escolheu configurar no balanceador de carga para o servidor da API Kubernetes do cluster de usuário.

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

   • lb_address_pools: uma lista de mapas que definem os pools de endereços a serem usados pelo balanceador de carga do MetalLB. O VIP de entrada precisa estar em um desses pools.

   • admin_user_emails: uma lista de endereços de e-mail dos usuários que receberão privilégios administrativos no cluster. Adicione seu endereço de e-mail se você pretende administrar o cluster.

   Quando o cluster é criado, a API GKE On-Prem aplica as políticas de controle de acesso baseado em papel (RBAC) do Kubernetes ao cluster para conceder a você e a outros usuários administradores o papel clusterrole/cluster-admin do Kubernetes, que fornece acesso total a todos os recursos do cluster em todos os namespaces. Isso também permite que os usuários façam login no console usando a identidade do Google.

4. Salve 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 provedor do Google Cloud.

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

   terraform plan
   

7. Aplique o plano do Terraform para criar o cluster de usuário:

   terraform apply
   

   Leva 15 minutos ou mais para criar o cluster de usuário. É possível visualizar o cluster no Console do Google Cloud na página Clusters do Anthos.

conecte-se ao cluster de usuário

Quando você cria um cluster de usuário no console, o cluster é configurado com as políticas de controle de acesso baseado em papel (RBAC, na sigla em inglês) do Kubernetes para que você possa fazer login no cluster usando sua identidade do Google Cloud. Ao criar um cluster de usuário com a CLI gcloud, por padrão, você recebe essas políticas do RBAC se não incluir a flag --admin-users. Se você incluir --admin-users para designar outro usuário como administrador, o padrão será substituído e será necessário incluir seu endereço de e-mail e o endereço de e-mail do outro administrador. Para mais informações sobre as políticas de IAM e RBAC necessárias, consulte Configurar a autenticação de identidade do Google.

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

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

• Use o gateway do Connect para acessar o cluster em um computador que tenha a CLI do Google Cloud instalada. Nesse caso, kubectl usa o kubeconfig do gateway do Connect, que encaminha o tráfego com segurança para o endpoint particular em seu nome.

• Para acesso direto a endpoints particulares, crie um arquivo kubeconfig na estação de trabalho do administrador e gerencie o cluster.

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

Conectar gateway

1. Inicialize a CLI gcloud para uso com o projeto host da frota ou execute os seguintes comandos para fazer login com sua Conta do Google, defina o projeto host da frota como o padrão e atualize os componentes:

   gcloud auth login
   gcloud config set project PROJECT_ID
   gcloud components update
   

2. Busque as credenciais de cluster usadas para interagir com o gateway do Connect. No comando a seguir, substitua MEMBERSHIP_NAME pelo nome do seu cluster. Em clusters do Anthos em bare metal, o nome da associação é igual ao nome do cluster.

   gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
   

   Esse comando retorna um Conectar-se específico ao gatewaykubeconfig especial que permite a conexão com o cluster por meio do gateway.

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

kubectl get namespaces

Estação de trabalho do administrador

Use o comando bmctl get credentials para recuperar um arquivo kubeconfig para o cluster de usuário recém-criado.

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

Substitua:

• CLUSTER_NAME: o nome do cluster de usuário de destino.

• ADMIN_KUBECONFIG_PATH especifica o caminho até o arquivo kubeconfig do cluster de administrador;

Um kubeconfig com as credenciais do cluster de usuário é gravado em um arquivo, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. O TIMESTAMP no nome do arquivo indica a data e a hora em que o arquivo foi criado.

Como esse arquivo contém credenciais de autenticação para o cluster, armazene-o em um local seguro com acesso restrito.

A seguir

• Proteger seus contêineres usando o SELinux
• Gerenciar clusters pelo console do Google Cloud