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

Esta página foi traduzida pela API Cloud Translation.

Gerenciar clusters pelo console do Google Cloud

Este documento explica como disponibilizar para gerenciamento os clusters de administrador e usuário criados com o software Google Distributed Cloud em bare metal no Console do Google Cloud. Os recursos de gerenciamento de clusters incluem fazer login, visualizar cargas de trabalho, atualizar, atualizar e excluir clusters.

Membros da frota e o console

Todos os clusters precisam ser membros de uma frota, uma maneira unificada de visualizar e gerenciar vários clusters e as cargas de trabalho deles. Cada frota de clusters é associada a um projeto host da frota.

Todos os clusters são registrados em uma frota no momento da criação:

Ao criar um cluster usando bmctl, especifique seu projeto de host de frota na seção gkeConnect do arquivo de configuração do cluster. O cluster se torna um membro da frota do projeto especificado.
Quando você cria um cluster de administrador ou de usuário com um cliente padrão da API GKE On-Prem (o console, a Google Cloud CLI ou o Terraform), o cluster se torna um membro da frota no projeto especificado.

Os membros da frota fora do Google Cloud, como o Google Distributed Cloud, são exibidos no console no projeto host da frota, com outros clusters de frota, como o GKE no Google Cloud. O limite em que é possível gerenciar clusters bare metal no console depende do seguinte:

Se você tiver configurado a autenticação, poderá fazer login nos clusters e ver as cargas de trabalho e outros detalhes.
Se você ativou o gerenciamento do ciclo de vida do cluster, é possível fazer upgrade dos clusters de administrador e de usuários usando o console. Também é possível usá-lo para atualizar e excluir clusters de usuário. Se esse recurso não estiver ativado, só será possível gerenciar o ciclo de vida do cluster usando bmctl na estação de trabalho do administrador.

Ver clusters registrados

Todos os clusters são exibidos na página Clusters do GKE no console. Isso fornece uma visão geral de toda a frota e, para o Google Distributed Cloud, permite ver quais clusters são gerenciados pela API GKE On-Prem.

Para ver os clusters da frota:

No console, acesse a página de visão geral dos clusters do Google Kubernetes Engine.

Acesse os clusters do GKE
Selecione o projeto do Google Cloud.
- Se Bare metal for exibido na coluna Tipo, o cluster será gerenciado pela API GKE On-Prem. Apenas clusters de administrador e usuário podem ser gerenciados pela API GKE On-Prem.
- Se Externo for exibido na coluna Tipo, o cluster não vai ser gerenciado pela API GKE On-Prem.

Para ver mais detalhes sobre um cluster, faça login e autentique-se nele. Para fazer isso, siga estas etapas:

Configurar um método de autenticação
Conceder aos usuários papéis específicos do Identity and Access Management

Configurar a autenticação

Conforme descrito anteriormente, todos os clusters aparecem na página de clusters do GKE no console. No entanto, para ver mais detalhes, como nós e cargas de trabalho (e para realizar tarefas de gerenciamento do ciclo de vida do cluster, se o recurso estiver ativado), você precisa fazer login e autenticar no cluster. Para isso, é preciso configurar os clusters com um dos seguintes métodos de autenticação:

Identidade do Google: essa opção permite fazer login usando sua identidade do Google Cloud, que é o endereço de e-mail associado à sua conta do Google Cloud. Use essa opção se os usuários já tiverem acesso ao Google Cloud com uma identidade do Google. Se você criou o cluster no console, pode fazer login nele usando sua identidade do Google, mas precisará configurar a autenticação para outros usuários.

O login com a identidade do Google é a abordagem mais simples para autenticação no console. Portanto, descrevemos em mais detalhes como configurar isso em Configurar a autenticação de identidade do Google.
OpenID Connect (OIDC): essa opção permite fazer login nos clusters no console usando a identidade de um provedor de identidade OIDC de terceiros, como o Okta ou o Microsoft AD FS. Use essa opção se os usuários tiverem nomes de usuário, senhas e associações de grupo de segurança existentes do seu provedor. Saiba como configurar a autenticação do OIDC de terceiros para seus clusters nos guias a seguir:
- Configurar clusters do GKE Identity Service com OIDC: este guia mostra como configurar a autenticação do OIDC em um cluster por cluster.
- Configurar o GKE Identity Service em uma frota: essa opção permite configurar o OIDC no nível da frota.
Token do portador: se as soluções anteriores fornecidas pelo Google não forem adequadas para sua organização, configure a autenticação usando uma conta de serviço do Kubernetes e usando o respectivo token do portador para fazer login. Para mais detalhes, consulte Configurar usando um token do portador.

