本文档介绍了在使用 Backup for GKE 执行恢复操作时可能会遇到的错误和相应代码。每个部分都包含在执行操作以解决恢复错误时需要考虑的事项，以及有关如何解决恢复操作错误的说明。
错误 200010301：由于准入 Webhook 服务不可用，无法完成恢复操作
当尝试完成恢复操作失败时，会发生错误 200010301，这是因为准入webhook服务（也称为 HTTP 回调）不可用，从而导致以下错误消息。此错误消息表明，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 尚未恢复或准备就绪。这种情况发生在恢复操作期间，即在命名空间服务完全处于
ready状态之前应用集群范围的 webhook 配置。外部网址：由于 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：由于资源创建请求遭拒，无法完成恢复操作
当尝试完成恢复操作失败时，会发生错误 200010302，这是因为准入webhook拒绝了资源创建请求，从而导致以下错误消息，表明由于活跃的准入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。
当 Backup for 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 联系以获取进一步帮助。