Visão geral do controlador de hierarquia

Este documento descreve o Controlador de hierarquias, um controlador do Kubernetes e controlador de admissão dinâmica que adiciona hierarquias aos namespaces do Kubernetes.

Namespaces hierárquicos

O Controlador de hierarquias introduz o conceito de namespaces hierárquicos, extensões de namespaces do Kubernetes que facilitam o gerenciamento de grupos de namespaces que compartilham um conceito comum de propriedade. Eles são especialmente úteis em clusters compartilhados por várias equipes, mas os proprietários não precisam ser pessoas. Por exemplo, talvez você queira transformar um operador em proprietário de um conjunto de namespaces.

Para aceitar casos de uso multilocatários, os namespaces hierárquicos têm dois comportamentos principais, além dos namespaces normais do Kubernetes:

  • Criação de namespace delegado. O Controlador de hierarquias introduz o conceito de subnamespace, que pode ser criado por usuários em um namespace existente, mesmo que esse usuário não tenha privilégios de namespace no nível do cluster.

    Por exemplo, você pode definir um namespace para uma equipe no Anthos Config Management em um repositório Git, mas, em seguida, delegue a criação de subnamespace para a equipe. Isso permite que eles criem seus próprios subnamespaces abaixo do namespace no nível da equipe que você definiu para eles, sem fazer modificações no Git.

  • Aplicação da política. Assim como o Anthos Config Management pode propagar objetos de política de diretórios de namespace abstratos para namespaces do Kubernetes, o Controlador de hierarquias também consegue propagar esses objetos para subnamespaces. Por exemplo, isso garante que as políticas aplicadas ao namespace root de uma equipe também sejam aplicadas aos respectivos subnamespaces.

    No entanto, há algumas diferenças entre a forma como o Controlador de hierarquias e o Anthos Config Management propagam políticas. O Anthos Config Management copia todos os objetos em diretórios de namespaces abstratos para os namespaces descendentes do Kubernetes. O Controlador de hierarquias, por sua vez, copia apenas papéis RBAC e vinculações de papéis por padrão, embora possa ser configurado para propagar qualquer outro tipo de objeto do Kubernetes.

O Controlador de hierarquias está integrado ao Anthos Config Management versão 1.4.1 ou posterior. O Controlador de hierarquias é baseado no Controlador de namespace hierárquico (HNC, na sigla em inglês), um projeto de código aberto.

Namespaces hierárquicos x namespaces abstratos

Os namespaces hierárquicos fornecidos pelo Controlador de hierarquias são parecidos com os namespaces abstratos do Anthos Config Management. No entanto, enquanto os namespaces abstratos só existem no repositório do Anthos Config Management, os namespaces hierárquicos são todos os namespaces do Kubernetes e existem no cluster.

Para evitar contenção entre namespaces abstratos do Anthos Config Management e namespaces do Controlador de hierarquias, não deixe nenhum namespace hierárquico não raiz ser criado como um namespace abstrato ou folha no repositório do Anthos Config Management.

Como alternativa, use um repositório não estruturado para desativar namespaces abstratos do Anthos Config Management e confiar apenas no Controlador de hierarquias para definir hierarquias e propagar políticas. Isso pode ser útil se você não conseguir usar a estrutura de diretórios do repositório padrão, mas quiser aproveitar os recursos hierárquicos.

Para usar repositórios não estruturados, faça verificações em subnamespaces ou namespaces completos. Recomendamos o uso de namespaces completos porque é possível atualizar as relações hierárquicas deles modificando o objeto HierarchicalConfiguration (que também precisa ser verificado). Por outro lado, se você fizer verificações em subnamespaces, não deixe de verificar namespaces e objetos SubnamespaceAnchor nos pais, mas lembre-se de que eles não foram projetados para serem facilmente modificados após a criação.

Em ambos os casos, não se esqueça de configurar o controlador de hierarquias para aplicar todos os tipos de objeto do Kubernetes que quiser nas hierarquias. Por padrão, somente papéis RBAC e vinculações de papel são aplicados.

A seguir