什么是 Azure Kubernetes 服务备份？

项目
12/20/2024

Azure Kubernetes 服务 (AKS) 备份是一个简单的云原生过程，可用于备份和还原 AKS 群集中运行的容器化应用程序和数据。可以为存储在基于 CSI 驱动程序的 Azure 磁盘存储中的永久性卷上的群集状态和应用程序数据配置计划备份。该解决方案通过在 Blob 容器本地将备份存储为磁盘快照，可以精细控制是选择特定命名空间还是整个群集进行备份或还原。可以将 AKS 备份用于端到端方案（包括操作恢复、克隆开发人员/测试环境）和群集升级方案。

AKS 备份与 Azure 中的备份中心集成，提供单一视图，帮助你大规模管理、监视、操作和分析备份。还可以在 Azure 门户中 AKS 实例的服务菜单的“设置”部分下找到你的备份。

AKS 备份是如何工作的？

使用 AKS 备份可以备份 AKS 群集中部署的 AKS 工作负荷和永久性卷。该解决方案要求在 AKS 群集内安装备份扩展。备份保管库与备份扩展进行通信，以完成与备份和还原相关的操作。必须使用备份扩展，而且必须将备份扩展安装在 AKS 群集内，才能为群集启用备份和还原。配置 AKS 备份时，可为存储备份的存储帐户和 Blob 容器添加值。

除备份扩展外，还会在 AKS 群集的受管理资源组中创建用户标识（名为扩展标识）。此扩展标识在其中的 Blob 容器存储了备份的存储帐户上分配有“存储帐户参与者”角色。

为了支持基于公共、专用和授权 IP 的群集，AKS 备份要求在 AKS 群集和备份保管库之间启用受信任的访问。受信任的访问允许备份保管库访问 AKS 群集，因为已为其分配用于备份操作的特定权限。有关 AKS 受信任访问的详细信息，请参阅使用受信任的访问使 Azure 资源能访问 AKS 群集。

注意

AKS 备份允许在操作层中存储备份。操作层是本地数据存储（备份作为快照存储在租户中）。

安装备份扩展并启用受信任的访问后，可以根据备份策略为群集配置计划备份。可以将备份还原到同一订阅和区域中的原始群集或备用群集。设置特定操作时，可以选择特定命名空间或整个群集作为备份和还原配置。

备份解决方案为群集中部署的 AKS 数据源和该群集永久性卷中存储的数据启用备份操作，然后将备份存储在 Blob 容器中。基于磁盘的永久性卷作为快照资源组中的磁盘快照进行备份。 Blob 中的快照和群集状态都组合在一起，形成存储在租户中称为操作层的恢复点。还可以将操作层中的备份（一天、一周、一个月或一年中的第一次成功备份）转换为 Blob，然后每天将它们移到保管库（租户外部）一次。

注意

目前，Azure 备份仅支持基于 CSI 驱动程序的 Azure 磁盘存储的永久性卷。在备份期间，该解决方案会跳过其他永久性卷类型，如 Azure 文件共享和 Blob。

配置备份

若要为 AKS 群集配置备份，首先创建备份保管库。保管库提供跨各种数据源配置的备份的合并视图。 AKS 备份支持操作层备份。
注意
- 备份保管库和要备份或还原的 AKS 群集必须位于同一区域和订阅中。
AKS 备份会自动触发计划的备份作业。该作业将群集资源复制到 Blob 容器，并根据备份频率创建基于磁盘的永久性卷的增量快照。备份会根据备份策略中定义的保留持续时间保留在操作层中，并在持续时间结束后删除。

注意

通过对每个备份实例使用不同的备份配置，可以使用 AKS 备份为单个 AKS 群集创建多个备份实例。但是，应在不同的备份保管库中，或在同一备份保管库中使用单独的备份策略创建 AKS 群集的每个备份实例。

管理备份

完成 AKS 群集的备份配置后，会在备份保管库中创建备份实例。可以在 AKS 门户中 AKS 实例的“备份”部分中查看群集的备份实例。可以通过其相应的备份实例对实例执行任何与备份相关的操作，例如启动还原、监视、停止保护等。

AKS 备份还直接与备份中心集成，以帮助你集中管理所有 AKS 群集的保护，以及其他支持备份的工作负荷。备份中心是用于满足所有备份要求的单一视图，例如监视作业以及备份和还原状态。备份中心有助于确保合规性和治理、分析备份使用情况，以及执行关键的数据备份和还原操作。

