什么是 Azure Kubernetes 服务备份?

Azure Kubernetes 服务(AKS) 备份是一个简单的云原生过程,可用于备份和还原在 AKS 群集中运行的容器化应用程序和数据。 可以为存储在基于容器存储接口 (CSI) 驱动程序的 Azure 磁盘存储中的 Kubernetes 永久性卷上的群集状态和应用程序数据配置计划备份。

该解决方案提供精细的控制。 可以通过将备份本地存储在 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(租户外部)存储在保管库层中。 保管库层中存储的备份还可用于还原次要区域(Azure 配对区域)中的数据。

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

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

注意

目前,Azure 备份仅支持基于 CSI 驱动程序的 Azure 磁盘存储的永久性卷。 在备份期间,该解决方案会跳过其他永久性卷类型,如 Azure 文件存储共享和 Blob。 此外,如果您为保管库层设置了特定的保留规则,那么只有在持久卷小于或等于 1 TB 时,备份才有资格被移动到保管库。

配置备份

若要为 AKS 群集配置备份,首先创建备份保管库。 保管库提供为各种数据源配置的备份的合并视图。 AKS 备份支持操作层和保管库级别的备份。

备份保管库存储冗余设置(本地冗余存储或异地冗余存储)仅适用于存储在保管库层中的备份。 如果要使用备份进行灾难恢复,请将存储冗余设置为启用了跨区域还原GRS

注意

备份保管库和要备份或还原的 AKS 群集必须位于同一区域和订阅中。

AKS 备份会自动触发计划的备份作业。 该作业将群集资源复制到 Blob 存储容器中,并根据备份频率为磁盘型持久卷创建增量快照。 备份会根据备份策略中定义的保留持续时间保留在操作层和保险库层中。 当持续时间结束时,将删除备份。

通过对每个备份实例使用不同的备份配置,可以使用 AKS 备份为单个 AKS 群集创建多个备份实例。 但是,建议使用以下两种方式之一创建 AKS 群集的每个备份实例:

  • 在不同的备份保管库中
  • 在同一备份保管库中使用单独的备份策略

管理备份

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

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

AKS 备份使用托管标识来访问其他 Azure 资源。 若要配置 AKS 群集的备份以及从以前的备份还原,备份保管库的托管标识需要对 AKS 群集拥有一组权限。 它还需要对创建和管理快照的快照资源组拥有一组权限。 目前,AKS 群集需要对快照资源组具有一组权限。

此外,备份扩展会创建一个用户标识,并分配一组权限来访问存储帐户,其中备份存储在 Blob 中。 可以使用 Azure 基于角色的访问控制向托管标识授予权限。 托管标识是一种只能用于 Azure 资源的特殊服务主体类型。 详细了解托管标识

从备份还原

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

使用 Azure 备份,可以选择还原备份的所有项,或使用精细控件通过命名空间和其他筛选器选项从备份中选择特定项。 此外,还可以在原始 AKS 群集(备份群集)或备用 AKS 群集上执行还原。 可以将存储在操作层和归档层中的备份还原到相同或不同订阅中的群集。 仅存储于保管库层中的备份可用于在不同的区域(Azure 配对区域)中还原到群集。

若要还原存储在保管库层中的备份,必须提供备份数据冻结的暂存位置。 此暂存位置包括资源组及同一区域中的存储帐户,以及用于还原的目标群集的订阅。 还原期间,在水合的过程中创建特定资源(Blob 容器、磁盘和磁盘快照)。 还原操作完成后,它们会被清除。

AKS 的 Azure 备份目前支持以下两个选项,用于发生资源冲突的情况。 当备份资源与目标 AKS 群集中的资源同名时,会发生资源冲突。 定义还原配置时,可以选择以下选项之一。

  • 跳过:默认情况下此选项处于选中状态。 例如,如果你备份一个名为 pvc-azuredisk 的永久性卷声明 (PVC),并在具有同名 PVC 的目标群集中对其进行还原,则备份扩展会跳过对已备份 PVC 的还原。 在这种情况下,建议从群集中删除资源。 然后,执行还原操作,这样备份项仅在群集中可用,并且不会被跳过。

  • 修补:此选项可用于在目标群集中的资源上修补备份资源中的可变变量。 如果要更新目标群集中的副本数,可以选择修补作为操作。

注意

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

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

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

什么是自定义挂钩?

可以使用 AKS 备份在备份和还原操作过程中执行自定义挂钩。 挂钩被配置为在备份操作期间或还原后,运行要在容器下的 Pod 中执行的一个或多个命令。

