本文說明使用 Backup for GKE 執行還原作業時，可能遇到的錯誤和對應代碼。每個章節都會說明執行動作來解決還原錯誤時的注意事項，以及如何解決還原作業錯誤。
錯誤 200010301：由於准入 Webhook 服務無法使用，因此無法完成還原作業
如果嘗試完成還原作業時，因准入 Webhook 服務 (也稱為 HTTP 回呼) 無法使用而失敗，就會發生錯誤 200010301，並顯示下列錯誤訊息。這則錯誤訊息表示 GKE API 伺服器嘗試在還原資源時聯絡許可控制器 Webhook，但支援該 Webhook 的服務無法使用或找不到：
resource [/example-group/ClusterSecretStore/example-store] restore failed:
Internal error occurred: failed calling webhook "example-webhook.io":
failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.
如果目標叢集中有作用中的 ValidatingAdmissionWebhook 或 MutatingAdmissionWebhook GKE 資源，但 GKE API 伺服器無法連上 Webhook 中設定的端點，就會發生這個錯誤。准入 Webhook 會攔截傳送至 GKE API 伺服器的要求，而其設定會指定 GKE API 伺服器應如何查詢要求。
Webhook 的 clientConfig 會指定處理准入要求的後端，可以是內部叢集服務或外部網址。這兩個選項的選擇取決於 Webhook 的具體作業和架構需求。視選項類型而定，還原作業可能因下列原因而失敗：
叢集內服務：GKE API 伺服器嘗試呼叫 Webhook 時，GKE 服務及其支援 Pod 未還原或準備就緒。在還原作業期間，如果叢集範圍的 Webhook 設定在命名空間服務完全處於
ready狀態前套用，就會發生這種情況。外部網址：由於 GKE 叢集與外部端點之間的網路連線問題，或 DNS 解析問題或防火牆規則，外部端點暫時無法使用。
如要解決這項錯誤，請按照下列說明操作：
找出錯誤訊息中提及的失敗 Webhook。例如
failed calling webhook "..."。執行
kubectl get validatingwebhookconfigurations指令，檢查 Webhook：kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml將
WEBHOOK_NAME替換為錯誤訊息中識別的 Webhook 名稱。您也可以使用
kubectl get mutatingwebhookconfigurations指令檢查 Webhook：kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml將
WEBHOOK_NAME替換為錯誤訊息中識別出的 Webhook 名稱。請根據設定類型執行下列疑難排解步驟：
根據服務
clientConfig如要定義自訂還原順序，請修改
RestorePlan資源，加入含有GroupKindDependency項目 的RestoreOrder。這樣一來，系統就能在ValidatingWebhookConfiguration或MutatingWebhookConfiguration之前，還原並準備好支援 Webhook 的元件，例如Deployment、StatefulSet或Service。如需如何定義自訂還原順序的操作說明，請參閱「在還原期間指定資源還原順序」。
這種做法可能會失敗，因為即使建立
Service物件，服務的 Pod 也不會進入完全ready狀態。失敗的另一個原因可能是其他應用程式意外建立 Webhook 設定。或者，您也可以按照下列步驟執行兩階段還原作業：使用備份建立
Restore資源，方法是透過精細的還原篩選器設定還原作業，其中會包含 Webhook 運作所需的特定資源，例如Namespaces、Deployments、StatefulSets或Services。如要進一步瞭解如何使用精細還原篩選器設定還原作業，請參閱「啟用精細還原功能」。
為備份作業建立另一個
Restore資源，並設定您選擇的其餘資源。
以網址為準
clientConfig驗證外部 HTTPS 端點，並確認該端點處於啟用狀態、可連線，且運作正常。
確認 GKE 叢集節點和控制層可連線至外部網址。您可能也需要檢查防火牆規則，例如使用虛擬私有雲、內部部署或代管 Webhook 的雲端服務供應商、網路政策和 DNS 解析時。
請重試還原作業。如果作業持續失敗，請聯絡 Cloud Customer Care 團隊尋求進一步協助。
錯誤 200010302：資源建立要求遭拒，因此無法完成還原作業
如果准入 Webhook 拒絕資源建立要求，導致還原作業無法完成，就會發生 200010302 錯誤。這時系統會顯示下列錯誤訊息，指出備份中的資源無法在目標叢集中建立，因為作用中的准入 Webhook 攔截了要求，並根據自訂政策拒絕要求：
[KubeError]; e.g. resource
[/example-namespace/example-api/ExampleResource/example-name]
restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}
這個錯誤是由目標 GKE 叢集中設定的內容所致，該叢集具有 ValidatingAdmissionWebhook 或 MutatingAdmissionWebhook，會對資源建立和修改作業強制執行特定規則，進而封鎖資源建立要求。舉例來說，Webhook 會禁止建立資源，因為叢集中已有相關但衝突的資源。舉例來說，如果部署作業已由 HorizontalPodAutoscaler GKE API 資源管理，Webhook 可能會拒絕建立部署作業。
如要解決這項錯誤，請按照下列說明操作：
使用還原作業失敗時發生的錯誤訊息，找出拒絕要求的 Webhook。舉例來說，
webhook WEBHOOK_NAME denied the request錯誤訊息包含下列資訊：Webhook 名稱：拒絕要求的 Webhook 名稱。
拒絕原因：拒絕要求的具體原因。
使用
kubectl get validatingwebhookconfigurations指令檢查 Webhook：kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml將
WEBHOOK_NAME替換為錯誤訊息中識別的 Webhook 名稱。您也可以使用
kubectl get mutatingwebhookconfigurations指令檢查 Webhook：kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml將
WEBHOOK_NAME替換為您從錯誤訊息中識別出的 Webhook 名稱。解決目標叢集中的根本問題。正確的動作取決於具體錯誤。以這個範例來說，如果發生
HorizontalPodAutoscaler衝突，您必須先刪除目標叢集中的現有HorizontalPodAutoscaler，再執行還原作業，才能建立備份的工作負載和相關聯的資源。請重試還原作業。如果還原作業持續失敗，請與 Cloud Customer Care 團隊聯絡，尋求進一步協助。
錯誤 200060202：工作負載驗證期間缺少 GKE 資源，因此無法完成還原作業
在還原作業的工作負載驗證階段，如果 Backup for GKE 預期要驗證的 GKE 資源在目標叢集中找不到，就會發生錯誤 200060202，並顯示下列錯誤訊息：
Workload Validation Error: [KIND] "[NAME]" not found
例如 Example: Workload Validation Error: pods "jenkins-0" not found。
當 GKE 備份功能在還原作業程序中，成功建立或更新 GKE 資源，但驗證階段開始時，一或多個 GKE 資源已不在目標叢集中，就會發生這個錯誤。這是因為資源在還原程序最初建立或更新後，但在 GKE 資源的工作負載驗證完成前遭到刪除。發生這類錯誤的可能原因如下：
手動刪除：使用者或管理員使用
kubectl或其他 Google Cloud 工具手動刪除資源。外部自動化：GitOps 控制器 (例如 Config Sync、ArgoCD、Flux、自訂指令碼或其他叢集管理工具) 還原或刪除了資源，以符合存放區中的所需狀態。
GKE 控制器：GKE 控制器刪除資源，是因為該資源與其他資源或政策衝突，或是
OwnerReference鏈導致垃圾收集，或是 GKE 的自動清除程序在刪除owner資源時，一併刪除依附資源。
如要解決這項錯誤，請按照下列說明操作：
如果還原作業無法完成，請使用顯示的錯誤訊息找出缺少的資源。
使用下列其中一種方法，找出資源所屬的命名空間：
GKE 稽核記錄：檢查您嘗試還原作業時產生的 GKE 稽核記錄。您可以篩選資源
Kind和Name的刪除作業記錄。稽核記錄項目包含原始命名空間。備份詳細資料：查看還原作業的範圍和備份內容。備份索引會顯示資源的原始命名空間。您也可以驗證
RestorePlan是否包含TransformationRule，其中指定了在所選命名空間中還原資源的規則。跨命名空間搜尋：使用
kubectl get指令在所有命名空間中搜尋資源：kubectl get KIND --all-namespaces | grep NAME將
KIND和NAME替換為錯誤訊息中的值。如果資源仍存在，這項指令會顯示其命名空間。
使用
kubectl get指令驗證刪除作業：kubectl get KIND NAME -n [NAMESPACE]將
KIND和NAME替換為錯誤訊息中的值。您應該會收到not found錯誤訊息。請使用下列其中一種方法，調查刪除原因：
GKE 稽核記錄：識別發出刪除要求的實體。例如使用者、服務帳戶或控制器。
檢查已設定的自動化程序：如果您使用 GitOps 或其他自動化工具，請檢查這些工具的記錄和狀態，確認是否干擾了還原的資源。
檢查相關事件：使用
kubectl get events指令，在已判斷的命名空間中檢查 GKE 事件：kubectl get events -n NAMESPACE --sort-by='.lastTimestamp'將
NAMESPACE替換為命名空間名稱。
根據上一步的結果，解決資源刪除的原因。例如暫停衝突的自動化功能、修正設定錯誤，或調整使用者權限。
請使用下列其中一種方法復原遺失的資源：
重新套用資訊清單檔案：如果遺失的資源有資訊清單，可以重新套用至正確的命名空間。
執行精細還原：執行精細還原作業，從相同備份中選擇性還原遺失的資源，確保您指定正確的命名空間。如要進一步瞭解如何執行精細還原作業，請參閱「啟用精細還原功能」。
請重試還原作業。如果還原作業持續失敗，請與 Cloud Customer Care 團隊聯絡，尋求進一步協助。