使用 nomos 指令列工具

nomos 指令列工具是 Config Sync 的選用工具，可用來取得 Config Sync 的狀態，以及單一事實來源的同步狀態。nomos 工具提供下列指令：

指令 用量
nomos status 檢查 Config Sync 狀態
nomos vet 檢查單一事實來源是否有錯誤
nomos hydrate 查看可靠資料來源中的所有設定
nomos bugreport 建立錯誤報告
nomos migrate 從 ConfigManagement 物件遷移至 RootSync
nomos init 初始化階層式單一資料來源

必要條件

如要使用 nomos 工具與叢集互動，必須先在目標叢集上安裝 Config Sync。您也必須安裝及設定 kubectl 指令列工具。如果您要與 Google Kubernetes Engine 叢集互動，請務必一併安裝 gke-gcloud-auth-plugin。

nomos 工具支援預覽及驗證 Kustomize 設定和 Helm 圖表。如要使用這項功能，請先在本機工作站安裝 Kustomize 和 Helm。如果可靠資料來源只包含完整轉譯的設定，則 Kustomize 和 Helm 為選用項目。

安裝 nomos 工具

nomos 工具是從 Go 程式碼編譯而來的二進位檔，您可以安裝在本機電腦 (例如工作站或筆記型電腦)。

安裝 Config Sync 時，不會一併安裝 nomos 工具。您可以安裝 Google Cloud CLI，藉此安裝 nomos 工具。如果您使用 Cloud Shell，Google Cloud CLI 會預先安裝。

如果您沒有 Google Cloud CLI，建議使用 gcloud components install nomos 安裝 nomos 工具。使用 Google Cloud CLI 安裝 nomos 工具後，您就能使用 gcloud components update 將 nomos 工具更新至最新版本。

如要瞭解安裝 nomos 工具的替代方法，請參閱「下載」一文。

基本用法

如要瞭解基本指令語法，請使用 --help 引數：

nomos --help

nomos 工具會從資訊來源的本機副本讀取資料。使用 --path 旗標指定可靠資料來源頂層的位置。根據預設，--path 會設為 . 或目前目錄。例如：

nomos vet --path=PATH_TO_SOURCE --source-format unstructured

檢查 Config Sync 狀態

您可以使用 nomos status 指令，監控所有已註冊叢集的 Config Sync 狀態。針對每個叢集，nomos status 會回報上次套用至叢集的提交雜湊，以及嘗試套用任何近期變更時發生的錯誤。

您也可以使用 nomos status 檢查 Config Sync 管理的資源是否已準備就緒。會在輸出內容的 Managed resources 區段中，於 STATUS 欄回報各個資源的狀態。nomos status

以下範例顯示 nomos status 指令可能會回報的一些不同情況：

nomos status

輸出內容範例：

MANAGED_CLUSTER_1
  --------------------
  <root>   git@github.com:foo-corp/acme@main
  SYNCED   f52a11e4
  Managed resources:
   NAMESPACE   NAME                                                                   STATUS
               k8snoexternalservices.constraints.gatekeeper.sh/no-internet-services   Current
               namespace/hello                                                        Current

MANAGED_CLUSTER_2
  --------------------
  <root>   git@github.com:foo-corp/acme@main
  PENDING  9edf8444

MANAGED_CLUSTER_3
  --------------------
  <root>   git@github.com:foo-corp/acme@main
  ERROR    f52a11e4
  Error:   KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.

MANGED_CLUSTER_4
  --------------------
  NOT INSTALLED

MANAGED_CLUSTER_5
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  Managed resources:
   NAMESPACE   NAME                                                                   STATUS
                namespace/gamestore                                                   Current
                namespace/monitoring                                                  Current
   gamestore    reposync.configsync.gke.io/repo-sync                                  Current
   gamestore    rolebinding.rbac.authorization.k8s.io/gamestore-admin                 Current
   gamestore    rolebinding.rbac.authorization.k8s.io/gamestore-webstore-admin        Current
   monitoring   deployment.apps/prometheus-operator                                   Current
   monitoring   prometheus.monitoring.coreos.com/acm                                  Current
   monitoring   service/prometheus-acm                                                Current
   monitoring   service/prometheus-operator                                           Current
   monitoring   serviceaccount/prometheus-acm                                         Current
   monitoring   serviceaccount/prometheus-operator                                    Current
   monitoring   servicemonitor.monitoring.coreos.com/acm-service                      Current
  --------------------
  bookstore  git@github.com:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8
  Managed resources:
   NAMESPACE   NAME                                 STATUS
   gamestore   configmap/store-inventory            Current
   gamestore   webstore.marketplace.com/gameplace   Current

