使用分层代码库

本页面介绍 Config Sync 如何从分层可信来源读取配置，并将生成的配置自动应用到集群。

如果您希望在结构上具有更大的灵活性（例如，您希望创建资源的子文件夹），则可以创建非结构化可信来源。对于大多数使用场景，建议使用非结构化可信来源。如果您已在使用分层可信来源，可以将其转换为非结构化可信来源。

如需了解 Config Sync 如何使用分层代码库，熟悉 Git 代码库和 git 命令行界面会很有帮助。

目录结构

对于分层源，Config Sync 利用类似于文件系统的结构，并使用目录来确定配置与哪些集群或命名空间相关。

namespaces/

namespaces/ 目录包含命名空间和命名空间级对象的配置。namespaces/ 的结构是推动命名空间继承的机制。您可以使用 NamespaceSelector 限制哪些命名空间可以继承配置。

cluster/

cluster/ 目录包含应用于整个集群（而不是命名空间）的配置。默认情况下，cluster/ 目录中的任何配置都会应用于在 Config Sync 中注册的每个集群。您可以使用 ClusterSelector 限制配置可以影响的集群。

clusterregistry/

clusterregistry/ 目录是可选的，它包含 ClusterSelectors 的配置。ClusterSelectors 会限制应用配置的集群，并且由 cluster/ 和 namespaces/ 目录中的配置引用。

system/

system/ 目录包含 Operator 的配置。

分层可信来源示例

以下目录结构演示了如何使用 Config Sync 分层可信来源配置由两个不同团队（team-1 和 team-2）共享的 Kubernetes 集群。

  • 每个团队都有自己的 Kubernetes 命名空间、Kubernetes 服务账号、资源配额、网络政策、角色绑定。
  • 集群管理员在 namespaces/limit-range.yaml 中设置政策，以限制两个命名空间中的资源分配（到 Pod 或容器）。
  • 集群管理员还设置了 ClusterRole 和 ClusterRoleBinding。

有效的 Config Sync 分层来源必须包含三个子目录：cluster/、namespaces/ 和 system/。

cluster/ 目录包含应用于整个集群而非命名空间的配置（例如 ClusterRole、ClusterRoleBinding）。

namespaces/ 目录包含命名空间对象和命名空间级对象的配置。 namespaces/ 下的每个子目录都包含一个命名空间对象和该命名空间下所有命名空间级对象的配置。子目录的名称应与命名空间对象的名称相同。需要在每个命名空间中创建的命名空间级对象可以直接放在 namespaces/ 下（例如 namespaces/limit-range.yaml）。

system/ 目录包含 ConfigManagement Operator 的配置。

├── cluster
│   ├── clusterrolebinding-namespace-reader.yaml
│   ├── clusterrole-namespace-reader.yaml
│   ├── clusterrole-secret-admin.yaml
│   └── clusterrole-secret-reader.yaml
├── namespaces
│   ├── limit-range.yaml
│   ├── team-1
│   │   ├── namespace.yaml
│   │   ├── network-policy-default-deny-egress.yaml
│   │   ├── resource-quota-pvc.yaml
│   │   ├── rolebinding-secret-reader.yaml
│   │   └── sa.yaml
│   └── team-2
│       ├── namespace.yaml
│       ├── network-policy-default-deny-all.yaml
│       ├── resource-quota-pvc.yaml
│       ├── rolebinding-secret-admin.yaml
│       └── sa.yaml
├── README.md
└── system
    └── repo.yaml

使用命名空间继承和抽象命名空间

通过分层可信来源，您可以使用命名空间继承的概念，自动将配置应用于存在（或应该存在）的所有集群中的命名空间组。

命名空间继承适用于分层代码库及其所有子目录的 namespaces/ 目录。代码库中其他目录（例如 cluster/）下的配置不受继承功能的约束。

在分层可信来源中，namespaces/ 目录可以包含两种不同类型的子目录：

  • 命名空间目录包含命名空间的配置。包含该配置的文件名称并不重要，但是这项配置必须具有 kind: Namespace。命名空间目录还可以包含其他类型的 Kubernetes 对象的配置。命名空间目录不能包含子目录。命名空间配置表示集群中的实际命名空间。

  • 抽象命名空间目录包含命名空间目录，还可以包含其他 Kubernetes 对象的配置，但不能直接包含命名空间的配置。抽象命名空间目录不代表 Kubernetes 集群中的对象，但其后代命名空间目录可以。

为了帮助确保命名空间和抽象命名空间源具有正确的配置和结构类型，系统会在出现问题时报告错误 KNV1003: Illegal 命名空间 SubdirectoryError。

命名空间目录中的配置仅应用于该命名空间。但是，抽象命名空间目录中的配置会应用于该抽象命名空间的所有后代命名空间目录（或与配置的 NamespaceSelector匹配的后代命名空间，如果存在）。

namespaces/ 目录中某项配置的继承很大程度上取决于该配置在可信来源目录树中的位置。如需了解哪些配置应用于给定集群中的给定命名空间，您可以浏览命名空间继承示例代码库。

受限命名空间

config-management-system 是受限命名空间。您不能将其用作抽象命名空间目录。您可以定义 config-management-system 命名空间，但 config-management-system 命名空间唯一允许的资源类型是 RootSync。

更改可信来源

当您对可信来源进行更改，以便在 namespaces/ 目录中创建或删除命名空间目录时，可能会因操作而异：

  • 创建目录：将有效的 namespaces/ 层次结构提交到可信来源时，Config Sync 会创建命名空间，然后在这些命名空间中为命名空间目录包含或继承的每项配置创建 Kubernetes 对象。
  • 删除目录：删除命名空间目录是一种破坏性操作。系统会从由 Config Sync 管理并包含相应命名空间的每个集群中删除该命名空间及其内容。如果您删除包含后代命名空间目录的抽象命名空间目录，则所有这些命名空间及其内容都将从 Config Sync 管理的每个集群中删除。

  • 重命名目录：如果重命名命名空间目录，系统会先删除目录，然后再创建目录，这被视为破坏性操作。重命名抽象命名空间目录不会产生外部可见的影响。

  • 移动目录：在 namespaces/ 中移动命名空间或抽象命名空间目录不会删除命名空间或其中的对象，除非命名空间由于其层次结构发生更改而开始或停止从抽象命名空间目录继承配置。

后续步骤