本頁說明 Config Sync 如何從階層式可靠來源讀取設定，並自動將產生的設定套用至叢集。
建議您使用非結構化單一事實來源，而非階層式來源，因為前者提供相同的核心功能，但可讓您更靈活地整理資源。如果您已使用階層式可靠資料來源，可以將其轉換為非結構化可靠資料來源。
如要瞭解 Config Sync 如何使用階層式存放區，建議您先熟悉 Git 存放區和 git 命令列介面。
您可以在 Config Sync 範例存放區中，查看如何整理及設定階層式可靠來源的範例。
目錄結構
對於階層式來源，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 或容器)。 - 叢集管理員也會設定 ClusterRoles 和 ClusterRoleBindings。
有效的 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/內移動命名空間或抽象命名空間目錄，並不會刪除該命名空間或其中的物件，除非您移動命名空間開始或停止沿用抽象命名空間目錄設定的位置 (因為該目錄的階層有所改變)。