AKS 备份使用托管标识来访问其他 Azure 资源。若要配置 AKS 群集的备份并从早期备份还原，备份保管库的托管标识需要对在其中创建和管理快照的 AKS 群集和快照资源组具有一组权限。目前，AKS 群集需要对快照资源组具有一组权限。此外，备份扩展会创建一个用户标识，并分配一组权限来访问存储帐户，其中备份存储在 Blob 中。可以使用 Azure 基于角色的访问控制 (Azure RBAC) 来授予对托管标识的访问权限。托管标识是一种只能用于 Azure 资源的特殊类型的服务主体。详细了解托管标识。

从备份还原

可以从恢复点存在的任何时间点还原数据。恢复点是在备份实例处于受保护状态时创建的，可用于还原数据，直到备份策略保留数据为止。

Azure 备份使你可以选择还原所有备份项，或者使用精细控件通过选择命名空间和其他筛选器选项来从备份中选择特定项。此外，还可以在原始 AKS 集群（已备份的群集）或备用 AKS 群集上执行还原。可以将存储在操作层中的备份还原到同一订阅和不同订阅中的群集。

发生资源冲突（例如备份资源与目标 AKS 群集中的资源同名）时，适用于 AKS 的 Azure 备份当前支持通过以下两个选项执行还原操作。定义还原配置时，可以选择以下选项之一。

跳过：默认情况下此选项处于选中状态。例如，如果你已备份名为 pvc-azuredisk 的 PVC，并且要在具有同名 PVC 的目标群集中还原它，则备份扩展会跳过还原备份的永久性卷声明 (PVC) 操作。在这种情况下，建议从群集中删除资源，然后执行还原操作，使备份项仅在群集中可用，不会被跳过。
修补：此选项可用于在目标群集中的资源上修补备份资源中的可变变量。如果要更新目标群集中的副本数，可以选择修补作为操作。

注意

AKS 备份当前不会删除并重新创建目标群集中的资源（如果它们已存在）。如果尝试在原始位置还原永久性卷，请删除现有的永久性卷，然后执行还原操作。

对备份和还原使用自定义挂钩

可以使用自定义挂钩执行卷的应用程序一致性快照，这些卷用于部署为容器化工作负荷的数据库。

什么是自定义挂钩？

可以使用 AKS 备份在备份和还原操作过程中执行自定义挂钩。挂钩是配置为在备份操作期间或还原后在容器下的 Pod 中执行一个或多个命令的命令。可以将这些挂钩定义为自定义资源，并在要备份或还原的 AKS 群集中部署它们。在所需命名空间的 AKS 群集中部署自定义资源后，需要提供详细信息作为配置备份和还原流的输入。备份扩展会运行 YAML 文件中定义的挂钩。

注意

挂钩不会在容器的shell中执行。

AKS 中的备份有两种类型的挂钩：

备份挂钩
还原挂钩

备份挂钩

在备份挂钩中，可以将命令配置为在任何自定义操作处理之前（挂钩前）或在完成所有自定义操作并且备份自定义操作指定的任何其他项之后（挂钩后）运行。

例如，此处是要使用备份挂钩部署的自定义资源的 YAML 模板：

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: BackupHook
metadata:
  # BackupHook CR Name and Namespace
  name: bkphookname0
  namespace: default
spec:
  # BackupHook is a list of hooks to execute before and after backing up a resource.
  backupHook:
    # BackupHook Name. This is the name of the hook that will be executed during backup.
    # compulsory
  - name: hook1
    # Namespaces where this hook will be executed.
    includedNamespaces: 
    - hrweb
    excludedNamespaces:
    labelSelector:
    # PreHooks is a list of BackupResourceHooks to execute prior to backing up an item.
    preHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute.
          command:
            - /bin/uname
            - -a
          # OnError specifies how Velero should behave if it encounters an error executing this hook  
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          timeout: 10s
      - exec:
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          container: webcontainer
          onError: Continue
    # PostHooks is a list of BackupResourceHooks to execute after backing up an item.
    postHooks:
      - exec:
          container: webcontainer
          command:
            - /bin/uname
            - -a
          onError: Continue
          timeout: 10s

还原挂钩

在还原挂钩脚本中，会编写自定义命令或脚本，以在还原的 AKS Pod 容器中执行。

