Como configurar namespaces e objetos com escopo de namespace

Nesta página, mostramos como usar o Config Sync para gerenciar namespaces e objetos com escopo de namespace. Você também encontra informações sobre como configurar clusters e objetos com escopo de cluster.

Como configurar um namespace

Formato não estruturado

As configurações de namespaces e objetos com escopo de namespace podem estar localizadas em qualquer lugar no diretório ou subdiretórios.

Siga estas etapas para configurar um namespace chamado gamestore em cada cluster inscrito. Você só precisa criar um arquivo YAML que contenha a configuração do namespace. Este exemplo adiciona o arquivo ao diretório raiz. É possível movê-lo para qualquer subdiretório.

  1. Crie um arquivo namespace-gamestore.yaml com o seguinte conteúdo.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    
  2. Crie uma confirmação que inclua o config namespace-gamestore.yaml e a envie ao repositório remoto.

    git add multirepo/root/namespace-gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push [NAME-OF-REMOTE] [BRANCH-NAME]
    

Formato hierárquico

Todas as configurações de namespaces e objetos com escopo de namespace estão localizados no diretório namespaces/ do repositório hierárquico e nos respectivos diretórios descendentes.

Siga estas etapas para configurar um namespace chamado gamestore em cada cluster inscrito.

  1. No clone local do repo, crie um diretório de namespace. Um diretório de namespace que contém uma configuração de um namespace. O nome do diretório de namespace precisa ser igual ao do namespace. Neste exemplo, o diretório é chamado namespaces/gamestore:

    mkdir namespaces/gamestore
    
  2. No diretório de namespace, crie um arquivo gamestore.yaml, com o conteúdo a seguir. O metadata.name precisa corresponder ao nome do namespace e do diretório de namespace.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    
  3. Crie uma confirmação que inclua o config gamestore.yaml e a envie ao repositório remoto.

    git add namespaces/gamestore/gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push [NAME-OF-REMOTE] [BRANCH-NAME]
    

Depois de alguns instantes, o namespace gamestore é criado em cada cluster inscrito. Para verificar a criação, descreva o namespace:

kubectl describe namespace gamestore

Para remover a configuração e excluir o namespace gamestore dos clusters registrados, crie uma nova confirmação que remova o arquivo e a envie ao repositório remoto.

Como configurar um namespace abstrato

Este exemplo amplia as informações fornecidas na seção Como configurar um namespace. Isso é feito ao mover o diretório de namespace gamestore para um namespace abstrato que contém mais configs herdados pelo gamestore.

  1. No clone local do repo, crie um diretório de namespace abstrato chamado eng. O diretório de namespace abstrato não contém um config de um namespace, mas sim os respectivos diretórios de namespace descendente.

    mkdir namespaces/eng
    
  2. No diretório de namespace abstrato eng, crie um config de um papel chamado eng-viewer. Ele concede get e list a todos os recursos em qualquer namespace que herdar esse papel.

    # namespaces/eng/eng-role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: eng-viewer
    rules:
    - apiGroups: [""]
      resources: ["*"]
      verbs: ["get", "list"]
    
  3. Crie um config de um RoleBinding chamado eng-admin. Ele vincula o papel eng-viewer ao grupo eng@example.com:

    # namespaces/eng/eng-rolebinding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: eng-admin
    subjects:
    - kind: Group
      name: eng@example.com
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: eng-viewer
      apiGroup: rbac.authorization.k8s.io
    
  4. Mova o diretório de namespace gamestore de namespaces/ para namespaces/eng/:

    mv namespaces/gamestore/ namespaces/eng/
    
  5. Confirme todas as alterações e as envie ao repo remoto.

O Config Management Operator reconhece a alteração e aplica o novo papel e o RoleBinding ao namespace gamestore em todos os clusters inscritos.

Para remover os configs e excluir o namespace gamestore dos clusters inscritos, crie uma nova confirmação que remova todo o namespace abstrato eng e envie ao repositório remoto.

Como limitar quais clusters são impactados por um config

Normalmente, o Config Sync aplica um config a cada cluster inscrito. Se a configuração estiver dentro do subdiretório namespaces/ de um repositório hierárquico, o Config Sync criará primeiro o namespace em cada cluster. Depois, ele aplicará todos os configurações herdadas a esse namespace.

