分层代码库概览

本页面介绍 Config Sync 如何从层次结构代码库中读取配置,并将生成的配置自动应用到您的集群。

如果您想提高结构灵活性(例如,要创建资源的子文件夹),则可以创建非结构化代码库。我们建议大多数用户使用非结构化代码库,并且可以将非结构化代码库与层次结构控制器结合使用,以提供类似于分层代码库所提供的命名空间继承功能。

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

分层代码库的结构

对于分层代码库,Config Sync 会利用 Git 的类文件系统结构,并使用该结构来确定配置与哪些集群或命名空间相关。

namespaces/

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

cluster/

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

clusterregistry/

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

system/

system/ 目录包含运算符的配置。如需详细了解如何配置 Config Sync,请参阅安装 Config Sync

分层代码库示例

以下目录结构展示了如何使用 Config Sync 分层代码库配置由两个不同团队(team-1team-2)共享的 Kubernetes 集群。

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

有效的 Config Sync 分层代码库必须包含三个子目录:cluster/namespaces/system/

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

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

system/ 目录包含 Config Management 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

后续步骤