Criar políticas para um cluster multilocatário

Neste tutorial, mostramos como usar o Config Sync e o Kustomize para configurar políticas para namespaces em um cluster multilocatário.

No Kubernetes, um locatário pode ser uma equipe ou uma carga de trabalho. Para clusters multilocatários, a prática recomendada é criar um namespace para cada locatário. Em seguida, cada namespace poderá ter políticas adequadas às diferentes necessidades. Use o Config Sync para aplicar essas políticas de maneira consistente a cada locatário diferente.

Arquitetura do repositório

Neste tutorial, você configura o Config Sync para sincronizar com as configurações no diretório namespace-specific-policy/ do repositório de amostras do Anthos Config Management. Esse diretório contém os seguintes diretórios e arquivos:

├── configsync
│   ├── tenant-a
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   ├── tenant-b
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   └── tenant-c
│       ├── ~g_v1_namespace_default.yaml
│       ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│       ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│       └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
├── configsync-src
│   ├── base
│   │   ├── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── networkpolicy.yaml
│   │   ├── rolebinding.yaml
│   │   └── role.yaml
│   ├── tenant-a
│   │   └── kustomization.yaml
│   ├── tenant-b
│   │   └── kustomization.yaml
│   └── tenant-c
│       └── kustomization.yaml
├── README.md
└── scripts
    └── render.sh

Este repositório é um não estruturado. Isso proporciona flexibilidade para organizar as configurações da maneira que você quiser, o que é útil principalmente ao trabalhar com o Kustomize.

Nesse repositório, há três namespaces para três locatários diferentes: tenant-a, tenant-b e tenant-c. Cada um dos diretórios de namespace contém configurações para Roles, RoleBindings e NetworkPolicies. O diretório configsync- src contém a configuração no formato kustomize. O diretório configconfig-src contém a configuração no formato kustomize. Há uma base e três sobreposições tenant-a, tenant-b e tenant-c.

Objetivos

• Atualizar uma sobreposição do Kustomize.

• Criar um cluster que possa ser usado com o Config Sync.

• Sincronizar as políticas no repositório Git com um cluster.

• Verificar se o cluster está sincronizando com as configurações no repositório.

Custos

Neste tutorial, usamos os seguintes componentes faturáveis do Google Cloud:

• GKE

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Limpeza.

Antes de começar

Antes de iniciar este tutorial, conclua as seguintes tarefas:

1. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Observação: se você não pretende manter os recursos criados neste procedimento, crie um projeto novo em vez de selecionar um que já existe. Depois de concluir essas etapas, é possível excluir o projeto. Para fazer isso, basta remover todos os recursos associados a ele.

   Acessar o seletor de projetos

2. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como verificar se o faturamento está ativado em um projeto.

3. Crie ou tenha acesso a uma conta do GitHub.

4. Instale o Kustomize executando o seguinte comando:

   gcloud components install kustomize
   

É útil ter alguma familiaridade com o Git e o Kustomize.

Atualizar um arquivo do Kustomize

Na seção a seguir, você atualiza um arquivo Kustomize no repositório para atualizar as políticas aplicadas a tenant-a.

Preparar o ambiente

Para preparar o ambiente, conclua as seguintes etapas:

1. Bifurque o repositório:

   1. Acesse o repositório do diretório de amostras do Anthos Config Management no GitHub.
   2. Clique em Bifurcar.

2. Clone o repositório bifurcado.

   git clone https://github.com/GITHUB_USERNAME/anthos-config-management-samples
   

   Substitua GITHUB_USERNAME pelo nome de usuário do GitHub:

3. Navegue até o diretório que contém os exemplos usados neste tutorial:

   cd anthos-config-management-samples/namespace-specific-policy
   

Atualize uma sobreposição

Nesta seção, você atualizará uma sobreposição. Uma sobreposição é uma personalização que depende de outra personalização.

As etapas a seguir mostram como conceder um novo papel a tenant-a atualizando a sobreposição dele. acm-samples/namespace-specific-policy/configsync-src/tenant-a. Como você está atualizando apenas uma configuração, só será necessário atualizar uma sobreposição.

Para dar tenant-a a esse novo papel, siga estas etapas:

1. Crie um arquivo acessando a página a seguir no GitHub:

   github.com/GITHUB_USERNAME/anthos-config-management-samples/new/main/namespace-specific-policy/configsync-src/tenant-a
   

2. Nomeie o arquivo another-role.yaml.

3. Na janela Editar novo arquivo, cole o seguinte manifesto YAML para o novo papel:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: pod-reader
   rules:
   - apiGroups: [""]
     resources: ["pods"]
     verbs: ["get", "watch", "list"]
   

4. Clique em Confirmar novo arquivo.

   Agora é possível incluir a configuração do novo papel no arquivo kustomization.yaml.

5. Na pasta /namespace-specific-policy/configsync-src/tenant-a, abra kustomization.yaml e clique no ícone de edição (parecido com um lápis).

6. Na seção de recursos de kustomization.yaml, adicione - another-role.yaml:

   namespace: tenant-a
   
   resources:
   - ../base
   - another-role.yaml
   # The rest of the file is omitted
   