輸出內容如下：

  • 「MANAGED_CLUSTER_1」已將最新變更同步至可靠資料來源，且所有受管理資源的狀態均為 Current。Current 狀態表示資源狀態符合您想要的狀態。
  • MANAGED_CLUSTER_2仍在同步處理中。
  • 「MANAGED_CLUSTER_3」發生錯誤，導致變更無法套用。在本例中，MANAGED_CLUSTER_3 有錯誤 KNV1021，因為缺少其他叢集已安裝的 CustomResourceDefinition (CRD)。
  • MANAGED_CLUSTER_4 未安裝 Config Sync。
  • MANAGED_CLUSTER_5 正在從兩個 Git 存放區同步處理。 <root> 可靠來源屬於叢集管理員，而 bookstore 可靠來源可能屬於應用程式開發團隊。

代管資源狀態

受管理資源的狀態可以是下列其中一個值：

  • InProgress：資源的實際狀態尚未達到您在資源資訊清單中指定的狀態。這個狀態表示資源對帳尚未完成。新建立的資源通常會從這個狀態開始，但部分資源 (例如 ConfigMap) 會立即進入 Current 狀態。

  • Failed：將實際狀態與所需狀態進行比對的程序發生錯誤，或進展不足。

  • Current：資源的實際狀態符合您想要的狀態。 只要期望狀態或實際狀態沒有變更，調解程序就會視為完成。

  • Terminating：系統正在刪除資源。

  • NotFound：叢集中不存在該資源。

  • Unknown：Config Sync 無法判斷資源狀態。

如要關閉顯示資源層級狀態，請在 nomos status 指令中加入 --resources=false。

關於上次同步處理的提交

nomos status 指令會在 status.sync.commit 下方的輸出內容中，顯示套用至叢集的最新提交雜湊。如要取得這個值，請查詢 RootSync 或 RepoSync 物件，並查看 status.sync 欄位。

舉例來說，如要查詢 RootSync 物件，請執行下列指令：

kubectl get rootsyncs.configsync.gke.io -n config-management-system root-sync -o yaml

輸出內容範例：

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
status:
  sync:
    commit: f1739af550912034139aca51e382dc50c4036ae0
    lastUpdate: "2021-04-20T00:25:01Z"

如要查詢 RepoSync 物件，請執行下列指令：

kubectl get reposync.configsync.gke.io -n NAMESPACE repo-sync -o yaml

將 NAMESPACE 替換為您建立命名空間來源事實的命名空間。

輸出內容範例：

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
status:
  sync:
    commit: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
    lastUpdate: "2021-04-20T00:25:20Z"

這個修訂版本代表叢集最近的修訂版本。不過，叢集中的每個資源不會都受到每次提交的影響；如要查看特定資源的最新提交，請查詢該資源並查看 metadata.annotations.configmanagement.gke.io/token。例如：

kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml

將 CLUSTER_ROLE_NAME 替換為要查詢的叢集角色名稱。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    configmanagement.gke.io/token: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f

nomos 狀態旗標

如要自訂 nomos status 指令，請新增下列標記：

旗標 說明
--contexts 接受以半形逗號分隔的環境清單，用於多叢集指令。預設值為所有內容。如要不使用任何內容，請輸入「""」。
-h或--help nomos status 指令的說明。
--name 接受字串。使用這個標記，透過提供的名稱篩選根目錄和存放區同步。這個旗標可以與 namespace 旗標搭配使用。
--namespace 接受字串。使用 namespace 標記，將指令限制為特定命名空間的單一事實來源。如要取得所有來源，請將此欄位設為未設定。只有在啟用多個可靠資料來源的同步功能時，才能使用這個標記。
--poll 使用 poll 旗標持續執行 nomos status，並定期重新列印狀態表。例如 3s。請將這個標記設為未設定，以便執行 nomos status 一次
--resources 接受 true 或 false。如果 true，nomos status 會在從多個可靠資料來源同步時，顯示根層級或命名空間可靠資料來源的資源層級狀態。預設值為 true。
--timeout 連線至每個叢集的逾時時間。預設值為 3s。