Conceder os papéis necessários

O acesso ao console é controlado pelo Identity and Access Management (IAM). Para gerenciar o ciclo de vida do cluster no console, você precisa conceder alguns papéis do IAM a usuários que não são proprietários do projeto:

Para permitir que os usuários acessem o console, conceda pelo menos os seguintes papéis:
- roles/container.viewer: esse papel permite que os usuários visualizem a página Clusters do GKE e outros recursos de contêiner no console. Para detalhes sobre as permissões incluídas nesse papel ou para conceder um papel com permissões de leitura e gravação, consulte Papéis do Kubernetes Engine na documentação do IAM.
- roles/gkehub.viewer: esse papel permite que os usuários visualizem clusters fora do Google Cloud no console. Para detalhes sobre as permissões incluídas nesse papel ou para conceder um papel com permissões de leitura e gravação, consulte Papéis do GKE Hub na documentação do IAM.
Para permitir que os usuários gerenciem o ciclo de vida do cluster no console, conceda o papel roles/gkeonprem.admin do IAM. O papel de IAM roles/gkeonprem.admin concede aos usuários acesso administrativo à API GKE On-Prem, que o console usa para gerenciar o ciclo de vida do cluster. Para ver detalhes sobre as permissões incluídas nesse papel, consulte Papéis do GKE On-Prem na documentação do IAM.

Os comandos a seguir mostram como conceder os papéis mínimos necessários para gerenciar o ciclo de vida do cluster no console:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkeonprem.admin

onde:

PROJECT_ID é o projeto host da frota. Para clusters criados usando bmctl, esse é o projeto que você configurou na seção gkeConnect do arquivo de configuração do cluster de usuário. Para clusters criados no console, esse é o projeto que você escolheu quando o cluster foi criado.
MEMBER é o endereço de e-mail do usuário no formato user:emailID, por exemplo: user:alice@example.com

Ativar o gerenciamento do ciclo de vida do cluster no console

Os clusters de administrador e usuário criados usando ferramentas padrão (o console, a CLI gcloud ou o Terraform) são registrados automaticamente na API GKE On-Prem, que permite executar tarefas de gerenciamento do ciclo de vida do cluster no console. No Google Distributed Cloud 1.16 e versões mais recentes, quando você cria clusters de usuário e administrador usando bmctl, eles são registrados na API GKE On-Prem por padrão. Se você precisar registrar um cluster na API GKE On-Prem, siga as etapas em Configurar um cluster para ser gerenciado pela API GKE On-Prem.

Configurar a autenticação de identidade do Google

Para permitir que os usuários façam login no cluster usando a identidade do Google, configure o seguinte:

Os usuários precisam de papéis específicos do Identity and Access Management (IAM) para ver e interagir com clusters no console da página Clusters do GKE.
Os usuários precisam ser adicionados às políticas de controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes de que o gateway de conexão precisa para acessar o servidor da API Kubernetes do cluster usando o agente do Connect.

Configurar a autorização do RBAC

O servidor da API Kubernetes de cada cluster precisa ser capaz de autorizar solicitações originadas do console. Para configurar a autorização, você precisa configurar políticas de controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes para usuários em cada cluster. Sua Conta do Google é adicionada como administrador com acesso total a um cluster de usuário nos seguintes casos:

Você criou o cluster de usuário no console.
Você criou o cluster de usuário usando a CLI gcloud e sua Conta do Google foi especificada na sinalização --admin-users no comando de criação do cluster.
Você criou o cluster de usuário usando o Terraform e sua Conta do Google foi especificada no campo authorization.admin_users.username.
Você criou o cluster de usuário usando bmctl e configurou sua Conta do Google em clusterSecurity.authorization.clusterAdmin.gcpAccounts.

