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

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

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

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/audit:
```
mkdir namespaces/audit
```
No diretório de namespace, crie um arquivo audit.yaml, com o conteúdo a seguir. O metadata.name precisa ser igual ao nome do namespace e do diretório de namespace.
```
apiVersion: v1
kind: Namespace
metadata:
  name: audit
```

Crie uma confirmação que inclua o config audit.yaml e a envie ao repositório remoto.

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

Depois de alguns instantes, o namespace audit é criado em cada cluster inscrito. Para verificar a criação, descreva o namespace:
```
kubectl describe namespace audit
```
Para remover a configuração e excluir o namespace audit dos clusters registrados, crie uma nova confirmação que remova o arquivo e a envie ao repositório remoto.

Observação: não remova o config se você quiser configurar um namespace abstrato.

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 audit para um namespace abstrato que contém mais configs herdados pelo audit.

No clone local do repo, crie um diretório de namespace abstrato chamado regulatory. 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/regulatory
```

No diretório de namespace abstrato regulatory, crie um config de um papel chamado regulator. Ele concede get e list a todos os recursos em qualquer namespace que herdar esse papel.

# namespaces/regulatory/regulator_role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: regulator
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list"]

Crie um config de um RoleBinding chamado regulatory-admin. Ele vincula o papel regulator ao grupo regulators@example.com:

# namespaces/regulatory/regulator_rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: regulatory-admin
subjects:
- kind: Group
  name: regulators@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: regulator
  apiGroup: rbac.authorization.k8s.io

Mova o diretório de namespace audit de namespaces/ para namespaces/regulatory/:
```
mv namespaces/audit/ namespaces/regulatory/
```
Confirme todas as alterações e as envie ao repo remoto.

O operador do Config Sync reconhece a alteração e aplica o novo papel e o RoleBinding ao namespace audit em todos os clusters inscritos.

Para remover os configs e excluir o namespace audit dos clusters inscritos, crie uma nova confirmação que remova todo o namespace abstrato regulatory 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 ele estiver no subdiretório namespaces/, o Config Sync criará primeiro o namespace em cada cluster. Depois, ele aplicará todos os configs herdados 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. Utilize um NamespaceSelector com um config em namespaces/ para limitar os namespaces que podem herdar esse config.

Os NamespaceSelectors são semelhantes, mas não idênticos, aos ClusterSelectors. O NamespaceSelector restringe o pool de namespaces que podem herdar 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

É possível colocar os NamespaceSelectors em qualquer diretório de namespace abstrato, mas não em um namespace.

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

foo-corp
...
├── namespaces
│   ├── ns_selector.yaml  # valid
|   ├──audit
|   |   ├── namespace.yaml
|   |   └── ns_selector.yaml  # invalid
|   └──shipping-app-backend
|       ├── ns_selector.yaml  # valid
|       └── shipping-prod
|           ├──namespace.yaml
|           └──ns_selector.yaml # invalid
...

Como os diretórios namespaces e shipping-app-backend representam namespaces abstratos, é possível colocar um seletor neles. No entanto, como os diretórios audit e shipping-prod 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 sre-supported. Se outro config mencionar esse NamespaceSelector, ele só poderá ser aplicado a objetos em namespaces com o rótulo env: prod.

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: sre-supported
spec:
  selector:
    matchLabels:
      env: prod

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 sre-supported estiver na mesma hierarquia que o RoleBinding sre-admin a seguir, o RoleBinding será criado somente nos namespaces que tiverem o rótulo env: prod:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-admin
  annotations:
    configmanagement.gke.io/namespace-selector: sre-supported
subjects:
- kind: Group
  name: sre@foo-corp.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

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

Adicionar rótulos aos namespaces.
Criar um config NamespaceSelector.
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

Veja o guia de início rápido.
Saiba mais sobre como configurar clusters e objetos com escopo de cluster.
Saiba mais sobre como aplicar configs a um subconjunto de clusters.