所需權限

如果您是專案擁有者，則擁有 cluster-admin RBAC 角色，因此可以對專案中的任何叢集使用 nomos status 指令，不必新增任何其他權限。如果您沒有 cluster-admin 角色，可以建立下列 ClusterRole，使用 nomos status：

  1. 建立名為 nomos-status-reader.yaml 的檔案，然後將下列 ClusterRole 複製到檔案中。您需要的規則取決於是否使用 RootSync 和 RepoSync 物件。

    使用 RootSync 和 RepoSync 物件

    # nomos-status-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nomos-status-reader
rules:
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs", "rootsyncs"]
  verbs: ["get"]
- nonResourceURLs: ["/"]
  verbs: ["get"]

    未使用 RootSync 和 RepoSync 物件

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nomos-status-reader
rules:
- apiGroups: ["configmanagement.gke.io"]
  resources: ["configmanagements", "repos"]
  verbs: ["get", "list"]
- nonResourceURLs: ["/"]
  verbs: ["get"]

  2. 套用 nomos-status-reader.yaml 檔案：

    kubectl apply -f nomos-status-reader.yaml

檢查可靠資料來源是否有錯誤

將設定修訂到可靠來源之前，您可以使用 nomos vet 指令檢查可靠來源中設定的語法及有效性：

nomos vet --source-format unstructured

如果系統偵測到語法錯誤，nomos vet 指令會在非零狀態下結束，並將錯誤訊息記錄在 STDERR 中。

nomos vet flags

如要自訂 nomos vet 指令，請新增下列標記：

旗標 說明
--api-server-timeout 接受時間長度字串。設定與 Kubernetes API 伺服器通訊時的用戶端逾時。預設值為 15s。
--clusters 接受以半形逗號分隔的叢集名稱清單，用於多叢集指令。預設值為所有叢集。如要取消分群，請輸入 ""。
--format 接受 yaml 或 json。輸出格式。預設值為 yaml。
-h或--help nomos vet 指令的說明。
--keep-output 接受布林值。如果設為 true，系統會將算繪輸出內容儲存到您可使用 --output 標記指定的位置。
--namespace 接受字串。如果已設定，會將真實來源驗證為具有所提供名稱的命名空間真實來源。自動設定 --source-format=unstructured。
--no-api-server-check 接受布林值。如果 true，則會停用與 Kubernetes API 伺服器的通訊，以進行探索。如要進一步瞭解這個標記，請參閱「伺服器端驗證」一節。
--output 接受字串。算繪輸出的路徑。預設為 compiled 目錄。如果 --keep-output 設為 false，系統會忽略這個旗標。
--path 接受字串。Config Sync 可靠來源的根目錄路徑。預設值為「.」
--source-format 接受 hierarchy 或 unstructured。如果 hierarchy 或未設定，則會將可靠來源驗證為階層式可靠來源。如果 unstructured，則會將可靠來源驗證為 非結構化可靠來源。 如果您使用非結構化可靠資料來源，就必須設定這個標記。
--threshold 可選用整數。設定每個存放區允許的物件數量上限，如果超過上限，系統會顯示錯誤訊息。略過該旗標或使用 --threshold=0 停用物件數量上限驗證。提供不含值的標記即可使用預設的 1000，或使用 --threshold=N 設定特定限制。

伺服器端驗證

如果 nomos vet 指令無法判斷類型是否為命名空間，nomos 工具會連線至目前 kubectl 環境的 API 伺服器。由於 nomos 工具預設會瞭解核心 Kubernetes 型別和 Config Sync CRD，因此只有在 CR 沒有對應的已宣告 CRD 時，才會嘗試連線至 API 伺服器。在這種情況下，如果 API 伺服器未套用 CRD，nomos vet 指令會傳回錯誤 KNV1021。如要停用這項檢查並抑制缺少 CRD 的錯誤，請傳遞 --no-api-server-check 標記。