É possível adicionar outras pessoas como administradores após a criação do cluster. É possível usar qualquer uma das maneiras a seguir para conceder acesso administrativo ao cluster. Dois comandos gcloud diferentes são fornecidos.

O comando gcloud ... generate-gateway-rbac precisa ser executado na estação de trabalho do administrador porque exige acesso ao kubeconfig e ao contexto do cluster (que normalmente estão apenas na estação de trabalho do administrador). O comando generate-gateway-rbac permite personalizar as políticas de RBAC, mas os endereços de e-mail do usuário não serão exibidos como administradores na seção Detalhes do cluster no console.
O comando gcloud ... update pode ser executado na estação de trabalho do administrador ou em qualquer computador que tenha acesso à API GKE On-Prem.

Se você criou um cluster de administrador no console do Google Cloud, recebe acesso somente leitura a ele. Se você quiser receber o papel clusterrole/cluster-admin, alguém com esse papel precisará adicionar você usando o comando gcloud ... generate-gateway-rbac.

`generate-gateway-rbac`

Para aplicar as políticas do RBAC aos usuários, siga estas etapas na estação de trabalho do administrador:

Execute o seguinte comando para atualizar os componentes (se necessário):
```
gcloud components update
```
Gere e aplique as políticas do RBAC ao cluster para usuários e contas de serviço:
```
gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply
```
Substitua:
- MEMBERSHIP_NAME: o nome usado para representar o cluster na frota dele de maneira exclusiva. No Google Distributed Cloud, o nome da assinatura e do cluster são iguais.
- ROLE: o papel do Kubernetes que você quer conceder aos usuários no cluster. Para conceder aos usuários acesso total a todos os recursos no cluster em todos os namespaces, especifique clusterrole/cluster-admin. Para fornecer acesso somente leitura, especifique clusterrole/view. Para restringir o acesso, crie um papel personalizado, por exemplo: role/mynamespace/namespace-reader. É preciso que o papel personalizado exista antes da execução do comando.
- USERS: os endereços de e-mail dos usuários (contas de usuário ou contas de serviço) aos quais você quer conceder as permissões como uma lista separada por vírgulas. Por exemplo, --users=222larabrown@gmail.com,test-acct@test-project.iam.gserviceaccount.com.
- PROJECT_ID O ID do projeto host da frota.
- KUBECONFIG_PATH: o caminho local do arquivo kubeconfig que contém uma entrada para o cluster.
- KUBECONFIG_CONTEXT: o contexto do cluster como ele aparece no arquivo kubeconfig. É possível conseguir o contexto atual pela linha de comando executando kubectl config current-context. Independentemente de usar o contexto atual ou não, verifique se ele funciona para acessar o cluster executando um comando como:
```
kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT
```
Depois de executar gcloud container fleet memberships generate-gateway-rbac, você verá algo como o seguinte no fim da saída, de maneira truncada para facilitar a leitura:
```
Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
Applying the generate RBAC policy to cluster with kubeconfig: /usr/local/google/home/foo/.kube/config, context: kind-kind
Writing RBAC policy for user: foo@example.com to cluster.
Successfully applied the RBAC policy to cluster.
```
Esse é o contexto para acessar o cluster pelo gateway de conexão.

Para mais detalhes sobre o comando generate-gateway-rbac, consulte o guia de referência da CLI gcloud.

`update`

Execute o seguinte comando para atualizar os componentes:
```
gcloud components update
```
Para cada usuário que precisa receber o papel clusterrole/cluster-admin, inclua a sinalização --admin-users e execute o comando a seguir. Não é possível especificar vários usuários em uma única sinalização. Inclua sua Conta do Google no comando, porque ele substitui a lista de permissões pelos usuários especificados no comando.
```
gcloud container bare-metal clusters update USER_CLUSTER_NAME \
  --admin-users YOUR_GOOGLE_ACCOUNT \
  --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
```

Além de conceder o papel clusterrole/cluster-admin do Kubernetes, o comando concede as políticas do RBAC de que os usuários precisam acessar o cluster por meio do gateway de conexão.

bmctl