Gerenciar clusters pelo console do Google Cloud

Neste documento, explicamos como disponibilizar clusters do Anthos em Bare Metal para gerenciamento no Console do Google Cloud. Isso inclui gerenciamento básico, como a capacidade de fazer login em clusters e a visualização das cargas de trabalho, além de como ativar o gerenciamento do ciclo de vida do cluster para fazer upgrade, atualizar e excluir clusters.

Membros da frota e o console

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

Nos clusters do Anthos em bare metal, um cluster de usuário é registrado em uma frota no momento da criação:

  • Ao criar um cluster usando bmctl, especifique seu projeto host da frota na seção gkeConnect do arquivo de configuração do cluster. Clusters do Anthos em bare metal usam essas informações para registrar seu cluster no projeto especificado da frota.

  • Quando você cria um cluster de usuário no console, o cluster se torna automaticamente um membro da frota no projeto selecionado no console.

Os membros da frota fora do Google Cloud, como os clusters do Anthos em bare metal, são exibidos no console no projeto host da frota, junto com outros clusters de frotas, como o GKE no Google Cloud. Até que ponto você pode gerenciar clusters do Anthos em Bare Metal do 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ê tiver ativado o gerenciamento do ciclo de vida do cluster para o cluster, também será possível fazer upgrade, atualizar ou excluir clusters de usuários usando o console. Para fazer isso, o cluster precisa ser gerenciado por um serviço chamado API Anthos On-Prem. Para clusters de usuários criados no console, o gerenciamento do ciclo de vida do cluster é ativado no momento da criação do cluster ou é possível ativar esse recurso posteriormente para clusters de usuários criados usando bmctl. 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 de frota são exibidos nas páginas Clusters do Anthos e Clusters do GKE no console. Isso oferece uma visão geral de toda a frota e, para clusters do Anthos em bare metal, permite ver quais clusters são gerenciados pela API GKE On-Prem.

Para ver os clusters da frota:

  1. No console, acesse a página de clusters do Anthos.

    Acesse a página de clusters do Anthos

  2. Selecione o projeto do Google Cloud.

    • Se Anthos bare metal for exibido na coluna Tipo, o cluster será gerenciado pela API GKE On-Prem.

    • Se Externo for exibido na coluna Tipo, o cluster não vai ser gerenciado pela API Anthos On-Prem.

Para ver mais detalhes sobre um cluster, os usuários precisam fazer login e autenticação nele. Para fazer isso, você precisa:

Configurar a autenticação

Conforme descrito anteriormente, todos os clusters da frota aparecem nas listas de clusters do GKE e do Anthos no console. No entanto, para ver mais detalhes, como nós e cargas de trabalho, e realizar tarefas de gerenciamento do ciclo de vida do cluster se o recurso estiver ativado, os usuários precisam fazer login e autenticação no cluster. Para fazer isso, os clusters registrados precisam ser configurados com um dos seguintes métodos de autenticação:

  • Identidade do Google: esta opção permite que os usuários façam login usando a 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 como configurá-lo em mais detalhes abaixo em Configurar a autenticação de identidade do Google.

  • OpenID Connect (OIDC): com essa opção, os usuários fazem login em clusters pelo 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:

  • 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 Google Cloud IAM. Para gerenciar o ciclo de vida do cluster no console, é necessário conceder alguns papéis do IAM a usuários que não sejam proprietários de projetos:

  • Para permitir que os usuários acessem o console, conceda pelo menos os seguintes papéis:

    • roles/container.viewer Com esse papel, os usuários podem ver a página de clusters do GKE e outros recursos do contêiner no console. Para ver detalhes sobre as permissões incluídas nesse papel ou conceder um papel com permissões de leitura/gravação, consulte Papéis do Kubernetes Engine na documentação do IAM.

    • roles/gkehub.viewer. Esse papel permite que os usuários vejam os clusters fora do Google Cloud no console. Para ver detalhes sobre as permissões incluídas nesse papel ou conceder um papel com permissões de leitura/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 Anthos 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 usuário criados no console são gerenciados automaticamente pela API Anthos On-Prem e permitem realizar tarefas de gerenciamento de ciclo de vida do cluster no console. Se você quiser ativar esse recurso para clusters de usuários criados usando bmctl, siga as etapas em Configurar um cluster de usuário para ser gerenciado pela API Anthos On-Prem. Quando o gerenciamento do ciclo de vida do cluster está ativado, é possível atualizar os clusters no console:

  • Atualizar clusters de usuários
  • Adicionar ou remover pools de nós em clusters de usuários
  • Excluir clusters de usuários

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 poder ver e interagir com clusters no console do Google Cloud na Lista de clusters do GKE e na Lista de clusters do Anthos.

  • Os usuários precisam ser adicionados às políticas de controle de acesso baseado em papel (RBAC, na sigla em inglês) do Kubernetes de que o gateway do Connect precisa acessar o servidor da API Kubernetes do cluster pelo 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, é necessário configurar políticas de controle de acesso baseado em papéis (RBAC) do Kubernetes em cada cluster. Se você criou o cluster no console, a API Anthos On-Prem adiciona a conta de usuário como administrador e cria políticas de RBAC apropriadas que concedem acesso administrativo total ao cluster.

CLI da gcloud

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

  1. Execute os seguintes comandos para fazer login na sua Conta do Google e atualizar os componentes:

    gcloud auth login
gcloud components update

  2. 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 forma exclusiva. Nos clusters do Anthos em bare metal, os nomes da associação e do cluster são os mesmos.
    • 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 do cluster em todos os namespaces, especifique clusterrole/cluster-admin. 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=foo@example.com,test-acct@test-project.iam.gserviceaccount.com.
    • PROJECT_ID O ID do projeto host da frota.
    • KUBECONFIG_PATH: o caminho de arquivo local em que o kubeconfig que contém uma entrada do cluster é armazenado.

    • 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 você usar o contexto atual, verifique se ele funciona para acessar o cluster. Para isso, basta executar um comando simples 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 do Connect.

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

bmctl

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

  1. Adicione a seção clusterSecurity.authorization ao arquivo de configuração do cluster. Especifique o endereço de e-mail e o endereço de e-mail de outros usuários que precisam administrar o cluster. Por exemplo:

    ...
clusterSecurity:
  authorization:
    clusterAdmin:
      gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com]
...

  2. Atualize o cluster:

    bmctl update cluster \
    -c CLUSTER_NAME \
    --kubeconfig=KUBECONFIG

    Faça as mudanças a seguir:

    • Substitua CLUSTER_NAME pelo nome do cluster que você quer atualizar.
    • Se o cluster for de autogerenciamento, como o cluster de administrador ou independente, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster. Se o cluster for de usuário, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de administrador.

Mais informações