快取 API 伺服器中繼資料

您可以快取 API 伺服器上的資料，供 nomos vet 指令使用，不必抑制 API 伺服器檢查。如要快取 api-resources，請完成下列步驟：

  1. 連線至叢集，其中包含可靠資料來源所需的所有 CRD。叢集不需啟用 Config Sync。
  2. 前往可靠資料來源的 policyDir。這與 ConfigManagement 或 RootSync 資源中指定的目錄相同。
  3. 執行下列指令：kubectl api-resources > api-resources.txt 這項指令會建立名為 api-resources.txt 的檔案，其中包含 kubectl api-resources 的確切輸出內容。

從現在起，真實來源中的 nomos vet 執行作業會瞭解這些型別定義。如果移除或重新命名 api-resources.txt 檔案，nomos vet 就找不到該檔案。如果找到 api-resources.txt 中未宣告的型別資訊清單，nomos vet 仍會嘗試連線至叢集 (除非傳遞 --no-api-server-check)。

api-resources.txt 檔案只會影響 nomos 工具的運作方式，不會以任何方式修改 Config Sync 的行為。

api-resources.txt 檔案中可以有額外項目，這些項目適用於要驗證的真實來源中沒有的型別。nomos vet 會匯入定義，但不會對這些定義執行任何動作。

更新 api-resources.txt

確認叢集上已安裝所有需要的 CRD 後，請執行下列指令：

kubectl api-resources > api-resources.txt

修訂時自動檢查語法錯誤

如果您修訂的檔案含有 JSON 或 YAML 錯誤，Config Sync 就不會套用變更。不過，您可以利用用戶端或伺服器端的掛鉤，防止這類錯誤進入單一事實來源。

在修訂前掛鉤中使用 nomos vet

將變更修訂到存放區的 Git 本機副本時，您可以設定修訂前掛鉤，以執行 nomos vet 指令來檢查語法錯誤。如果修訂前掛鉤在非零狀態下結束，git commit 作業就會失敗。

如要將 nomos vet 指令當做修訂前掛鉤執行，請編輯真實來源中的 .git/hooks/pre-commit 檔案 (請注意，.git 的開頭為 . 字元)。您可能需要手動建立這個檔案。請將 nomos vet 指令新增到指令碼中新的一行。--path 引數為選用項目。將 --source-format 引數設為存放區的來源格式。

nomos vet --path=/path/to/repo --source-format unstructured

確保 pre-commit 檔案可以執行：

chmod +x .git/hooks/pre-commit

這樣一來，當您在真實現源的本機副本中執行 git commit 指令時，系統就會自動執行 nomos vet。

.git/ 目錄的內容不會由可靠來源本身追蹤，也無法修訂到可靠來源中的相同位置。您可以在 Git 掛鉤的單一可靠資料來源中建立目錄，以便單一可靠資料來源的使用者將掛鉤複製到本機副本中的正確位置。

在伺服器端掛鉤中使用 nomos vet

Git 提供一項在 git push 作業期間透過伺服器 (而不是用戶端) 執行檢查的機制。如果檢查失敗，git push 也會失敗。用戶端無法略過這類伺服器端掛鉤。伺服器端掛鉤的設定方式取決於 Git 伺服器的託管方式。詳情請參閱下列連結，或查閱您 Git 託管服務的說明文件。

強制執行要同步處理的物件數量上限

Config Sync 會在 ResourceGroup 目錄物件中儲存每個同步物件的參照，以及物件的目前狀態。由於 Kubernetes 對資源物件的位元組大小設有限制，因此 Config Sync 可透過單一 RootSync 或 RepoSync 同步處理的物件數量上限也受到限制。

根據預設，伺服器端的 etcd 大小上限為 1.5 MiB。詳情請參閱 etcd 說明文件。如果套用的物件超出這項限制，系統會根據物件大小，傳回下列其中一個錯誤：

  • etcdserver: request is too large
  • rpc error: code = ResourceExhausted desc = trying to send message larger than max
  • Request entity too large: limit is 3145728

