本页介绍了如何在可靠来源中组织配置。
随着组织的不断发展壮大，您可能需要管理整个集群队列中的配置，并支持多个团队在同一代码库中开展工作。成功的 GitOps 策略的关键在于确保配置应用于正确的集群，并且团队可以正常工作，而不会相互干扰。
关于配置文件
Config Sync 专为管理多个集群的集群运维人员而设计。允许 Config Sync 管理整个舰队中的命名空间、Role、RoleBinding、ResourceQuota 和其他重要的 Kubernetes 对象，可以确保您的集群符合业务与合规性标准。
当 Config Sync 管理这些资源时，它会使用配置使已注册的集群保持同步。配置是可靠来源中的 YAML 或 JSON 文件。Config Sync 支持使用 Git 代码库、OCI 映像和 Helm 图表作为可靠来源。配置包含您可以通过 kubectl apply 命令手动应用于集群的相同类型的配置详细信息。您可以为集群中存在的任何 Kubernetes 对象创建配置。不过，某些 Kubernetes 对象（如 Secret）包含可能不适合存储在可靠来源中的敏感信息。请仔细考虑是否使用 Config Sync 来管理这些类型的对象。
要求和限制
某些 Kubernetes 资源包含不可变字段，例如 Deployment 对象中的 Pod 选择器。您无法通过更改可靠来源中的值来更改配置中的任何不可变字段。尝试此类更改会导致
KNV2009错误。如果您需要更改不可变字段，请从可靠来源中删除对象，等待 Config Sync 从集群中删除该对象，然后在可靠来源中使用更新重新创建该对象。如果您使用 Git 子模块，则必须向 Config Sync 授予对所有仓库（包括所有子模块）的访问权限。
您无法使用 Config Sync 直接管理内置的 Kubernetes ClusterRole。GKE 内置了一些面向用户的角色，例如
cluster-admin、admin、edit和view。您无法直接使用 Config Sync 管理这些 ClusterRole，否则 Config Sync 会与 GKE 发生冲突。如需向内置 ClusterRole 添加权限，请使用角色聚合间接修改这些角色。如需修改角色，请在可靠来源中创建具有唯一名称的 ClusterRole，并添加适当的注解。
整理可靠来源
您可以将 Config Sync 配置为从整个代码库或特定文件夹或分支同步。由于这种灵活性，您可以根据团队或组织的需求整理配置文件。
我们建议您在配置 Config Sync 时，将 sourceFormat 设置为 unstructured。结构化（分层）来源类型需要非常特定的文件夹结构才能正确同步配置，并且在大多数情况下会增加不必要的复杂性。
Config Sync 的大多数文档（包括本页面）默认使用非结构化格式，但您可以在使用分层代码库中找到有关分层格式的信息（如果需要）。
使用非结构化来源时，您可以灵活地组织配置，以适应团队的工作流程。本部分介绍了一些常见的代码库结构模式。
基于环境的布局
一种常见的方法是按环境整理代码库。
├── cluster-essentials/
│ ├── crds/
│ └── namespace.yaml
├── environments/
│ ├── dev/
│ │ ├── backend/
│ │ └── frontend/
│ ├── staging/
│ │ ├── backend/
│ │ └── frontend/
│ └── prod/
│ ├── backend/
│ └── frontend/
└── system/
└── monitoring/
在此示例中，可靠来源的结构如下：
cluster-essentials/：包含适用于所有集群（无论环境如何）的配置。这可能包括自定义资源定义 (CRD) 和必需的命名空间等资源。environments/：所有特定于环境的配置的父目录。system/：包含监控等系统级服务的配置。
这种方法简单易懂，可让您轻松地在不同环境之间转移更改。
在此场景中设置 Config Sync 时，您会在每个集群上创建多个 RootSync 对象。例如，开发集群具有从 cluster-essentials/、system/ 和 environments/dev/ 同步的 RootSync 对象。
基于集群的布局
如果您专注于管理具有不同配置的单个集群组成的舰队，那么基于集群的布局可能更适合您。
├── clusters/
│ ├── cluster-a/
│ │ ├── apps/
│ │ └── networking/
│ ├── cluster-b/
│ │ ├── apps/
│ │ └── networking/
│ └── cluster-c/
│ ├── apps/
│ └── networking/
└── shared/
├── roles/
└── policies/
在此示例中，可靠来源的结构如下：
clusters/：包含您管理的每个集群的目录。shared/：包含所有集群通用的配置，例如 RBAC 角色和安全政策。
如果多个集群都具有独特的配置，此方法可有效管理这些集群，因为它可以明确配置的所有权并隔离配置。如果您有许多共享的集群配置，这种方法在管理方面可能会更加复杂。
在此场景中设置 Config Sync 时，您可以使用 RepoSync 将每个集群配置为同时从 shared 和特定于集群的目录同步。
基于团队的布局
对于由不同团队管理不同应用或服务的组织，基于团队的布局可能非常有效。此方法可使可靠来源结构与组织结构保持一致。
├── teams/
│ ├── team-alpha/
│ │ ├── app-one/
│ │ └── app-two/
│ ├── team-beta/
│ │ ├── service-a/
│ │ └── service-b/
│ └── team-gamma/
│ ├── data-pipeline/
│ └── dashboard/
└── platform/
├── cluster-roles/
└── storage-classes/
在此示例中，真实来源的组织方式如下：
teams/：按团队整理配置，每个团队管理自己的应用和服务配置。platform/：包含由中央平台团队管理并供所有团队使用的集群级配置。
这种方法可让团队管理自己的配置和发布周期，并降低一个团队的更改意外影响另一个团队的可能性。不过，这种方法需要仔细管理应用团队和平台团队之间的依赖关系。
在此方案中，设置 Config Sync 时，每个团队都使用 RootSync 对象来同步配置，例如 team-alpha 从 teams/team-alpha/ 同步。
验证配置文件
在创建、整理配置并将配置文件添加到可靠来源后，请使用 nomos vet --source-format=unstructured 命令检查配置的语法和有效性。这有助于避免在同步期间或之后出错。
忽略对象变更
如果您不希望 Config Sync 在集群存在后保留该对象的状态，则可以将 client.lifecycle.config.k8s.io/mutation: ignore 注解添加到您希望 Config Sync 忽略变更的对象。
以下示例向您展示如何将注释添加到对象中：
metadata:
annotations:
client.lifecycle.config.k8s.io/mutation: ignore
您无法在集群中的受管对象上手动修改此注释。
将分层代码库转换为非结构化代码库
如果您使用的是分层代码库，并且想要将其转换为非结构化代码库，请运行以下命令：
nomos hydrate PATH
将 PATH 替换为目录的路径。
此命令会在当前工作目录中创建一个 compiled/ 目录。在该目录中，系统会为每个已注册的集群创建一个子目录。这些子目录包含完全解析的配置，可以在非结构化代码库中使用。
如需了解详情，请参阅 nomos 命令。
如果您希望手动转换代码库，请按照以下说明操作：
从 Git 代码库中移除
system/目录中的Repo配置。非结构化代码库不需要Repo资源。非结构化代码库不支持抽象命名空间目录。因此，请声明最初包含在
namespaces/目录及其子目录中的所有资源的命名空间。非结构化代码库不支持命名空间继承。因此，请声明在后代命名空间中最初继承的所有资源（最初位于
namespaces/目录下的资源）。