本主题说明如何使用 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
后续步骤
- 试用快速入门
- 详细了解如何配置集群和集群级对象
- 了解如何将配置应用于部分集群