7. Clique em Confirmar alterações.

8. Após a atualização, recrie a saída do Kustomize para cada namespace executando o script render.sh:

   ./scripts/render.sh
   

9. Confirme e envie a atualização:

   git add .
   git commit -m 'update configuration'
   git push
   

Observação: neste tutorial, a saída do Kustomize é gravada em um diretório diferente na mesma ramificação no mesmo repositório Git. Também é possível gravar a saída do Kustomize em um repositório Git diferente, se quiser.

Criar e registrar um cluster do GKE

Nesta seção, você cria e configura um cluster que pode ser usado com o Config Sync.

Criar um cluster

Console

Para criar um cluster zonal com o Console do Google Cloud, execute as seguintes tarefas:

1. Acesse o menu do Google Kubernetes Engine no console.

   Acessar o Google Kubernetes Engine

2. Clique em Criar.

3. Na seção Padrão, clique em Configurar.

4. Na seção Princípios básicos do cluster, conclua o seguinte:

   1. Insira mt-cluster como o Nome do cluster.
   2. Na lista suspensa Zona, selecione us-central1-c.
   3. Não altere os outros campos.

5. No menu à esquerda, clique em default-pool e, na lista suspensa exibida, clique em Nós.

6. Na seção Programação, faça o seguinte:

   1. Na lista suspensa Tipo de máquina, selecione e2-standard-4.
   2. Mantenha os valores padrão em todos os outros campos.

7. No menu à esquerda, selecione Segurança.

8. Na seção Segurança, marque a caixa de seleção Ativar Identidade da carga de trabalho.

9. Clique em Criar. A criação do cluster pode levar alguns minutos.

gcloud

Para criar um cluster com a Google Cloud CLI, execute a seguinte tarefa:

gcloud container clusters create mt-cluster \
    --project PROJECT_ID \
    --zone us-central1-c \
    --release-channel regular \
    --machine-type "e2-standard-4" \
    --workload-pool=PROJECT_ID.svc.id.goog

Substitua PROJECT_ID pela ID do seu projeto.

Receba as credenciais de autenticação para o cluster

Depois de criar o cluster, você precisará das credenciais de autenticação para interagir com o cluster:

gcloud container clusters get-credentials mt-cluster --zone us-central1-c

Conceda a si mesmo as permissões de administrador

Depois que o cluster for criado, conceda a si mesmo o papel Administrador do GKE Hub de que você precisa para o Config Sync.

Observação: se você for proprietário do projeto, você já tem essa permissão e não precisa concluir as etapas a seguir.

Console

Para conceder a si mesmo permissões de administrador com o Console do Google Cloud, execute a seguinte tarefa:

1. No console, acesse a página IAM.

   Acessar a página IAM

2. Clique em Add.

3. No campo Novos membros, digite um endereço de e-mail. É possível adicionar indivíduos, contas de serviço ou Grupos do Google como membros.

4. Na lista suspensa Selecionar um papel, procure e selecione Administrador do GKE Hub.

5. Clique em Save.

gcloud

Para conceder a si mesmo permissão de administrador com a Google Cloud CLI, execute as seguintes tarefas:

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

Substitua:

• PROJECT_ID: ID do projeto
• MEMBER: um identificador do membro, que geralmente tem este formato: member-type:id Por exemplo, user:[e-mail]. Para ver uma lista completa dos valores que member pode ter, consulte a referência de vinculação de políticas.

Observação: para o tipo de membro user, o nome de domínio no identificador precisa ser do Google Workspace ou Cloud Identity. Para saber como configurar um domínio do Cloud Identity, consulte a visão geral do Cloud Identity.

Registrar o cluster

Depois que o cluster for criado, é possível registrá-lo em uma frota:

Console

Para registrar o cluster com o Console do Google Cloud, execute as seguintes tarefas:

1. No Console do Google Cloud, acesse a página Clusters do Anthos.

   Acessar a página de clusters do Anthos

2. Clique em Registrar cluster existente.

3. Ao lado de mt-cluster, clique em Registrar. Se você não encontrar esse cluster na lista, verifique se ele foi criado.

   Exemplo de saída:

   Cluster mt-cluster registered successfully as mt-cluster in project PROJECT_NAME.
   

gcloud

Para registrar seu cluster com a Google Cloud CLI, execute a seguinte tarefa:

gcloud beta container hub memberships register MEMBERSHIP_NAME \
 --gke-cluster=us-central1-c/mt-cluster \
 --enable-workload-identity

Substitua:

• MEMBERSHIP_NAME: o nome da assinatura que você escolhe para representar de maneira exclusiva o cluster que está sendo registrado na frota.

Configure o Config Sync

Nesta seção, você configura o Config Sync para que ele seja sincronizado com as políticas no diretório namespace-specific-policy/.

Para configurar o Config Sync, conclua as etapas a seguir.

Console

Para configurar o Config Sync com o Console do Google Cloud, execute as seguintes tarefas:

1. No console, acesse a página Anthos Config Management.

   Acessar o Anthos Config Management

2. Selecione mt-cluster e clique em Configurar.

3. Na seção Autenticação do repositório do Git para ACM, selecione Nenhuma e clique em Continuar.

4. Na seção Configurações do ACM para os clusters, faça o seguinte:

   1. No campo Versão, selecione uma versão 1.7 ou posterior.
   2. Marque a caixa de seleção Ativar Config Sync e preencha os seguintes campos:
      1. No campo URL, adicione https://github.com/GITHUB_USERNAME/anthos-config-management-samples
      2. No campo Ramificação, adicione main
      3. No campo Tag/Confirmação, adicione HEAD
      4. No campo Diretório de configuração, adicione namespace-specific-policy/configsync
      5. Deixe o campo Espera de sincronização em branco.
      6. Deixe o campo Proxy do Git em branco.
      7. Na lista suspensa Formato de origem, selecione não estruturado.

5. Clique em Concluído. Você será redirecionado para a página Anthos Config Management. Após alguns minutos, você verá Synced na coluna de status ao lado do cluster configurado.

gcloud

Para configurar o Config Sync com a Google Cloud CLI, execute as seguintes tarefas:

1. Crie um arquivo chamado apply-spec.yaml e copie o arquivo YAML a seguir nele.

   # apply-spec.yaml
   
   applySpecVersion: 1
   spec:
     configSync:
       # Set to true to install and enable Config Sync
       enabled: true
       sourceFormat: unstructured
       syncRepo: https://github.com/GITHUB_USERNAME/anthos-config-management-samples
       syncBranch: main
       secretType: none
       policyDir: namespace-specific-policy/configsync
   

   Substitua GITHUB_USERNAME pelo nome de usuário do GitHub:

2. Aplique o arquivo apply-spec.yaml:

    gcloud beta container hub config-management apply \
        --membership=MEMBERSHIP_NAME \
        --config=CONFIG_YAML_PATH \
        --project=PROJECT_ID
   

   Substitua:

   • MEMBERSHIP_NAME: o nome da assinatura escolhido ao registrar o cluster, é possível encontrar o nome com gcloud container fleet memberships list.
   • CONFIG_YAML_PATH: o caminho para o arquivo apply-spec.yaml
   • PROJECT_ID: o ID do projeto

Verificar se as políticas específicas do namespace estão sincronizadas

Agora que você instalou o Config Sync, verifique se as políticas específicas do namespace estão sincronizadas com o cluster usando o comando nomos status:

nomos status

O resultado será semelhante a:

gke_PROJECT_ID_us-central1-c_mt-cluster
  --------------------
  <root>   https:/github.com/GITHUB_USERNAME/anthos-config-management-samples/namespace-specific-policy/configsync@main
  SYNCED   bf8655aa
  Managed resources:
     NAMESPACE   NAME                                                             STATUS
                 namespace/foo                                                    Current
                 namespace/istio-system                                           Current
                 namespace/tenant-a                                               Current
                 namespace/tenant-b                                               Current
                 namespace/tenant-c                                               Current
     tenant-a    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-a    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-a    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-b    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-b    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-b    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-c    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-c    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-c    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current

Em seguida, confirme se os recursos existem no cluster. Os exemplos a seguir mostram como verificar alguns dos recursos de tenant-a.

1. Verifique se o RoleBinding para tenant-a existe:

   kubectl get RoleBinding/tenant-admin-rolebinding -n tenant-a
   

   Exemplo de saída:

   NAME                       ROLE                AGE
   tenant-admin-rolebinding   Role/tenant-admin   23h
   

2. Verifique se o Role para tenant-a existe:

   kubectl get Role/tenant-admin -n tenant-a
   

   Exemplo de saída:

   NAME           CREATED AT
   tenant-admin   2021-05-24T21:49:06Z
   

3. Verifique se a NetworkPolicy para tenant-a existe:

   kubectl get NetworkPolicy/deny-all -n tenant-a
   

   Exemplo de saída:

   NAME       POD-SELECTOR   AGE
   deny-all   <none>         23h
   

Ao usar esses comandos, é possível ver que cada namespace tem o próprio conjunto de políticas, seguindo a prática recomendada para clusters multilocatários.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto atual para seguir este tutorial, a exclusão dele incluirá quaisquer outras ações feitas no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja explorar vários tutoriais e guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. No console, acesse a página Gerenciar recursos.

   Acessar "Gerenciar recursos"

2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Exclua o diretório

Para limpar os namespaces e políticas do locatário para eles, recomendamos que você remova os diretórios que contêm a configuração do repositório Git:

rm -r acm-samples/namespace-specific-policy/configsync/tenant-*/*
git add .
git commit -m 'clean up'
git push

Quando a última confirmação do repositório raiz for sincronizada, os três namespaces tenant-a, tenant-b e tenant-c serão excluídos do cluster.

A seguir

• Descubra quais são as Práticas recomendadas para multilocação empresarial.
• Confira o conteúdo de migração de dados do Google Cloud. Confira o Centro de arquitetura do Cloud.