O controlador de hierarquia adiciona recursos hierárquicos aos namespaces do Kubernetes, que permitem escrever políticas mais expressivas, melhorar a observabilidade e delegar a administração do cluster.
O Controlador de hierarquias é baseado no Controlador de namespace hierárquico (HNC, na sigla em inglês), um projeto de código aberto. Ele é implementado usando controladores e controladores de admissão dinâmicos do Kubernetes, executados no cluster.
Namespaces hierárquicos
No Kubernetes, namespaces são a unidade fundamental da organização da maioria dos objetos. Eles também formam a unidade fundamental de isolamento e segurança no Kubernetes. A maioria das políticas e objetos de isolamento operam no nível do namespace, como papéis RBAC, secrets, contas de serviço, cotas de recursos e políticas de rede.
Normalmente, é possível melhorar a segurança e o isolamento do cluster definindo um escopo para cada namespace para conter o menor número de recursos, como um único microsserviço, junto com os recursos e políticas. No entanto, isso pode levar a um grande número de namespaces nos clusters, o que pode ser difícil de gerenciar.
Para resolver isso, o controlador de hierarquia introduz o conceito de namespaces hierárquicos, que permite agrupar namespaces do Kubernetes de acordo com os proprietários e manipular esses grupos como unidades coesas. Eles são especialmente úteis em clusters compartilhados por várias equipes, mas os proprietários não precisam ser pessoas. Por exemplo, pode ser útil tornar uma ferramenta automatizada o proprietário de um conjunto de namespaces, especialmente se ela exigir permissões muito amplas, mas precisar apenas de um pequeno conjunto de namespaces relacionados.
Para aceitar casos de uso multilocatários, os namespaces hierárquicos são compatíveis com vários recursos além dos namespaces normais do Kubernetes:
- Aplicação da política. Os namespaces hierárquicos podem herdar determinadas políticas dos ancestrais por meio do uso de propagação. Por exemplo, isso permite conceder permissões do RBAC em um namespace "raiz", e o controlador de hierarquia garante que essas permissões também estejam em todos os namespaces descendentes copiando (propagando) os objetos RBAC para esses descendentes. A propagação também pode ser controlada em um nível refinado usando exceções.
- Aplicação da política. Todos os namespaces hierárquicos incluem rótulos confiáveis e conhecidos que refletem os ancestrais. Esses rótulos podem ser usados em seletores de rótulos para políticas como a validação de configurações de webhook ou políticas de rede.
- Cota hierárquica. É possível definir uma única cota hierárquica em um namespace ancestral, e os limites são aplicados automaticamente no uso agregado desse namespace, bem como de todos os seus descendentes.
- Observabilidade hierárquica. Os rótulos confiáveis usados no aplicativo de políticas também podem ser usados para observar cargas de trabalho hierárquicas, como filtrar registros ou uso.
- 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.
Os namespaces hierárquicos também são compatíveis com recursos de administração abrangentes, incluindo delegação.
Namespaces hierárquicos x namespaces abstratos
Os namespaces hierárquicos fornecidos pelo Controlador de hierarquias são semelhantes aos namespaces abstratos que podem ser usados se você estiver usando um repositório hierárquico do Config Sync. No entanto, eles têm várias diferenças conceituais:
- Os namespaces abstratos só podem ser definidos em um repositório hierárquico, o que impõe uma estrutura específica nos configs. Os namespaces hierárquicos podem ser usados em repositórios não estruturados, permitindo que você organize seus arquivos de configuração da maneira que quiser.
- Os namespaces abstratos só existem em repositórios Git, enquanto os namespaces hierárquicos também são namespaces normais do Kubernetes e existem no cluster. Como resultado, os namespaces hierárquicos podem ser definidos em um repositório ou diretamente no cluster.
- Não é necessário ter permissões no nível do cluster para criar namespaces hierárquicos. Em vez disso, é possível usar subnamespaces para criação de namespace excluído.
- As Cotas de recursos hierárquicas são compatíveis somente com namespaces hierárquicos, e não com namespaces abstratos.
- Os namespaces abstratos só estão disponíveis para o Config Sync, enquanto os namespaces hierárquicos são baseados em conceitos de código aberto.
Os namespaces abstratos e hierárquicos também têm alguns comportamentos padrão diferentes. Por padrão, todos os objetos criados em um namespace abstrato são propagados para os descendentes. Por outro lado, os objetos em namespaces hierárquicos só serão propagados se o Controlador de hierarquias tiver sido configurado para propagar esse tipo de objeto.
Por padrão, somente papéis RBAC e vinculações de papel são propagados, mas qualquer objeto com namespace pode ser propagado. Recomendamos que você propague somente objetos de política (como papéis) e objetos de recurso (como mapas de configuração). O controlador de hierarquia não foi projetado para propagar objetos de carga de trabalho, como pods, implantações ou jobs, e pode produzir consequências indesejadas se usado dessa maneira. Recomendamos colocar as cargas de trabalho em namespaces folha.
Como usar o controlador de hierarquia com o Config Sync
O controlador de hierarquia permite definir e aplicar políticas usando conceitos hierárquicos, que são adequados para muitos aplicativos, incluindo clusters usados por várias equipes. O Config Sync permite armazenar essas políticas em um repositório Git e aplicá-las a grupos de clusters. Embora diferentes, esses dois recursos são gratuitos e proporcionam um modo poderoso de aplicar GitOps em ambientes com várias equipes e clusters.
Ao usar o controlador de hierarquia com o Config Sync, recomendamos
usar um
repositório não estruturado
para desativar namespaces abstratos do Config Sync e usar
o controlador de hierarquia para definir hierarquias e propagar políticas. Para os
namespaces que você quer verificar em seu repo, recomendamos verificar apenas as
configurações de
namespaces completos,
não subnamespaces, porque você pode atualizar seus relações hierárquicas
modificando o objeto HierarchicalConfiguration.
É possível usar o controlador de hierarquia com os namespaces abstratos do Config Sync em um repositório hierárquico, mas apenas de maneiras limitadas. Por exemplo, o controlador de hierarquia não permite criar uma relação hierárquica entre dois namespaces que foram definidos em um repositório hierárquico. Isso pode entrar em conflito com namespaces abstratos nesse repositório. No entanto, é possível usar namespaces hierárquicos com um repositório hierárquico das seguintes maneiras:
- É possível criar subnamespaces de autoatendimento no cluster, abaixo de um namespace criado a partir de um repositório hierárquico. No entanto, não recomendamos que você verifique as configurações desses subnamespaces.
- Se você estiver usandovários repositórios , é possível criarâncoras de subnamespace nos repositórios de namespaces, que instruirão o controlador de hierarquia a criar subnamespaces abaixo do namespace especificado. Esses subnamespaces herdarão todos os recursos configurados dos ancestrais e serão restritos por qualquer cota de recursos hierárquicos. No entanto, não é possível definir recursos que precisam existir apenas nesses subnamespaces. O Config Sync sincronizará todos os objetos no repositório de namespace com o namespace especificado.