Gerenciar conflitos de recursos durante a restauração
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Autopilot
Standard
Nesta página, descrevemos como configurar estratégias de tratamento de conflitos para
recursos com namespace e com escopo de cluster em um plano de restauração.
Ao restaurar em um cluster, talvez você encontre conflitos de recursos nos seguintes cenários:
Fazer a restauração para um cluster atual que já tenha recursos provisionados.
Quando um recurso do Kubernetes é gerenciado por ferramentas, como o GitOps ou um operador.
O Backup para GKE oferece várias opções para definir o gerenciamento de conflitos
recursos com escopo de cluster e com namespace que podem ser especificados em um plano de restauração.
Restaurar o tratamento de conflitos para recursos com escopo de cluster
É possível configurar as seguintes opções no plano de restauração para lidar com conflitos
para recursos com escopo de cluster:
Manter os recursos no cluster de destino (não destrutivo): se um recurso com
o mesmo nome no cluster de destino, não mude nada.
Substituir recursos no cluster de destino (destrutivo): se um recurso já
no cluster de destino, excluir e restaurar a cópia do backup.
gcloud
Atualize um plano de restauração atual para lidar com conflitos relacionados a um recurso com escopo de cluster:
CLUSTER_RESOURCE_CONFLICT_POLICY: define como lidar com conflitos de tempo de restauração para recursos de cluster selecionados. Use uma das seguintes opções:
use-existing-version: se os recursos que estão sendo restaurados
já existirem no cluster de destino, o Backup para GKE manterá os
recursos atuais.
use-backup-version: se os recursos que estão sendo restaurados
já existirem no cluster de destino, o Backup para GKE substituirá os
recursos atuais pelos novos recursos do backup.
Console
Use as instruções a seguir para atualizar a política de conflito de recursos com escopo de cluster no console do Google Cloud:
No Console do Google Cloud, acesse a página do Google Kubernetes Engine.
Na seção Restaurar configurações, acesse a seção Recursos com escopo de cluster e clique em Editar.
Na seção Definir o tratamento de conflitos, selecione uma opção.
Clique em Salvar.
Restaurar o tratamento de conflitos para recursos com namespace
No plano de restauração, é possível configurar as seguintes opções para gerenciar conflitos
para um recurso com namespace. É possível especificar o tratamento de conflitos para
nos seguintes níveis:
Recurso individual
Namespace e ProtectedApplication
.
Confira a seguir as opções disponíveis para lidar com conflitos de recursos individuais:
Mesclar pular (não destrutivo): se um recurso específico já existir,
pular a restauração do recurso a partir do backup.
Mesclar o volume de substituição (destrutivo): se um recurso específico já existir,
pular a restauração desse recurso, mas substituir o volume permanente subjacente
usando a política de restauração de dados de volume. O volume de substituição de mesclagem atinge
a restauração somente de dados.
Mesclar substituição (destrutivo): se um recurso específico já existir,
substitua esse recurso pelo do backup e do volume associado
de dados seguindo a política de restauração de dados de volume.
Confira a seguir as opções disponíveis para lidar com conflitos de todos os recursos
pertencentes a um Namespace e ProtectedApplication:
Falha em caso de conflito (não destrutivo): se o namespace ou
ProtectedApplication destinada à restauração de um backup que já
existir no cluster de destino, a restauração falhará.
Reversão (destrutiva): quando o cluster de destino contém o namespace
ou ProtectedApplication, que são direcionadas para restauração no cluster,
o grupo de recursos atual é excluído antes que os novos recursos sejam restaurados.
gcloud
Atualize um plano de restauração existente para lidar com conflitos de um recurso com namespace:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-08-31 UTC."],[],[],null,["# Handle resource conflicts during restore\n\nAutopilot Standard\n\n*** ** * ** ***\n\nThis page describes how to configure conflict handling strategies for\nnamespaced and cluster-scoped resources in a restore plan.\n\nWhen restoring to a cluster, you might encounter resource conflicts in the following scenarios:\n\n- Restoring to an existing cluster that already has resources provisioned.\n- When a Kubernetes resource is managed by tools, such as GitOps or an [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/).\n\nBackup for GKE provides various options to define conflict handling for\ncluster-scoped and namespaced resources that you can specify in a [restore plan](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/restore-plan#create_a_restore_plan).\n\nRestore conflict handling for cluster-scoped resources\n------------------------------------------------------\n\nYou can configure the following options in the restore plan to handle conflicts\nfor a cluster-scoped resources:\n\n- **Keep resources in target cluster (non-destructive)**: if a resource with the same name exists in the target cluster, leave it as it is.\n- **Replace resources in target cluster (destructive)**: if a resource already\n exists in the target cluster, delete it and restore the copy from the backup.\n\n | **Warning:** This option could cause unintentional data loss if used inappropriately. For example, deleting a `CustomResourceDefinition` will cause Kubernetes to delete all custom `CustomResource` of that type.\n\n### gcloud\n\nUpdate an existing restore plan to handle conflict for a cluster-scoped resource: \n\n gcloud beta container backup-restore restore-plans update \u003cvar translate=\"no\"\u003eRESTORE_PLAN\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e \\\n --cluster-resource-conflict-policy=\u003cvar translate=\"no\"\u003eCLUSTER_RESOURCE_CONFLICT_POLICY\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eRESTORE_PLAN\u003c/var\u003e: the name of the restore plan that you want to update.\n- \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: the ID of your Google Cloud project.\n- \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e: the [compute region](/compute/docs/regions-zones#available) for the resource, for example `us-central1`.\n- \u003cvar translate=\"no\"\u003eCLUSTER_RESOURCE_CONFLICT_POLICY\u003c/var\u003e: defines how to handle restore-time conflicts for selected cluster resources. Use one of the following options:\n\n - \u003cvar translate=\"no\"\u003euse-existing-version\u003c/var\u003e: if the resources that are being restored already exist in the target cluster, Backup for GKE keeps the existing resources.\n - \u003cvar translate=\"no\"\u003euse-backup-version\u003c/var\u003e: if the resources that are being restored already exist in the target cluster, Backup for GKE replaces the existing resources with the new resources from the backup.\n\n### Console\n\nUse the following instructions to update cluster-scoped resources conflict policy in the Google Cloud console:\n\n1. In the Google Cloud console, go to the **Google Kubernetes Engine** page.\n\n [Go to Google Kubernetes Engine](https://console.cloud.google.com/kubernetes/list)\n2. In the navigation menu, click **Backup for GKE**.\n\n3. Click the **Restore plans** tab.\n\n4. Click the restore plan name.\n\n5. Click the **Details** tab.\n\n6. In the **Restore configurations** section, go to the **Cluster-scoped resources** section and click **Edit**.\n\n7. In the **Define conflict handling** section, select a conflict handling option.\n\n8. Click **Save changes**.\n\nRestore conflict handling for namespaced resources\n--------------------------------------------------\n\nIn the restore plan, you can configure the following options to manage conflict\nfor a namespaced resource. You can specify conflict handling for namespaced\nresources at the following levels:\n\n- Individual resource\n- Namespace and ProtectedApplication\n\n| **Note:** If the restore plan includes destructive policies, such as merge replace volume, merge replace, and rollback, the PV and volume continue to exist but become orphaned and unused if the reclaim policy is [Retain](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#retain). If the reclaim policy is [Delete](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#delete), the PV and volume are deleted.\n\nThe following are the available options to handle conflicts for the individual resources:\n\n- **Merge skip (non-destructive)**: if a specific resource already exists, skip restoring the resource from the backup.\n- **Merge replace volume (destructive)**: if a specific resource already exists, skip restoring that resource but replace the underlying persistent volume using the volume data restore policy. The merge replace volume achieves the data-only restore.\n- **Merge replace (destructive)**: if a specific resource already exists, replace that resource with the one from backup and the associated volume data by following the volume data restore policy.\n\nThe following are the available options to handle conflicts of all resources\nbelonging to a **Namespace** and **ProtectedApplication**:\n\n- **Fail on conflict (non-destructive)** : if namespace or [ProtectedApplication](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/protected-application) targeted for restore from a backup that already exists in the target cluster, the restore fails.\n- **Rollback (destructive)** : when the target cluster contains the namespace\n or [ProtectedApplication](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/protected-application) that are targeted for restore to the cluster,\n the existing group of resources is deleted before the new resources are restored.\n\n### gcloud\n\nUpdate an existing restore plan to handle conflict for a namespaced resource: \n\n gcloud beta container backup-restore restore-plans update \u003cvar translate=\"no\"\u003eRESTORE_PLAN\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e \\\n --namespaced-resource-restore-mode=\u003cvar translate=\"no\"\u003eNAMESPACED_RESOURCE_RESTORE_MODE\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eRESTORE_PLAN\u003c/var\u003e: the name of the restore plan that you want to update.\n- \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: the ID of your Google Cloud project.\n- \u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e: the [compute region](/compute/docs/regions-zones#available) for the resource, for example `us-central1`.\n- \u003cvar translate=\"no\"\u003eNAMESPACED_RESOURCE_RESTORE_MODE\u003c/var\u003e: defines how to\n handle restore-time conflicts for namespaced resources. Use one of the following options:\n\n - \u003cvar translate=\"no\"\u003emerge-skip-on-conflict\u003c/var\u003e: skip the individual conflicting resources.\n - \u003cvar translate=\"no\"\u003emerge-replace-volume-on-conflict\u003c/var\u003e: skip the individual conflicting resources but replace the underlying persistent volume data.\n - \u003cvar translate=\"no\"\u003emerge-replace-on-conflict\u003c/var\u003e: replace the individual conflicting resources and underlying persistent volume data.\n - \u003cvar translate=\"no\"\u003efail-on-conflict\u003c/var\u003e: to fail on conflicting namespace or [ProtectedApplication](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/protected-application).\n - \u003cvar translate=\"no\"\u003edelete-and-restore\u003c/var\u003e: roll back conflicting namespace or [ProtectedApplication](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/protected-application).\n\n### Console\n\nUse the following instructions to update namespaced resources conflict policy in the Google Cloud console:\n\n1. In the Google Cloud console, go to the **Google Kubernetes Engine** page.\n\n [Go to Google Kubernetes Engine](https://console.cloud.google.com/kubernetes/list)\n2. In the navigation menu, click **Backup for GKE**.\n\n3. Click the **Restore Plans** tab.\n\n4. Click the restore plan name.\n\n5. Click the **Details** tab.\n\n6. In the **Restore configurations** section, go to the **Namespaced resources** section and click **Edit**.\n\n7. In the **Define conflict handling** section, select a conflict handling option.\n\n8. Click **Save changes**.\n\nRecommended conflict handlings for common scenarios\n---------------------------------------------------\n\nThe following table lists the recommended conflict handling strategies for certain common scenarios:\n\nWhat's next\n-----------\n\n- Learn more about [restoring a backup](/kubernetes-engine/docs/add-on/backup-for-gke/how-to/restore)."]]