此处是要使用还原挂钩部署的自定义资源的 YAML 模板：

apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: RestoreHook
metadata:
  name: restorehookname0
  namespace: default
spec:
  # RestoreHook is a list of hooks to execute after restoring a resource.
  restoreHook:
    # Name is the name of this hook.
  - name: myhook-1  
    # Restored Namespaces where this hook will be executed.
    includedNamespaces: 
    excludedNamespaces:
    labelSelector:
    # PostHooks is a list of RestoreResourceHooks to execute during and after restoring a resource.
    postHooks:
      - exec:
          # Container is the container in the pod where the command should be executed.
          container: webcontainer
          # Command is the command and arguments to execute from within a container after a pod has been restored.
          command:
            - /bin/bash
            - -c
            - echo hello > hello.txt && echo goodbye > goodbye.txt
          # OnError specifies how Velero should behave if it encounters an error executing this hook
          # default value is Continue
          onError: Continue
          # Timeout is the amount of time to wait for the hook to complete before considering it failed.
          execTimeout: 30s
          # WaitTimeout defines the maximum amount of time Velero should wait for the container to be ready before attempting to run the command.
          waitTimeout: 5m

了解如何在 AKS 备份期间使用挂钩。

注意

在还原期间，备份扩展会等待容器启动，然后对它们执行在还原挂钩中定义的 exec 命令。
如果要还原到已备份的同一命名空间，则不会执行还原挂钩，因为它只会查找生成的新容器。无论选择跳过还是修补策略，都是如此。

在将备份还原到 AKS 群集时修改资源

可以使用资源修改功能，通过指定在 AKS 群集中 configmap 部署的 JSON 补丁，在还原期间修改备份的 Kubernetes 资源。

在还原期间创建和应用资源修饰符 configmap

要创建和应用资源修改，请执行以下步骤：

创建资源修饰符 configmap。

需要从定义资源修饰符的YAML文件在首选命名空间中创建 configmap。

创建命令的示例：
```
version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: "^mysql.*$"
    namespaces:
    - bar
    - foo
    labelSelector:
        matchLabels:
          foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"
  - operation: remove
    path: "/metadata/labels/test"
```
- 上述 configmap 将 JSON 补丁应用于命名空间栏中的所有永久性卷副本以及 foo（名称以 mysql 和 match label foo: bar 开头）。 JSON 补丁将storageClassName替换为premium，并从永久性卷副本中删除标签test。
- 在这里，命名空间是已备份资源的原始命名空间，而不是要还原资源的新命名空间。
- 可以为特定资源指定多个 JSON 补丁。根据 configmap 中指定的顺序应用补丁。后续补丁按顺序应用。如果为同一路径指定了多个补丁，则最后一个补丁会替代以前的补丁。
- 可以在configmap中指定多个resourceModifierRules。根据configmap中指定的顺序应用规则。
在还原配置中创建资源修饰符引用

执行还原操作时，请提供ConfigMap 名称 以及作为还原配置的一部分部署的命名空间。这些详细信息需要在资源修饰符规则下提供。

资源修饰符支持的操作

添加

可以使用“添加”操作向资源 json 添加新块。在下面的示例中，该操作使用部署向规范添加新的容器详细信息。

version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
    # Dealing with complex values by escaping the yaml
  - operation: add
    path: "/spec/template/spec/containers/0"
    value: "{\"name\": \"nginx\", \"image\": \"nginx:1.14.2\", \"ports\": [{\"containerPort\": 80}]}"

删除

可以使用“移除”操作从资源 json 中移除某个键。在下面的示例中，该操作移除了以 test 为键的标签。

version: v1
resourceModifierRules:
- conditions:
      groupResource: persistentvolumeclaims
      resourceNameRegex: "^mysql.*$"
      namespaces:
      - bar
      - foo
      labelSelector:
        matchLabels:
            foo: bar
  patches:
  - operation: remove
    path: "/metadata/labels/test"

替换

可以使用“替换”操作将提到的路径的值替换为备用值。在下面的示例中，该操作将永久性卷声明中的 storageClassName 替换为 premium。

version: v1
resourceModifierRules:
- conditions:
     groupResource: persistentvolumeclaims
     resourceNameRegex: "^mysql.*$"
     namespaces:
     - bar
     - foo
     labelSelector:
        matchLabels:
           foo: bar
  patches:
  - operation: replace
    path: "/spec/storageClassName"
    value: "premium"

