使用分层代码库

本页面介绍 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: IllegalNamespaceSubdirectoryError。

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

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

受限命名空间

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

在可靠来源中进行更改

如果您在可靠来源中进行更改以在 namespaces/ 目录中创建或删除命名空间目录，则可能会发生意外结果，具体取决于操作：

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

  • 重命名目录：重命名命名空间目录是先进行删除，然后进行创建，因而被视为破坏性操作。重命名抽象命名空间目录不会产生任何外部可见的影响。

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

后续步骤