本指南說明 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
。