為防止 ResourceGroup 物件超出 Kubernetes 大小限制，您可以使用 nomos vet --threshold 驗證來源存放區中的物件數量。

根據預設，使用 nomos vet 指令時，系統不會強制執行門檻。 如果來源存放區中的物件數量超過門檻，傳遞 --threshold 標記會導致 vet 指令發生錯誤。

ResourceGroup 目錄包含物件參照和目前的物件狀態。如果物件無法同步或調解，這個佇列可能會變得非常龐大。 為避免超過 Kubernetes 物件大小限制，請選擇可保留足夠容量來記錄物件錯誤的門檻。預設值 1000 應適用於幾乎所有情況，但您可以視需要提高或降低門檻。

這個門檻只會由 nomos vet 指令驗證，Config Sync 本身不會驗證。如要強制執行門檻，請在來源存放區預先提交檢查或 git 修訂前掛鉤中使用 nomos vet --threshold 指令。

查看可靠資料來源中的所有設定

您可以使用 nomos hydrate 指令，查看每個已註冊叢集上真實來源的合併內容。

如果執行 nomos hydrate 時沒有任何選項，系統會在目前的工作目錄中建立 compiled/ 目錄。在該目錄中，系統會為每個已註冊的叢集建立子目錄，其中包含運算子會套用至叢集的完整解析設定。

這個指令也可以使用 compiled/ 目錄中的內容，將階層式可靠資料來源轉換為一或多個非結構化可靠資料來源。

nomos hydrate 旗標

如要自訂 nomos hydrate 指令，請新增下列標記：

旗標 說明
--api-server-timeout 接受時間長度字串。設定與 Kubernetes API 伺服器通訊時的用戶端逾時。預設值為 15s。
--clusters 接受以半形逗號分隔的叢集名稱清單。使用這個標記可將輸出內容限制為單一叢集或叢集清單。預設值為所有叢集。如要取消分群，請輸入 ""。
--flat 啟用後，所有輸出內容都會列印至單一檔案。如要模擬 nomos view 的行為，請使用這個旗標。
--format 接受 yaml 或 json。輸出格式。預設值為 yaml。
-h或--help nomos hydrate 指令的說明。
--no-api-server-check 接受布林值。如果 true，則會停用與 API 伺服器的通訊，以進行探索。如要進一步瞭解這個標記，請參閱「伺服器端驗證」一節。
--output 接受字串。要寫入已補水設定的位置，預設值為 compiled 目錄。 如果未啟用 --flat，則會將每個資源資訊清單寫入個別檔案。 如果啟用 --flat，則會寫入單一檔案，其中包含所有資源資訊清單。
--path 接受字串。Config Sync 可靠來源的根目錄路徑。預設值為「.」
--source-format 接受 hierarchy 或 unstructured。如果 hierarchy 或未設定，則會將可靠來源驗證為階層式可靠來源。如果 unstructured，則會將可靠來源驗證為 非結構化可靠來源。 如果您使用非結構化可靠資料來源，就必須設定這個標記。

建立錯誤報告

如果 Config Sync 發生問題，需要Google Cloud 支援團隊協助，可以使用 nomos bugreport 指令提供有價值的偵錯資訊。您可以對單一可靠來源和多個存放區使用這項指令。

nomos bugreport

這項指令會產生含有時間戳記的 ZIP 檔案，其中包含 kubectl 環境中 Kubernetes 叢集的相關資訊。這個檔案也包含 Config Sync Pod 的記錄。不包含與 Config Sync 同步處理的資源資訊。如要進一步瞭解 ZIP 檔案內容，請參閱 nomos bugreport 參考資料。

限制

如果任何個別檔案超過 1 GiB，nomos bugreport 指令就會失敗，並產生不完整的 zip 檔案。這通常是因為記錄檔過大。

下表列出記錄檔過大的常見原因，以及解決方法：

原因 建議做法
記錄詳細程度提高 使用記錄層級覆寫功能，減少記錄詳細程度
非常大的物件 取消管理大型物件或縮減物件大小
許多物件 將存放區分割成多個存放區
控制器衝突 解決爭執

