配置命名空间和命名空间级对象

本主题说明如何使用 Anthos Config Management 管理命名空间和命名空间级对象。您还可以阅读配置集群和集群级对象。

配置命名空间

命名空间和命名空间级对象的所有配置都位于存储库的 namespaces/ 目录及其后代目录中。

请按照以下步骤在每个已注册的集群中配置名为 audit 的命名空间。

在存储库的本地克隆中，创建一个命名空间目录。命名空间目录包含命名空间的配置。命名空间目录的名称必须与命名空间的名称一致。在此示例中，命名空间目录名为 namespaces/audit：
```
mkdir namespaces/audit
```
在命名空间目录中，创建一个包含以下内容的 audit.yaml 文件。metadata.name 必须与命名空间的名称（以及命名空间目录的名称）相匹配。
```
apiVersion: v1
kind: Namespace
metadata:
  name: audit
```

创建包含 audit.yaml 配置的提交实例，并将该实例推送到远程存储库。

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

稍等片刻之后，系统就会在每个已注册的集群中创建 audit 命名空间。如需进行验证，请描述该命名空间：
```
kubectl describe namespace audit
```
如需移除配置并从已注册的集群中删除 audit 命名空间，您可以创建一项新的提交实例以移除相应文件，然后将该实例推送到远程存储库。

注意：如果您想尝试配置抽象命名空间，请不要移除配置。

配置抽象命名空间

此示例在配置命名空间中的示例基础上进行了延伸，将 audit 命名空间目录移动到包含 audit 命名空间所继承的其他配置的抽象命名空间。

在存储库的本地克隆中，创建一个名为 regulatory 的抽象命名空间目录。抽象命名空间目录不包含命名空间的配置，但其后代命名空间目录包含该配置。
```
mkdir namespaces/regulatory
```

在 regulatory 抽象命名空间目录中，为名为 regulator 的 Role 创建配置，以针对最终继承该 Role 的任何命名空间中的所有资源授予 get 和 list 权限。

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

为名为 regulatory-admin 的 RoleBinding 创建配置，以将 regulator 角色绑定到 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

将 audit 命名空间目录从 namespaces/ 移动到 namespaces/regulatory/ 目录：
```
mv namespaces/audit/ namespaces/regulatory/
```
提交所有更改并将其推送到远程存储库。

Config Management Operator 会注意到这些更改，并将新的 Role 和 RoleBinding 应用于所有已注册集群上的 audit 命名空间。

如需移除这些配置并从已注册的集群中删除 audit 命名空间，您可以创建一个新提交实例来移除整个 regulatory 抽象命名空间，并将该实例推送到远程存储库。

限制受配置影响的集群

通常，Anthos Config Management 会将配置应用到每个已注册的集群。如果配置位于 namespaces/ 子目录中，则 Anthos Config Management 会先在每个集群内创建命名空间，然后再将所有继承的配置应用到该命名空间。

如需根据每个集群的标签限制受特定配置影响的集群，请参阅将配置应用于部分集群。

限制受配置影响的命名空间

NamespaceSelector 是一种使用 Kubernetes labelSelector 的特殊类型配置。您可以将 NamespaceSelector 与 namespaces/ 中的配置组合使用，以限制哪些命名空间可以继承该配置。

以下配置会创建一个名为 sre-supported 的 NamespaceSelector。如果您在另一项配置中引用了此 NamespaceSelector，那么该配置只能应用于具有 env: prod 标签的命名空间中的对象。

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

如需在配置中引用 NamespaceSelector，请将 configmanagement.gke.io/namespace-selector 注释设置为 NamespaceSelector 的名称。

当您在另一个配置中引用 NamespaceSelector 之后，该 NamespaceSelector 才会生效。 如果 sre-supported NamespaceSelector 位于与以下 RoleBinding sre-admin 相同的层次结构中，那么系统将仅在具有 env: prod 标签的命名空间中创建 RoleBinding：

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

总而言之，使用 NamespaceSelector 的过程分为三个步骤：

向命名空间添加标签。
创建 NamespaceSelector 配置。
在另一个配置中引用 NamespaceSelector 对象。

禁止继承某个对象类型

您可以有选择地针对任何配置停用继承功能，只需将 hierarchyMode 字段设置为 none 即可。HierarchyConfig 存储在存储库的 system/ 目录中。以下示例会禁止继承 RoleBinding。

# 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

配置命名空间和命名空间级对象