本指南說明 Config Sync 的依附元件運作方式，以及如何指定自己的依附元件。
Config Sync 會在將特定物件同步至叢集時，自動偵測這些物件之間的隱含依附元件。舉例來說，系統一律會先套用命名空間物件，再套用這些命名空間中的任何物件；系統一律會先套用 CustomResourceDefinition (CRD) 物件，再套用這類型的任何自訂資源。同樣地，這些隱含依附元件的刪除順序也會相反：命名空間會在該命名空間中的物件刪除後刪除，而 CRD 則會在該類型的自訂資源刪除後刪除。
您也可以使用 depends-on 註解設定明確的依附元件。
舉例來說，您可能希望 MySQL StatefulSet 在 Wordpress Deployment 之前啟動，以便在 Wordpress 啟動前套用資料庫並準備就緒。
需求條件
必須啟用 RootSync 和 RepoSync API。 如果您使用 kubectl 手動安裝 Config Sync，且未啟用 RootSync 和 RepoSync API，則必須遷移 ConfigManagement 物件。
限制：依附元件必須與依附對象位於相同的可靠資料來源。依附元件必須由與其依附項相同的 RootSync 或 RepoSync 物件管理，確保所有資源都位於同一個 ResourceGroup 中。
套用群組
將資源同步至叢集時，Config Sync 會將具有直接或間接依附元件的資源劃分為不同的套用群組。一個套用群組只包含彼此沒有直接或間接依附元件的資源。如果資源沒有任何依附元件，系統會先套用該資源所屬的套用群組。
結算和對帳
物件啟動 (套用或修剪) 後，控制器可能需要一段時間才能完成物件的協調程序。舉例來說，套用 Deployment 時，基礎 Pod 可能不會立即就緒。基礎 Pod 準備就緒後，Deployment 就會完成協調。對於不同類型的物件，Config Sync 會檢查不同類型的條件，以驗證物件是否已完成協調。詳情請參閱 sigs.k8s.io/cli-utils
有了 depends-on 註解，Config Sync 不僅會按照您想要的順序套用物件，還會先驗證依附元件物件是否已完成協調，再套用依附元件物件。
如果依附元件物件未在預設的 5 分鐘協調逾時時間內完成協調，Config Sync 會等到下一個同步週期，才會套用依附元件物件。您可以設定 spec.override.reconcileTimeout，覆寫預設的協調逾時。
將 depends-on 註解新增至物件
如要指定依附元件，請在依附物件上新增 config.kubernetes.io/depends-on 註解，並使用參照依附物件的值。
以 Wordpress 為例，Wordpress 部署中的註解類似於下列內容：
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress
namespace: default
labels:
app: wordpress
annotations:
config.kubernetes.io/depends-on: apps/namespaces/default/StatefulSet/wordpress-mysql
Config Sync 套用物件時，會先套用依附元件，也就是 wordpress-mysql StatefulSet 物件。依附元件完成協調後，Config Sync 會套用依附元件，也就是 wordpress Deployment。
物件參照
物件參照使用下列語法：
命名空間物件：
GROUP/namespaces/NAMESPACE/KIND/NAME叢集範圍內的物件：
GROUP/KIND/NAME更改下列內容：
GROUP：依附元件物件的群組。NAMESPACE：命名空間範圍內依附元件物件的命名空間。KIND：依附元件物件的種類。這個欄位會區分大小寫。例如，請使用「Pod」而非「pod」。NAME：依附元件物件的名稱。
如果是核心群組中的物件，則會改用空字串，例如 /namespaces/test/Pod/pod-a。
使用 , 分隔多個物件參照，例如 /namespaces/test/Pod/pod-a,/namespaces/test/Pod/pod-b。