复制

可以使用“复制”操作将定义的资源中的一个路径中的值复制到另一个路径。

version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^test-.*$"
    namespaces:
    - bar
    - foo
  patches:
  - operation: copy
    from: "/spec/template/spec/containers/0"
    path: "/spec/template/spec/containers/1"

Test

可以使用测试操作来检查资源中是否存在特定值。如果该值存在，则会应用补丁。如果该值不存在，则不会应用补丁。在下面的示例中，该操作检查了永久性卷声明的 StorageClassName 是否为 premium，如果为 true，则替换为 standard。

version: v1
resourceModifierRules:
- conditions:
    groupResource: persistentvolumeclaims
    resourceNameRegex: ".*"
    namespaces:
    - bar
    - foo
  patches:
  - operation: test
    path: "/spec/storageClassName"
    value: "premium"
  - operation: replace
    path: "/spec/storageClassName"
    value: "standard"

JSON 补丁

此configmap默认将 JSON 补丁应用于命名空间中的所有部署以及“nginxwith the name that starts withnginxdep”。 JSON 补丁将所有此类部署的副本计数更新为12。

version: v1
resourceModifierRules:
- conditions:
    groupResource: deployments.apps
    resourceNameRegex: "^nginxdep.*$"
    namespaces:
   - default
   - nginx
  patches:
  - operation: replace
    path: "/spec/replicas"
    value: "12"

JSON 合并补丁

此 ConfigMap 将 JSON 合并补丁应用于命名空间中默认情况下的所有部署，以及名称以 nginxdep 开头的 nginx。 JSON 合并补丁将使用值“nginx1”添加/更新标签“app”。

version: v1
resourceModifierRules:
  - conditions:
      groupResource: deployments.apps
      resourceNameRegex: "^nginxdep.*$"
      namespaces:
        - default
        - nginx
    mergePatches:
      - patchData: |
          {
            "metadata" : {
              "labels" : {
                "app" : "nginx1"
              }
            }
          }

战略性合并补丁

此 ConfigMap 将战略性合并补丁应用于命名空间中默认情况下名称以 nginx 开头的所有 Pod。战略合并补丁将容器 nginx 的映像更新为 mcr.microsoft.com/cbl-mariner/base/nginx:1.22

version: v1
resourceModifierRules:
- conditions:
    groupResource: pods
    resourceNameRegex: "^nginx.*$"
    namespaces:
    - default
  strategicPatches:
  - patchData: |
      {
        "spec": {
          "containers": [
            {
              "name": "nginx",
              "image": "mcr.microsoft.com/cbl-mariner/base/nginx:1.22"
            }
          ]
        }
      }

AKS 备份支持哪些备份存储层？

适用于 AKS 的 Azure 备份支持：

操作层：AKS 群集中安装的备份扩展首先通过 CSI 驱动程序创建卷快照来获取备份，并将群集状态存储在自己的租户中的 Blob 容器中。此层支持较低的 RPO，两个备份之间的最短持续时间为 4 小时。此外，对于基于 Azure 磁盘的卷，操作层支持更快的还原。

注意

可以通过定义保留规则，通过备份策略将备份数据存储到保管库标准数据存储中。

了解定价

产生的费用如下：

受保护的实例费用：AKS 的 Azure 备份每月按命名空间收取受保护的实例费用。在配置 AKS 群集的备份时，会创建受保护的实例。每个实例都有特定数量的命名空间，这些命名空间按照备份配置中的定义进行备份。有关 AKS 备份定价的详细信息，请参阅云备份定价，并选择 Azure Kubernetes 服务作为工作负荷
快照费用：AKS 的 Azure 备份获取存储在 Azure 订阅的资源组中的快照，从而保护基于磁盘的永久性卷。这些快照会产生快照存储费用。由于快照不会复制到备份保管库，因此备份存储成本不适用。有关快照定价的详细信息，请参阅托管磁盘定价。
备份存储费：AKS 的 Azure 备份还支持将备份存储在保管库层中。这可以通过在备份策略中定义保管库标准的保留规则来实现，每天有一个还原点有资格移动到保管库中。存储在保管库层中的还原点将根据备份保管库上存储的数据总量（以 GB 为单位）和启用的冗余类型收取单独的费用，称为备份存储费。

通过