本文档介绍了在使用 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 中配置的端点时，会发生此错误。准入网络钩子会拦截发送到 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：由于资源创建请求遭拒，无法完成恢复操作
当尝试完成恢复操作失败时，会发生错误 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_NAME --sort-by='.lastTimestamp'将
NAMESPACE_NAME替换为命名空间的名称。
根据上一步的结果，解决资源删除的原因。例如，暂停冲突的自动化操作、更正错误配置或调整用户权限。
使用以下方法之一恢复丢失的资源：
重新应用清单文件：如果您有缺失资源的清单，可以将其重新应用到正确的命名空间。
执行精细恢复：执行精细恢复操作，以从同一备份中选择性地恢复丢失的资源，确保您指定正确的命名空间。如需详细了解如何执行精细恢复操作，请参阅启用精细恢复。
重试恢复操作。如果恢复操作仍失败，请与 Cloud Customer Care 联系以获取进一步帮助。
错误 200060201：因工作负载验证超时而无法完成恢复操作
当一个或多个已恢复的工作负载在集群中创建资源后，在预期的时间限制内未能完全变为 ready 时，就会出现错误 200060201，从而导致以下错误消息：
Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]
出现此错误的原因是，Backup for GKE 在恢复 GKE 资源配置后会执行验证步骤，以确保关键工作负载正常运行。Backup for GKE 会等待某些工作负载达到 ready 状态，但至少有一个工作负载在分配的超时时间内未满足以下就绪条件：
对于
Pods：status.Phase为Running对于
Deployments：status.ReadyReplicas等于spec.Replicas对于
StatefulSets：status.ReadyReplicas等于spec.Replicas对于
DaemonSets：status.NumberReady等于status.DesiredNumberScheduled
如需解决此错误，请按照以下说明操作：
在错误消息中，找出未处于
ready状态的工作负载。该消息会列出未能进入ready状态的工作负载及其命名空间。运行
kubectl describe命令，检查工作负载状态并获取失败工作负载的详细信息和事件：kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD替换以下内容：
WORKLOAD_TYPE：工作负载的类型，例如Deployment、StatefulSet或DaemonSet。WORKLOAD_NAME：特定工作负载实例的名称。NAMESPACE_NAME：工作负载所在的命名空间。SELECTOR_FOR_WORKLOAD：用于查找与工作负载关联的Pods的标签选择器。例如app=my-app。
对于
Deployments或StatefulSets工作负载类型中的 pod，请运行kubectl describe pod命令来检查各个 pod 的状态：kubectl describe pod POD_NAME -n NAMESPACE_NAME替换以下内容：
POD_NAME：特定 pod 的名称。NAMESPACE_NAME：Pod 所在的命名空间。
在
Events部分中，分析describe输出中的事件和日志，并找到以下信息：ImagePullBackOff / ErrImagePull：表示提取容器映像时存在问题。CrashLoopBackOff：表示容器正在启动并崩溃。
在
Containers部分中，分析describe输出中的容器日志，通过运行kubectl logs命令找到容器名称：kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME替换以下内容：
POD_NAME：特定 pod 的名称。NAMESPACE_NAME：Pod 所在的命名空间。CONTAINER_NAME：Pod 中容器的名称。
根据
describe输出，Pod 可能未显示在资源输出中，原因有多种，包括：就绪性探测失败：容器的就绪性探测未成功。
资源问题：集群中的 CPU、内存或其他资源不足，或者已达到配额限制。
init 容器问题：init 容器中的故障阻止了主容器启动。
配置错误：
ConfigMaps、Secrets或环境变量中的错误。网络问题：
Pods无法与所需服务通信。
检查 GKE 集群资源，确保 GKE 集群具有足够的节点容量、CPU 和内存来运行已恢复的工作负载。在 Autopilot 集群中，节点自动预配可能需要额外的时间，因此，我们建议您检查是否存在任何节点伸缩限制或错误。根据您的发现解决潜在问题，并解决阻止工作负载进入
ready状态的问题。此方法可能涉及更正清单、调整资源请求或限制、修复网络政策，或确保满足依赖项。解决潜在问题后，等待工作负载进入
ready状态。您无需再次运行恢复操作。
如果问题仍然存在，请与 Cloud Customer Care 联系以获取进一步帮助。
错误 200060102：由于卷验证错误，无法完成恢复操作
错误 200060102 的出现是因为一个或多个 VolumeRestore 资源（用于管理将数据从 VolumeBackup 恢复到 PersistentVolume 的过程）在恢复操作的卷验证阶段进入了 failed 或 deleting 状态。卷恢复失败会导致恢复资源的 stateReason 字段中显示以下错误消息：
Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]
错误消息会列出失败的 VolumeRestore 的完整资源名称，包括目标 PersistentVolumeClaim 名称和命名空间。此错误消息表明，当 Backup for GKE 启动 VolumeRestore 资源以从 VolumeBackups 预配 PersistentVolumes 时，受影响的 PersistentVolumeClaim 的数据恢复过程未成功完成，并且从快照创建底层 Persistent Disk 失败。VolumeRestore 失败可能由以下原因导致：
配额不足：项目或区域中分配的 Persistent Disk 配额不足，例如
SSD_TOTAL_GB。权限问题：Backup for GKE 使用的服务账号缺少创建磁盘或访问快照所需的权限。
网络问题：存在暂时性或持续性网络问题，导致磁盘创建过程中断。
无效的快照：来源
VolumeBackup或底层 Persistent Disk 快照已损坏或无法访问。资源限制：其他集群资源限制阻碍了卷配置。
内部错误：Persistent Disk 服务存在内部问题。
如需解决此错误，请按照以下说明操作：
确定错误消息中列出的失败的
PersistentVolumeClaims，其中列出了失败的VolumeRestore对象的完整资源名称。运行
gcloud beta container backup-restore volume-restores describe命令，获取每个失败的VolumeRestore资源的详细信息：gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \ --project=PROJECT_ID \ --location=LOCATION \ --restore-plan=RESTORE_PLAN_ID \ --restore=RESTORE_ID替换以下内容：
VOLUME_RESTORE_ID：失败的VolumeRestore资源的 ID。PROJECT_ID：您的 Google Cloud 项目的 ID。LOCATION：恢复的 Google Cloud 位置。RESTORE_PLAN_ID：恢复方案的 ID。RESTORE_ID：恢复操作的 ID。
检查输出中的
state和stateMessage字段，了解有关失败的详细信息。运行
kubectl get pvc命令，检查目标PersistentVolumeClaim的状态：kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml替换以下内容：
PVC_NAME：PersistentVolumeClaim资源的名称。NAMESPACE_NAME：PersistentVolumeClaim所在的命名空间。
确认输出的
status.phase部分显示的是Pending阶段。此阶段意味着PersistentVolumeClaim尚未绑定到PersistentVolume，如果VolumeRestore失败，则这是预期行为。检查 YAML 输出中的
Events部分，查找与配置失败相关的消息，例如ProvisioningFailed：Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY: Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).输出表明，在创建磁盘期间访问加密密钥时存在权限问题。如需提供
compute service agent访问密钥的相关权限，请按照 Backup for GKE 文档中有关启用 CMEK 加密的说明操作。运行
kubectl get events命令，查看PersistentVolumeClaim命名空间中的 GKE 事件，这些事件会提供来自PersistentVolume控制器或 CSI 驱动程序的详细错误消息：kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'将
NAMESPACE_NAME替换为PersistentVolumeClaim的命名空间，识别与
PersistentVolumeClaim名称相关的事件，该名称包含FailedProvisioning或ExternalProvisioning等关键字。 这些事件还可能包含来自存储空间配置程序的错误，例如pd.csi.storage.gke.io。检查 Cloud Audit Logs 和 Cloud Logging 中的 Persistent Disk 日志，看看在故障发生前后是否存在与磁盘创建操作相关的任何错误，从而检查 Persistent Disk 日志。
根据生成的错误消息，解决以下潜在问题：
如果系统指示，请增加永久性磁盘配额，例如
(QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded。验证并更正 IAM 权限。
调查并解决网络问题。
请与 Cloud Customer Care 联系，以解决快照或 Persistent Disk 服务方面的问题。
PersistentVolumeClaim仍处于Pending状态。恢复操作流程不会自动重试
VolumeRestore。如需解决此问题，您应针对使用受影响的PersistentVolumeClaim的Deployment或StatefulSet工作负载触发恢复操作。使用精细恢复功能，有选择地恢复与失败的
PersistentVolumeClaim关联的Deployment或StatefulSet工作负载。如果底层问题得到解决，此方法可让标准 GKE 机制再次处理PersistentVolumeClaim创建和绑定过程。如需详细了解精细恢复，请参阅启用精细恢复。
如果问题仍然存在，或者 VolumeRestore 失败的原因尚不清楚，请与 Cloud Customer Care 联系以获取进一步帮助。
错误 200060101：由于卷验证超时，无法完成恢复操作
在恢复操作的卷验证阶段，如果至少一个负责从 VolumeBackup 恢复数据的 VolumeRestore 资源在分配的超时时间内未达到 succeeded 状态，导致 Backup for GKE 停止等待，则会发生错误 200060101。其他 VolumeRestore 资源也可能不完整。
Restore 资源的 stateReason 字段中的错误消息显示了在检查超时时遇到的第一个尚未处于 succeeded 状态的 VolumeRestore 资源。它包含特定 VolumeRestore 的目标 PersistentVolumeClaim 名称和命名空间，例如：
Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME)]
Backup for GKE 会启动 VolumeRestore 资源，以从 VolumeBackups 预配 PersistentVolumes。此错误表明，从快照创建底层 Persistent Disk 以及随后将 PersistentVolumeClaim 绑定到 PersistentVolume 的时间超过了所引用 VolumeRestore 的计算超时时间。同一恢复操作的其他 VolumeRestores 也可能处于未完成状态。
即使从 Backup for GKE 的角度来看已达到超时时间，上述 VolumeRestore 资源（可能还有 VolumeRestore 资源）的底层磁盘创建过程可能仍在进行中或已失败。
如需解决此问题，请按照以下说明操作：
在错误消息中找到超时的
PersistentVolumeClaim名称和命名空间，例如(PVC: PVC_NAMESPACE/PVC_NAME)。运行
gcloud beta container backup-restore volume-restores list命令，列出与恢复操作关联的所有VolumeRestores，以查看它们的当前状态：gcloud beta container backup-restore volume-restores list \ --project=PROJECT_ID \ --location=LOCATION \ --restore-plan=RESTORE_PLAN_NAME \ --restore=RESTORE_NAME替换以下内容：
PROJECT_ID： Google Cloud 项目的 ID。LOCATION：恢复的 Google Cloud 位置。RESTORE_PLAN_NAME：恢复方案的名称。RESTORE_NAME：恢复操作的名称。
找到未处于
succeeded状态的VolumeRestores。运行
gcloud beta container backup-restore volume-restores describe命令，获取错误中提及的VolumeRestore以及任何其他未处于succeeded状态的VolumeRestores的详细信息：gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \ --project=PROJECT_ID \ --location=LOCATION \ --restore-plan=RESTORE_PLAN_NAME \ --restore=RESTORE_NAME替换以下内容：
VOLUME_RESTORE_ID：VolumeRestore资源的 ID。PROJECT_ID：您的 Google Cloud 项目的 ID。LOCATION：恢复的 Google Cloud 位置。RESTORE_PLAN_NAME：恢复方案的名称。RESTORE_NAME：恢复操作的名称。
检查
state和stateMessage字段。state字段的值很可能是creating或restoring。stateMessage字段可能会提供更多背景信息，并包含目标PersistentVolumeClaim详细信息。运行
kubectl get pvc命令，检查已识别的目标PersistentVolumeClaims的状态：kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml替换以下内容：
PVC_NAME：PersistentVolumeClaim的名称。PVC_NAMESPACE：PersistentVolumeClaim的命名空间。
PersistentVolumeClaim'sstatus.phase的值很可能为Pending。在Events部分中检查是否存在以下错误：Waiting for first consumer to be created before binding：表示StorageClass具有volumeBindingMode: WaitForFirstConsumer。PersistentVolume的预配会延迟，直到创建并调度使用PersistentVolumeClaim的Pod。问题可能出在Pod调度上，而不是卷配置本身。因此，我们建议您确认Pods消耗PersistentVolumeClaim的原因，看看它们为何未被调度或未启动。FailedProvisioning或存储空间配置程序中的错误：例如pd.csi.storage.gke.io。
运行
kubectl get events命令，查看相关命名空间中的 GKE 事件：kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'将
PVC_NAMESPACE替换为PersistentVolumeClaim的命名空间。查找与
PersistentVolumeClaim名称相关的事件，例如配置消息或错误。在 Cloud Logging 中检查 Cloud Audit Logs 和 Persistent Disk 日志。
监控处于
creating和restoring状态的所有VolumeRestores的状态。问题修复后，
VolumeRestores的状态可以转换为succeeded或failed状态。如果VolumeRestores达到succeeded状态，PersistentVolumeClaims应变为Bound，并且工作负载应正常运行。如果任何VolumeRestore进入failed状态，您需要执行问题排查步骤来解决卷验证错误。如需了解详情，请参阅错误 200060102：因卷验证错误而无法完成恢复操作
如果 VolumeRestores 长时间保持 creating 或 restoring 状态，请与 Cloud Customer Care 联系以获取进一步帮助。