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

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

配置命名空间

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

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

  1. 在存储库的本地克隆中,创建一个命名空间目录。命名空间目录包含命名空间的配置。命名空间目录的名称必须与命名空间的名称一致。在此示例中,命名空间目录名为 namespaces/audit

    mkdir namespaces/audit
    
  2. 在命名空间目录中,创建一个包含以下内容的 audit.yaml 文件。metadata.name 必须与命名空间的名称(以及命名空间目录的名称)相匹配。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: audit
    
  3. 创建包含 audit.yaml 配置的提交实例,并将该实例推送到远程存储库。

    git add namespaces/audit/audit.yaml
    git commit -m "Created audit namespace config"
    git push [NAME-OF-REMOTE] [BRANCH-NAME]
    
  4. 稍等片刻之后,系统就会在每个已注册的集群中创建 audit 命名空间。如需进行验证,请描述该命名空间:

    kubectl describe namespace audit
    
  5. 如需移除配置并从已注册的集群中删除 audit 命名空间,您可以创建一项新的提交实例以移除相应文件,然后将该实例推送到远程存储库。

配置抽象命名空间

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

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

    mkdir namespaces/regulatory
    
  2. regulatory 抽象命名空间目录中,为名为 regulator 的 Role 创建配置,以针对最终继承该 Role 的任何命名空间中的所有资源授予 getlist 权限。

    # namespaces/regulatory/regulator_role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: regulator
    rules:
    - apiGroups: [""]
      resources: ["*"]
      verbs: ["get", "list"]
    
  3. 为名为 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
    
  4. audit 命名空间目录从 namespaces/ 移动到 namespaces/regulatory/ 目录:

    mv namespaces/audit/ namespaces/regulatory/
    
  5. 提交所有更改并将其推送到远程存储库。

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 的过程分为三个步骤:

  1. 向命名空间添加标签。
  2. 创建 NamespaceSelector 配置。
  3. 在另一个配置中引用 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

后续步骤