本頁說明如何在單一事實來源中整理設定。
隨著貴機構成長，您可能需要管理叢集機群的設定，並支援在相同存放區中工作的多個團隊。成功的 GitOps 策略的關鍵在於，確保設定套用至正確的叢集，且團隊可以順利協作，不會互相干擾。
關於設定檔
Config Sync 專為管理多個叢集的叢集操作人員而設計。只要您允許 Config Sync 管理您所有叢集上的命名空間、角色、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/目錄下的資源)。