匯入程序包含四個階段。

第 1 階段：

從管理程式 API 中擷取所有資源。根據 Kubernetes 叢集標籤 (NCP/叢集) 或在 user-spec.yaml 中指定的共用資源來篩選資源。開始製作要傳送至移轉伺服器的要求本文。如果有任何要求無法產生，NCP 將不會移轉叢集並結束。

預期的故障和解決方案：
  • 由於連線問題，無法從管理程式 API 中擷取資源

    解決方案：修正連線問題後重試

  • Kubernetes 不包含從管理程式 API 中擷取的資源

    解決方案：再次在管理程式模式中執行 NCP，直到其達到閒置狀態為止，這表示不會執行任何 CRUD (建立、讀取、更新、刪除) 作業。您應等待至少 10 分鐘，因為這是 NCP 傳送重試要求之前的最大時間間隔。如果 NCP 記錄中沒有任何錯誤，則此問題應已修正。

第 2 階段：

開始將第 1 階段中建立的匯入要求傳送到移轉 API。成功處理要求之後，請將要求中包含的 manager_ids 記錄在用戶端的本機磁碟上。如果有任何要求失敗，請使用儲存在本機磁碟上的 manager_ids 將已匯入的資源復原。如果移轉 API 告知其為重複的要求，則匯入工具會將其 manager_id 從要求本文中移除，然後再次傳送要求。

預期的故障和解決方案：
  • 連線問題

    解決方案：修正連線問題後重試

  • 移轉 API 傳回錯誤

    解決方案：在一段時間後重試，因為它可能是有錯的原則 API 或移轉 API。如果此問題仍存在，請使用 config.yaml 中的 rollback_imported_resources 選項，在匯入工具無預警停止時復原所有匯入的資源。依預設，如果在此階段發生任何問題，則匯入工具會復原。但是，如果復原期間發生問題，您必須手動再試一次。如果使用 mp_to_policy_importer 復原未成功，則必須先將 NSX Manager 從備份還原到狀態，然後再匯入 Kubernetes 叢集。

附註：如果已匯入 DFW 區段和規則，且資源的匯入要求在之後失敗，您必須使用已建立的備份還原管理程式的狀態，然後再次啟動叢集匯入。

第 3 階段：

針對所有匯入的資源，推斷需要在原則的資源上新增/移除的標籤。如果有任何標籤無法推斷 (原因可能為遺失對應的 Kubernetes 資源)，則匯入工具會使用其儲存在本機磁碟上的 manager_ids 將已匯入的資源復原。管理程式模式中的 NCP 在交易期間停止時，即可能會發生此情況。因此，您應再次啟動處於管理程式模式的 NCP，並等待一段時間。

預期的故障和解決方案：
  • Kubernetes 不包含從管理程式 API 中擷取的資源

    解決方案：在復原後，請再次在管理程式模式中執行 NCP，直到其達到閒置狀態為止。您應等待至少 10 分鐘，因為這是 NCP 傳送重試要求之前的最大時間間隔。如果 NCP 記錄中沒有任何錯誤，則此問題應已修正。

第 4 階段：

這是最重要的階段。強烈建議不要在此階段中發生未預期的故障。在此階段中，匯入工具將使用新的標籤和/或其他資訊來更新原則上的資源 (例如，匯入工具將會更新區段的 display_name)。如果目前無法更新資源，則匯入工具會將更新的原則資源主體和原則資源 URL 儲存在用戶端的本機磁碟上，並在修正問題後要求您再試一次 (此問題屬於原則 API 或連線問題)。

預期的故障和解決方案：
  • 連線問題

    解決方案：修正連線問題後重試

在所有四個階段中，還會出現未預期的電源故障和其他問題的風險，這些問題將如 失敗與復原 中的討論進行處理。