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

Criar clusters de usuários

No Google Distributed Cloud, os clusters de usuário executam suas cargas de trabalho e, em uma arquitetura de vários clusters, os clusters de usuário são criados e gerenciados por um cluster de administrador.

Depois de criar um cluster de administrador, chamar o comando bmctl create config cria um arquivo yaml que pode ser editado para definir o cluster de usuário. Para aplicar a configuração e criar o cluster de usuário, use o comando bmctl create cluster. As verificações de simulação são aplicáveis aos clusters de usuários criados com o comando bmctl create cluster.

Manter as cargas de trabalho fora do cluster de administrador protege dados administrativos confidenciais, como chaves SSH armazenadas no cluster de administrador, contra aqueles que não precisam acessar essas informações. Além disso, manter os clusters de usuários separados uns dos outros oferece uma boa segurança geral para as cargas de trabalho.

Pré-requisitos

O último bmctl é transferido por download (gs://anthos-baremetal-release/bmctl/1.30.100-gke.96/linux-amd64/bmctl) do Cloud Storage.
cluster de administrador de trabalho com acesso ao servidor da API do cluster (o controlPlaneVIP);
Os nós do cluster de administrador têm conectividade de rede para todos os nós no cluster do usuário de destino.
A estação de trabalho que executa bmctl tem conectividade de rede com todos os nós nos clusters de usuários de destino.
A estação de trabalho do administrador pode estabelecer uma conexão SSH com cada um dos nós do cluster de usuário.
A conta de serviço de registro do Connect é configurada no cluster de administrador para uso com o Connect.

Ativar o SELinux

Se você quiser ativar o SELinux para proteger seus contêineres, verifique se o SELinux está ativado no modo Enforced em todas as máquinas host. A partir da versão 1.9.0 ou mais recente do Google Distributed Cloud, é possível ativar ou desativar o SELinux antes ou depois da criação do cluster ou dos upgrades dele. O SELinux é ativado por padrão no Red Hat Enterprise Linux (RHEL). Se o SELinux estiver desativado em suas máquinas host ou se você não tiver certeza, consulte Como proteger seus contêineres usando o SELinux para instruções sobre como ativá-lo.

O Google Distributed Cloud oferece suporte ao SELinux apenas em sistemas RHEL.

Criar um arquivo de configuração do cluster de usuário

O arquivo de configuração para criar um cluster de usuário é quase exatamente igual ao usado para criar um cluster de administrador. A única diferença é que você remove a seção de configuração de credenciais locais para fazer com que a configuração seja um conjunto válido de recursos do Kubernetes. A seção de configuração fica na parte superior do arquivo na seção bmctl configuration variables. Veja exemplos de configurações em Clusters de usuário nas amostras de configuração de clusters.

Por padrão, os clusters de usuário herdam as credenciais do cluster de administrador que as gerencia. É possível substituir parcialmente todas ou algumas dessas credenciais.

Crie um arquivo de configuração do cluster de usuário com o comando bmctl create config:
```
bmctl create config -c USER_CLUSTER_NAME
```
Por exemplo, emita o seguinte comando para criar um arquivo de configuração para um cluster de usuário chamado user1:
```
bmctl create config -c user1
```
O arquivo é gravado em bmctl-workspace/user1/user1.yaml. O caminho genérico para o arquivo é bmctl-workspace/CLUSTER NAME/CLUSTER_NAME.yaml.
Edite o arquivo de configuração com as seguintes alterações:
- Remova os caminhos do arquivo das credenciais locais da configuração:
```
...
  gcrKeyPath: (path to GCR service account key)
  sshPrivateKeyPath: (path to SSH private key, used for node access)
  gkeConnectAgentServiceAccountKeyPath: (path to Connect agent service account key)
  gkeConnectRegisterServiceAccountKeyPath: (path to Hub registration service account key)
  cloudOperationsServiceAccountKeyPath: (path to Cloud Operations service account key)
...
```
- Altere a configuração para especificar um tipo de cluster de user em vez de admin:
```
...
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create
  #   user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster
  #   components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user
  #   workloads, but does not manage other clusters.
  type: user
...
```
- Registre seus clusters em uma frota especificando o ID do projeto no campo gkeConnect.projectID. Esse projeto é chamado de projeto host da frota.
```
...
gkeConnect:
   projectID: my-project-123
...
```
  - Como opção, é possível adicionar gkeConnect.location à especificação do cluster para especificar a região do Google Cloud em que a frota os serviços do Connect são executados. Esta assinatura regional restringe o tráfego da frota de serviço na sua região. Se você incluir gkeConnect.location na especificação do cluster, a região especificada precisa ser a mesma da região configurada em clusterOperations.location. Se as regiões não forem iguais, a criação do cluster falhará.
- Se a API GKE On-Prem estiver ativada no projeto do Google Cloud, todos os clusters do projeto são registrados na API GKE On-Prem automaticamente na região configurada em clusterOperations.location.
  - Se você quiser registrar todos os clusters do projeto na API GKE On-Prem, siga as etapas em Antes de começar para ativar e usar a API GKE On-Prem no projeto.
  - Se você não quiser registrar o cluster na API GKE On-Prem, inclua esta seção e defina gkeOnPremAPI.enabled como false. Se você não quiser registrar clusters no projeto, desative gkeonprem.googleapis.com (o nome do serviço da API GKE On-Prem) no projeto. Para instruções, consulte Como desativar serviços.
- Especifique o endereço IP do nó do plano de controle.
```
...
# Sample control plane config
controlPlane:
 nodePoolSpec:
   nodes:
   - address: 10.200.0.20
...
```
- Verifique se as especificações do cluster de administrador e de usuário para os VIPs e pools de endereços do balanceador de carga são complementares e não se sobrepõem a clusters. No exemplo a seguir, mostramos um exemplo de par de configuração de clusters de administrador e usuário, especificando o balanceamento de carga e os pools de endereços:
```
...
# Sample admin cluster config for load balancer and address pools
  loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.49
      ingressVIP: 10.200.0.50
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.50-10.200.0.70
...
...
# Sample user cluster config for load balancer and address pools
loadBalancer:
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
...
```
  Os outros arquivos de configuração do cluster do usuário são iguais aos da configuração do cluster do administrador.
- Especifique a densidade de pods dos nós do cluster:
```
...
# NodeConfig specifies the configuration that applies to all nodes in the cluster.
nodeConfig:
  # podDensity specifies the pod density configuration.
  podDensity:
    # maxPodsPerNode specifies at most how many pods can be run on a single node.
    maxPodsPerNode: 110
...
```
  Para clusters de usuários, os valores permitidos para maxPodsPerNode são 32-250. Se não especificado, o valor padrão será 110. Depois que o cluster é criado, esse valor não pode ser atualizado.
  
  A densidade de pods também é limitada pelos recursos de IP disponíveis do cluster. Para detalhes, consulte Rede de pod.

Criar o cluster de usuário

Emita o comando bmctl para aplicar a configuração do cluster de usuário revisado e criar o cluster:

bmctl create cluster -c USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

Substitua:

USER_CLUSTER_NAME especifica o nome do cluster criado na seção anterior.
ADMIN_KUBECONFIG especifica o caminho até o arquivo kubeconfig do cluster de administrador;

Por exemplo, para um cluster de usuários chamado user1 e um arquivo kubeconfig do cluster de administrador com o caminho kubeconfig bmctl-workspace/admin/admin-kubeconfig, o comando seria:

bmctl create cluster -c user1 --kubeconfig bmctl-workspace/admin/admin-kubeconfig

Exemplos de configurações de cluster de usuário

Para exemplos de configurações de cluster de usuário, consulte Clusters de usuário nas amostras de configuração de cluster.