本页面介绍了 Google Distributed Cloud (GDC) air-gapped 中提供的不同受保护应用策略。
受保护的应用策略可让您运行特定的执行前和执行后钩子,并为静止、备份或恢复有状态的工作负载定义自定义行为。
定义 ProtectedApplication
资源时,有三种备份和恢复策略可供使用:
策略定义可以包含以下值:
类型 | 属性 | 说明 |
---|---|---|
BackupAllRestoreAll |
备份和恢复组件中的所有内容。 | |
backupPreHooks |
要在备份之前执行的钩子列表。 | |
backupPostHooks |
备份后要执行的钩子列表。 | |
volumeSelector |
用于指定要备份哪些永久性卷的标签选择器。如果为空,则选择所有 PV。 | |
backupOneRestoreAll |
备份所选 pod 的一个副本,并使用该副本恢复所有 pod。 | |
backupTargetName |
用于备份的首选 Deployment 或
StatefulSet 的名称。 |
|
backupPreHooks |
要在备份之前执行的钩子列表。 | |
backupPostHooks |
备份后要执行的钩子列表。 | |
volumeSelector |
用于指定要备份哪些永久性卷的标签选择器。如果为空,则选择所有 PV。 | |
dumpAndLoad |
使用专用卷进行备份和恢复。 | |
dumpTarget |
指定用于转储组件数据的首选 Deployment 或 StatefulSet 的名称。目标 pod 的选择取决于相应组件的构成方式:
|
|
loadTarget
|
指定用于加载组件数据的首选 Deployment 或 StatefulSet 的名称。目标 pod 的选择取决于相应组件的构成方式:
|
|
dumpHooks |
用于转储数据的钩子列表。 | |
backupPostHooks |
备份后要执行的钩子列表。 | |
loadHooks |
用于从专用卷加载相应组件数据的钩子列表。它还可能包括加载完成后的清理步骤。执行目标 pod 是从 LoadTarget 中选择的 pod 之一。 |
|
volumeSelector |
用于指定要备份哪些永久性卷的标签选择器。如果为空,则选择所有 PV。 |
全部备份和全部恢复
此策略会在备份期间备份所有应用资源,并在恢复期间恢复所有这些资源。此策略最适合独立应用,即应用在 Pod 之间没有复制。
对于“全部备份和全部恢复”策略,请在资源定义中包含以下信息:
钩子:定义在执行卷备份之前和之后执行的命令,例如应用静默和取消静默步骤。这些命令在组件中的所有 pod 上执行。
卷选择:便于更精细地选择在组件中备份和恢复哪些卷。未选中的卷都不会备份。在恢复期间,备份期间跳过的任何卷都将恢复为空的卷。
此示例会创建一项 ProtectedApplication
资源,以在备份日志卷之前将文件系统设为静默状态,并在备份后取消静默状态:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
name: nginx
namespace: sales
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: nginx
components:
- name: nginx-app
resourceKind: Deployment
resourceNames: ["nginx"]
strategy:
type: BackupAllRestoreAll
backupAllRestoreAll:
backupPreHooks:
- name: fsfreeze
container: nginx
Commands: [ /sbin/fsfreeze, -f, /var/log/nginx ]
backupPostHooks:
- name: fsunfreeze
container: nginx
commands: [ /sbin/fsfreeze, -u, /var/log/nginx ]
备份一个和全部恢复
此策略会备份所选 pod 的一个副本。该单个副本是恢复期间用于恢复所有 pod 的来源。这种方法可以帮助降低存储费用和缩短备份时间。此策略适合高可用性配置,此时使用一个主要 PersistentVolumeClaim
和多个辅助 PersistentVolumeClaims
部署组件。
对于“备份一个和全部恢复”策略,您必须在资源定义中包含以下信息:
- 备份目标:指定要使用哪个
Deployment
或StatefulSet
来备份数据。系统会自动选择最适合用于备份的 Pod。在高可用性配置中,Google 建议从辅助PersistentVolumeClaim
进行备份。 - 钩子:定义在执行卷备份之前和之后执行的命令,例如应用静默和取消静默步骤。这些命令仅在所选备份 pod 上执行。
- 卷选择:便于更精细地选择在组件中备份和恢复哪些卷。
如果某个组件配置了多个 Deployment
或 StatefulSet
资源,则所有资源都必须具有相同的 PersistentVolume
结构,并且遵循以下规则:
- 所有
Deployment
或StatefulSet
资源使用的PersistentVolumeClaim
资源数量必须相同。 - 同一索引中
PersistentVolumeClaim
资源的用途必须相同。对于StatefulSet
资源,索引在volumeClaimTemplate
中定义。对于Deployment
资源,索引在Volume
资源中定义,且所有非永久性卷都会被跳过。
鉴于这些注意事项,您可以选择多个卷集进行备份,但只会从每个卷集中选择一个卷。
以下示例假设存在一个架构,它包含一个主要 StatefulSet
和一个辅助 StatefulSet
,其中显示了对辅助 StatefulSet
中的单个 pod 内的卷进行备份,然后对所有其他卷进行恢复:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
name: mariadb
namespace: mariadb
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: mariadb
components:
- name: mariadb
resourceKind: StatefulSet
resourceNames: ["mariadb-primary", "mariadb-secondary"]
strategy:
type: BackupOneRestoreAll
backupOneRestoreAll:
backupTargetName: mariadb-secondary
backupPreHooks:
- name: quiesce
container: mariadb
command: [...]
backupPostHooks:
- name: unquiesce
container: mariadb
command: [...]
转储和加载
此策略使用专用卷进行备份和恢复过程,并且需要将专用的 PersistentVolumeClaim
挂接到存储转储数据的组件。对于“转储和加载”策略,请在资源定义中包含以下信息:
- 转储目标:指定应使用哪个
Deployment
或StatefulSet
来转储数据。系统会自动选择最适合用于备份的 Pod。在高可用性配置中,建议从辅助PersistentVolumeClaim
进行备份。 - 加载目标:指定应使用哪个
Deployment
或StatefulSet
来加载数据。系统会自动选择最适合用于备份的 Pod。 加载目标不必与转储目标相同。 - 钩子:定义在执行卷备份之前和之后执行的命令。您必须为转储和加载策略定义特定钩子:
- 转储钩子:定义在备份之前将数据转储到专用卷的钩子。此钩子仅在所选转储 pod 上执行。
- 加载钩子:定义在应用启动后加载数据的钩子。此钩子仅在所选加载 pod 上执行。
- (可选)备份后钩子:定义在备份专用卷后执行的钩子,例如清理步骤。此钩子仅在所选转储 pod 上执行。
- 卷选择:指定用于存储转储数据的所有专用卷。您必须仅为每个转储和加载 Pod 选择一个卷。
如果应用由 Deployments
组成,则每个 Deployment
必须只有一个副本。
以下示例假设存在一个架构,它包含一个主要 StatefulSet
和一个辅助 StatefulSet
,且具有专用 PersistentVolumeClaims
同时用于主要和辅助 StatefulSets
。该示例显示了转储和加载策略:
kind: ProtectedApplication
apiVersion: gkebackup.gke.io/v1
metadata:
name: mariadb
namespace: mariadb
spec:
resourceSelection:
type: Selector
selector:
matchLabels:
app: mariadb
components:
- name: mariadb-dump
resourceKind: StatefulSet
resourceNames: ["mariadb-primary", "mariadb-secondary"]
backupStrategy:
type: DumpAndLoad
DumpAndLoad:
loadTarget: mariadb-primary
dumpTarget: mariadb-secondary
dumpHooks:
- name: db_dump
container: mariadb
commands:
- bash
- "-c"
- |
mysqldump -u root --all-databases > /backup/mysql_backup.dump
loadHooks:
- name: db_load
container: mariadb
commands:
- bash
- "-c"
- |
mysql -u root < /backup/mysql_backup.sql
volumeSelector:
matchLabels:
gkebackup.gke.io/backup: dedicated-volume