Para limitar quais clusters são impactados por um config específico com base nos rótulos de cada um deles, consulte a seção Como aplicar configs a um subconjunto de clusters.

Como limitar os namespaces impactados por um config

Um NamespaceSelector é um tipo especial de config que usa labelSelectors do Kubernetes. É possível declarar NamespaceSelectors junto com os configs de objetos com escopo de namespace em um repositório não estruturado ou um repositório hierárquico para limitar quais os namespaces podem herdar essa configuração.

Os NamespaceSelectors são semelhantes, mas não idênticos, aos ClusterSelectors. Um NamespaceSelector restringe o pool de namespaces a que um config se aplica. Em um repositório não estruturado, os objetos que declaram a anotação NamespaceSelector são aplicados a todos os Namespaces que satisfazem as condições do NamespaceSelector. Em um repositório hierárquico, os objetos que declaram a anotação NamespaceSelector são aplicados a namespaces que herdam um determinado config de um namespace abstrato, seja qual for a estrutura de diretórios de namespaces/. O ClusterSelector restringe o pool de clusters a que um config é aplicado, seja o destino dele um objeto com escopo de cluster ou de namespace.

Local do NamespaceSelector

  • Formato não estruturado: em um repositório não estruturado, é possível colocar os NamespaceSelectors em qualquer diretório ou subdiretório.
  • Formato hierárquico: em um repositório hierárquico, é possível colocar NamespaceSelectors em qualquer diretório de namespace abstrato, mas não em um diretório namespace.

    O repositório de exemplo a seguir mostra locais válidos e inválidos para os NamespaceSelectors:

    namespace-inheritance
    ...
    ├── namespaces
    │   ├── eng
    │   │   ├── gamestore
    │   │   │   ├── namespace.yaml
    │   │   │   └── ns_selector.yaml  # invalid
    │   │   └── ns_selector.yaml  # valid
    │   ├── ns_selector.yaml  # valid
    │   ├── rnd
    │   │   ├── incubator-1
    │   │   │   ├── namespace.yaml
    │   │   │   └── ns_selector.yaml  # invalid
    │   │   └── ns_selector.yaml  # valid
    

    Como os diretórios namespaces, eng e rnd representam namespaces abstratos, é possível colocar um seletor neles. No entanto, como os diretórios gamestore e incubator-1 representam namespaces reais, não é possível colocar um NamespaceSelector neles.

Como usar um NamespaceSelector

Com os configs a seguir, você cria um NamespaceSelector chamado gamestore-selector. Se outro config mencionar esse NamespaceSelector, ele só poderá ser aplicado a objetos em namespaces com o rótulo app: gamestore.

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: gamestore-selector
spec:
  selector:
    matchLabels:
      app: gamestore

Para mencionar um NamespaceSelector em um config, defina a anotação configmanagement.gke.io/namespace-selector como o nome do NamespaceSelector.

Um NamespaceSelector não terá efeito até que você o referencie em outro config. Se o NamespaceSelector gamestore-selector estiver na mesma hierarquia que o ResourceQuota quota a seguir, o ResourceQuota será criado somente nos namespaces que tiverem o rótulo app: gamestore:

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
  annotations:
    configmanagement.gke.io/namespace-selector: gamestore-selector
spec:
  hard:
    pods: "1"
    cpu: "200m"
    memory: "200Mi"

Para resumir, usar um NamespaceSelector é um processo de três etapas:

  1. Adicionar rótulos aos namespaces.
  2. Criar um config NamespaceSelector.
  3. Consultar o objeto NamespaceSelector em outro config.

Como desativar a herança para um tipo de objeto

É possível desativar seletivamente a herança dos configs. Basta definir o campo hierarchyMode como none. Os HierarchyConfigs são armazenados no diretório system/ do repo. Este exemplo desativa a herança para o RoleBindings.

# system/hierarchy-config.yaml
kind: HierarchyConfig
apiVersion: configmanagement.gke.io/v1
metadata:
  name: rbac
spec:
  resources:
  # Configure Role to only be allowed in leaf namespaces.
  - group: rbac.authorization.k8s.io
    kinds: [ "RoleBinding" ]
    hierarchyMode: none

A seguir