從 ConfigManagement 物件遷移至 RootSync 物件

您可以執行 nomos migrate 指令，從 ConfigManagement 物件遷移至 RootSync 物件，以啟用 RootSync 和 RepoSync API。

如果您使用 spec.enableLegacyFields 啟動 RootSync，請按照指南關閉舊版欄位，而不是使用 nomos migrate。從 1.19.0 版開始，系統不再支援舊版欄位。

nomos migrate 支援模擬測試，可預覽遷移程序。

nomos migrate 直接修改叢集上的 ConfigManagement 物件。為避免透過 nomos migrate 進行的變更遭到還原，請確保 ConfigManagement 物件未簽入可靠資料來源。

nomos migrate --contexts=KUBECONFIG_CONTEXTS --dry-run

如果模擬測試結果良好，您可以使用 nomos migrate 遷移 ConfigManagement 物件：

nomos migrate --contexts=KUBECONFIG_CONTEXTS

輸出結果會與下列內容相似：

--------------------
Enabling the multi-repo mode on cluster "my_managed_cluster-1" ...
- A RootSync object is generated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml".
- The original ConfigManagement object is saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-original.yaml".
- The ConfigManagement object is updated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml".
- Resources for the multi-repo mode have been saved in a temp folder. If the migration process is terminated, it can be recovered manually by running the following commands:
  kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml && \
  kubectl wait --for condition=established crd rootsyncs.configsync.gke.io && \
  kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml.
- Updating the ConfigManagement object ....
- Waiting for the RootSync CRD to be established ....
- The RootSync CRD has been established.
- Creating the RootSync object ....
- Waiting for the reconciler-manager Pod to be ready ....
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
- The reconciler-manager Pod is running.
- Waiting for the root-reconciler Pod to be ready ....
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- The root-reconciler Pod is running.
- The migration process is done. Please check the sync status with `nomos status`.

Finished migration on all the contexts. Please check the sync status with `nomos status`.

復原為先前的設定

如果您在透過 nomos migrate 執行遷移作業後需要回溯，請套用原始的 ConfigManagement 物件。nomos migrate 將原始 ConfigManagement 物件儲存至檔案，並將名稱列印至終端機。 檔案名稱的格式為 /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml。

如要還原先前的設定，請複製 cm-original.yaml 的檔案路徑，然後將檔案套用至叢集：

kubectl apply -f CM_ORIGINAL_PATH

nomos migrate 旗標

如要自訂 nomos migrate 指令，請新增下列標記：

旗標 說明
--connect-timeout 接受時間長度。連線至每個叢集的逾時時間長度。 預設值為 3s。
--contexts 接受以半形逗號分隔的環境清單，用於多叢集環境。預設為目前的內容。在所有情境中，使用 "all"。
--dry-run 接受布林值。如果 true，則只會列印遷移作業輸出內容。
-h或--help nomos migrate 指令的說明。
--remove-configmanagement 接受布林值。如果 true，則會移除 ConfigManagement Operator 和 ConfigManagement CRD，藉此遷移至 OSS Config Sync。
--wait-timeout 接受時間長度。等待 Kubernetes 資源條件為 true 的逾時時間長度。預設值為 10m。

初始化階層式可靠資料來源

如果您使用非結構化真相來源，可以任意整理真相來源。如果您使用階層式單一事實來源，則需要執行 nomos init 指令來初始化階層式目錄：

nomos init

這樣即可建立階層式可靠來源的基本目錄結構，包括 system/、cluster/ 和 namespaces/ 目錄。

nomos init 旗標

如要自訂 nomos init，請新增下列旗標：

旗標 說明
--force 即使目錄不為空白，仍要寫入，並覆寫衝突的檔案
-h或--help nomos init 指令的說明。
--path 接受字串。做為資料來源的根目錄。預設值為 "."

疑難排解

在 Linux 中執行 nomos 指令時，可能會看到下列錯誤訊息：

failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64

如要修正這個問題，請建立 USER 環境變數：

export USER=$(whoami)

後續步驟