可以将这些挂钩定义为自定义资源,并在要备份或还原的 AKS 群集中部署它们。 在所需命名空间的 AKS 群集中部署自定义资源后,需要提供详细信息作为配置备份和还原流的输入。 备份扩展会运行 YAML 文件中定义的挂钩。

注意

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

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

  • 备份挂钩
  • 还原挂钩

备份挂钩

使用备份挂钩时,可以将命令配置为在任何自定义操作处理之前运行挂钩(PreHooks)。 你也可以在所有自定义操作完成并且自定义操作指定的任何其他项都已备份后运行挂钩 (PostHooks)。

例如,此处是要使用备份挂钩部署的自定义资源的 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 群集时修改资源

可以通过将 JSON 修补程序指定为在 AKS 群集中部署的 configmap,使用资源修改功能在还原期间修改已备份的 Kubernetes 资源

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

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

  1. 创建资源修饰符 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 修补程序应用于名称以 mysqlmatch label foo: bar 开头的 namespaces bar 和 foo 中的所有永久性卷副本。 JSON 修补程序将 storageClassName 替换为 premium,并从永久性卷副本中删除标签 test
    • 此处是 namespace 备份资源的原始命名空间,而不是要还原资源的新命名空间。
    • 可以为特定资源指定多个 JSON 修补程序。 根据 configmap 中指定的顺序应用修补程序。 按顺序应用下一个修补程序。 如果为同一路径指定了多个修补程序,则最后一个修补程序会替代以前的修补程序。
    • 可以在configmap中指定多个resourceModifierRules。 这些规则根据中指定的 configmap顺序应用。
  2. 在还原配置中创建资源修饰符引用

    执行还原操作时,请提供 ConfigMap name 及其作为还原配置的一部分在其中部署的 namespace。 这些详细信息需要在资源修饰符规则下提供。

    显示提供资源详细信息的位置的屏幕截图。

资源修饰符支持的操作

  • 添加

    可以使用 “添加” 来向资源 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"
    
  • 替换

    可以使用“替换”操作将提到的路径的值替换为备用值。 在下面的示例中,该操作将 PVC 中的 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"
    
  • 测试

    可以使用“测试”操作来检查资源中是否存在特定值。 如果该值存在,则会应用修补程序。 如果该值不存在,则不会应用修补程序。 在以下示例中,该操作检查 PVC 是否具有 premium 作为 StorageClassName,如果是,则将其替换为 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 修补程序应用于命名空间中的所有部署(默认),以及名称以 nginxdep 开头的 nginx。 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 备份支持保管库标准数据存储。 根据备份策略中设置的保留规则,(一天、一周、一个月或一年)第一次成功的备份将移动到租户外部的 Blob 容器。 此数据存储不仅允许更长的保留期,还提供勒索软件保护。 还可以通过在备份保管库中启用 异地冗余跨区域还原 ,将保管库中存储的备份移动到另一个区域(Azure 配对区域)进行恢复。

    注意

    可以通过定义保留规则,通过备份策略将备份数据存储到保管库标准数据存储中。 每天只有一个计划的恢复点移动到保管库层。 但是,可以根据所选规则将任意数量的按需备份移动到保管库。

了解定价

产生的费用如下:

  • 受保护的实例费用:AKS 的 Azure 备份每月按命名空间收取受保护的实例费用。 在配置 AKS 群集的备份时,会创建受保护的实例。 每个实例都有特定数量的命名空间,这些命名空间按照备份配置中的定义进行备份。 有关 AKS 备份定价的详细信息,请参阅 Azure 备份的定价 ,并选择 Azure Kubernetes 服务作为工作负荷。

  • 快照费:适用于 AKS 的 Azure 备份通过创建存储在 Azure 订阅的资源组中的快照来保护基于磁盘的永久性卷。 这些快照会产生快照存储费用。 由于快照不会复制到备份保管库,因此备份存储成本不适用。 有关快照定价的详细信息,请参阅 托管磁盘定价

  • 备份存储费用:AKS 的 Azure 备份还支持将备份存储在保管库层中。 可以通过在备份策略中定义保管库标准的保留规则,将备份存储在保管库层中,每天有一个还原点有资格移动到保管库中。 存储在保管库层级中的还原点会根据存储的总数据量(以吉字节为单位)和在备份保管库上启用的冗余类型,单独收取费用(称为备份存储费用)。