有关 Azure Kubernetes 服务的 Azure 备份的常见问题

需要在 AKS 群集中安装 AKS 备份扩展才能启用备份，因为它将群集与 Azure 的本机备份服务集成，从而为备份提供集中管理、自动化和安全性。 该扩展与 Kubernetes API 交互，以确保正确备份和还原 Kubernetes 工作负荷（永久性卷、配置和元数据）。

AKS 备份扩展安装需要存储帐户和 Blob 容器作为输入。 存储帐户必须与 AKS 群集位于同一区域，Blob 容器必须位于同一存储帐户中。 Blob 容器用于存储备份数据和关联的元数据。 存储帐户和 Blob 容器的特定要求包括：

• 存储帐户的类型必须为 Standard general-purpose v2 类型。
• 在安装 AKS 备份扩展之前，必须在存储帐户中创建 Blob 容器。
• Blob 容器最好在安装之前为空，或者至少不应该有非备份相关数据，因为扩展将在容器中创建自己的文件夹结构来存储备份数据和元数据。
• 如果 AKS 群集位于专用网络中，则必须从 AKS 群集访问存储帐户。 为此，可以使用存储帐户的专用终结点，或者配置必要的网络规则以允许从 AKS 群集访问存储帐户来实现此目的。

与 AKS 备份扩展关联的 Pod 部署在 AKS 群集的 NodePools 上。 若要成功部署这些 Pod 并阻止它们干扰应用程序资源，请确保以下各项：

• AKS 群集必须具有包含作系统（包括 Azure Linux 和 Ubuntu）的 Linux 代理节点池。
• 代理节点池必须具有基于非 ARM64 体系结构的 VMSS SKU。
• 代理节点池必须具有与之关联的污点 CriticalAddOnOnly 。 通过门户创建 AKS 群集时，会自动将此污点添加到节点池。 它可确保仅在节点池上计划关键加载项 Pod（如 AKS 备份扩展 Pod）。 这可以防止干扰应用程序工作负荷，并确保备份作与群集中的其他工作负荷隔离。 如果不存在污点，可以在安装 AKS 备份扩展之前手动添加它。

AKS 的 Azure 备份依赖于在 AKS 集群中部署的 Pod，这些 Pod 是命名空间 dataprotection-microsoft 下备份扩展的一部分。 若要执行备份和还原作，这些 Pod 具有特定的 CPU 和内存要求。

• 内存：请求 - 256Mi，限制 - 1280Mi
• CPU：请求 - 500m，限制 - 1000m

安装 AKS 备份扩展时，备份相关的资源将部署在命名空间下的群集中 dataprotection-microsoft 。 以下三个部署在此命名空间中创建：

dataprotection-microsoft-controller dataprotection-microsoft-geneva-service dataprotection-microsoft-kubernetes-agent

此外，由于 AKS 备份扩展基于 AKS 平台的 Arc 扩展构建，因此 kube-system 在命名空间中创建另外两个部署：

extension-agent extension-operator

这些部署不仅支持备份扩展，还支持其他扩展（例如 Flux 和 Azure 机器学习）。

作为备份扩展安装的一部分，还会在群集的节点资源组中创建用户标识。 AKS 备份扩展使用此标识来访问备份作所需的 Azure 资源。 用户标识通过存储帐户分配 Storage Blob Data Contributor 角色，以启用扩展的访问权限。 每当从 AKS 群集卸载扩展时，标识也会被删除。

Velero 是 Kubernetes 的第三方备份解决方案，可与 AKS 备份扩展冲突。 建议仅将 AKS 备份扩展用于群集中的备份作，但不能同时使用这两个扩展。 AKS 备份扩展还会在群集中部署 Velero CRD。 如果独立 Velero 随备份扩展一起安装在 AKS 群集中，并且每个安装使用的版本在任何时间点都不同，可能会导致由于协定不匹配而导致失败。 此外，由你创建的自定义 Velero 配置（例如 VolumeSnapshotClass for Velero CSI 基于 CSI 的快照）可能会干扰 AKS 备份快照设置。 包含 velero.io 应用于群集中各种资源的 Velero 注释也可以以不支持的方式影响 AKS 备份的行为。

AKS 的 Azure 备份为 AKS 群集提供作层备份。 因此，在计划备份作和按需备份作期间创建的基于 Azure 磁盘的永久性卷的快照存储在订阅中的资源组中。 由于增量快照存储在你的订阅中，因此 Azure 备份可执行快速还原。 此资源组称为快照资源组。 必须在备份配置期间提供快照资源组，并且分配快照资源组后，无法对其进行修改。

从保管库层还原备份时，需要暂存资源组和存储帐户。 在此类还原期间，保管库中的备份数据首先在暂存位置冻结，然后在群集中安装的扩展将此数据还原到目标 AKS 群集中。 临时资源组用于临时重新创建备份的磁盘。 临时存储帐户用于存储存储在保管库层中的备份数据中的 Kubernetes 资源。 在暂存位置创建后，必须手动清理备份项。

AKS 的 Azure 备份依赖于基于 CSI 驱动程序的快照进行备份和还原作。 由于此依赖项，目前仅支持通过 CSI 驱动程序附加的基于 Azure 磁盘的永久性卷。 目前不支持其他 Azure 存储选项，例如 Azure 文件共享、Azure Blob、Azure 容器存储、Azure NetApp 文件、Azure 托管 Lustre 和第三方存储解决方案。 在 Azure 磁盘中，支持以下 SKU：

• 高端SSD
• 标准 SSD
• 标准 HDD

但是，不支持高级 SSD v2 和超级磁盘。 此外，当涉及到具有网络访问设置的 Azure 磁盘时：

• 作层支持任何大小的公共和专用访问磁盘。
• 保管库层仅支持公共访问磁盘，最大大小为 1TB。

如果 AKS 群集包含不受支持的类型的永久性卷，则会在备份作期间跳过这些卷。 总体备份仍会成功，但备份中不包含不支持的卷。

AKS 的 Azure 备份支持两种类型的备份存储层：

• 作层：此层用于短期保留备份。 它将永久性卷的增量快照作为备份存储在订阅中。 此层非常适合快速还原和作恢复方案。
• 保管库层：此层用于长期保留备份。 它存储存储在作层中的备份数据，将其转换为块 Blob，然后将其存储在存储帐户（术语为保管库）中，由Microsoft管理的受保护 Azure 租户中。 此层非常适合符合性和法规要求，因为它允许在低成本存储层中保留长时间的备份。

创建备份策略时，可以定义备份存储层。 默认规则是使用作层进行备份。 可以添加更多规则来备份保管库层中的数据以及作层。

备份策略中定义了备份频率。

• 在作层中，备份的频率可以每隔 4 小时进行一次。
• 在保管库层中，每天只能存储一个备份。

可以配置规则，将当天、周、月或年的第一次成功备份移到保管库层。 可以根据恢复点目标（RPO）和保留要求自定义这些设置。

根据备份策略计划的时间，计划备份会在该时间起的 2 小时内执行。 因此，从 AKS 备份的计划备份时间起，备份开始时间的最大延迟为 2 小时。

在作层中创建备份后，如果备份按照备份策略中定义的规则创建备份，则它有资格立即进行保管库。 之后，将在接下来的 4 小时内启动到保管库层的传输。

包含“第一周/月/年”保留期的备份策略选择每周、月或年的第一个成功备份，并根据指定的保留期保留该备份。 “first”的定义是系统定义的，例如：

• 周： 周日被视为一周的开始
• 月： 月份的第一天
• 年： 1 月 1 日

此行为不基于创建或启用策略的日期。

AKS 群集可以同时托管多个应用程序，每个应用程序的范围都限定为不同的命名空间。 Azure 备份允许根据不同的应用程序配置多次备份 AKS 群集，无论是在不同的备份保管库中，还是在同一备份保管库中使用不同的备份策略。

AKS 的 Azure 备份支持异地冗余备份，允许在发生区域性中断时还原不同 Azure 区域中的数据。 通过将备份数据复制到 Azure 配对区域，使备份数据变得冗余。

若要使备份在地理上冗余，第一步是在已启用 Geo-Redundancy 的备份保管库中配置备份，并启用跨区域还原。

接下来，使用包含保管库层保留规则的备份策略配置备份实例。

使用这些设置，将备份移动到保管库层后，它会自动复制到配对的次要 Azure 区域。

发生区域性服务中断时，可以使用 Azure 门户或 Azure CLI 从次要区域还原备份。

在保管库层中移动备份后，最多可能需要 12 小时才能在次要区域中复制备份。 因此，如果次要区域中存在备份数据可用性，则还原点在 AKS 的 Azure 备份支持的次要区域中可用的最大 RPO 数为小时。 这意味着，在发生区域性服务中断时，可以从次要区域还原备份数据，最大数据丢失时间为 24 小时。

AKS 的 Azure 备份使用最低特权方法来发现、保护和还原订阅中的 AKS 群集。 为此，Azure 备份使用备份保管库的托管标识来访问其他 Azure 资源。 可以使用 Azure 基于角色的访问控制（Azure RBAC）向托管标识、系统分配或用户授予权限。 托管标识是一种只能用于 Azure 资源的特殊类型的服务主体。 默认情况下，备份保管库无权访问要备份的 AKS 群集、创建定期快照、在保留期后删除快照以及还原备份。 通过向备份保管库的托管标识显式授予角色分配，你可以控制对订阅中资源的管理权限。

以下是在 AKS 群集上分配的 参与者角色中 要备份或还原到的作：

1. Microsoft.Compute/快照/读取
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/snapshots/delete

下面是在存储 Blob 数据参与者 角色中使用的作，这些作分配给已备份或还原到 AKS 群集的扩展标识（通过存储帐户）：

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. Microsoft.Storage/storageAccounts/blobServices/containers/write（Microsoft 存储/存储账户/Blob 服务/容器/写入）
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read（读取权限）
4. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
5. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete（删除操作路径）
6. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action

以下是在 AKS 群集上为备份保管库分配的 读取者 角色中使用的作：

1. */读

以下是在备份保管库上通过快照资源组分配的 读取者 角色中使用的作：

1. Microsoft.Authorization/*/read
2. Microsoft.Resources/subscriptions/resourceGroups/read

以下是在备份保管库上通过快照资源组分配的 磁盘快照参与者 角色中使用的作，以防备份存储在保管库层中：

1. Microsoft.Compute/snapshots/delete
2. Microsoft.Compute/snapshots/write
3. Microsoft.Compute/快照/读取
4. Microsoft.Compute/snapshots/beginGetAccess/action
5. Microsoft.Compute/snapshots/endGetAccess/action
6. Microsoft.Compute/disks/beginGetAccess/action

下面是在备份保管库上通过快照资源组分配的 托管磁盘角色的数据作员 中使用的作，以防备份存储在保管库层中：

1. Microsoft.Compute/disks/download/action
2. Microsoft.Compute/snapshots/download/action

以下是在存储帐户上分配的 存储 Blob 数据读取者 角色中使用的作，以防备份存储在保管库层中：

1. Microsoft.Storage/storageAccounts/blobServices/containers/read
2. 微软存储/存储帐户/Blob服务/生成用户委派密钥/操作
3. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read（读取权限）

以下是在临时资源组上为备份保管库分配的 参与者 角色中使用的作，以防从保管库层还原备份：

1. Microsoft.Resources/subscriptions/resourceGroups/read
2. Microsoft.Authorization/*/read
3. Microsoft.Compute/snapshots/*
4. Microsoft.Compute/disks/*

以下是在临时存储帐户上为备份保管库分配的存储帐户 参与者 角色中使用的作，以防从保管库层还原备份：

1. Microsoft.Authorization/*/read
2. Microsoft.Storage/storageAccounts/*

下面是在备份保管库上通过过渡存储帐户分配的 存储 Blob 数据所有者 角色中使用的作，以防从保管库层还原备份：

1. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*

AKS 的 Azure 备份目前不支持以完全相同毫秒的速度拍摄所有 PV 的快照。 虽然快照作是并行启动的，但由于基础结构和 API 计时，单个 PV 快照之间可能会有轻微的延迟。 为了帮助实现多个 PV 的一致性，Azure 备份支持使用挂钩进行应用程序一致性备份。 挂钩允许用户在快照之前暂停应用程序写入，并在之后恢复它们。 此方法可提高一致性并模拟崩溃一致性，尽管它可能不等同于真正的同时快照或协调的数据库级一致性。

选择“跳过”意味着还原过程不会尝试重新创建任何 Kubernetes 资源。 如果目标群集中已存在匹配的资源，则会 as-is重复使用它们。 如果它们不存在，Azure 备份将尝试动态重新创建它们。 对于 PV，请确保目标环境中存在兼容的 StorageClass 定义和权限。

当还原的群集引用仍指向原始源资源组的永久性卷（PV）时，通常会发生这种情况。 AKS 将群集资源分为两个资源组：一个用于控制平面，另一个用于基础结构（如磁盘）。 如果在还原期间 PVC-to-PV 映射未正确更新，则还原的工作负载可能会尝试附加源 PV，从而导致错误。 确保还原过程正确地将 PVC 重新映射到目标群集资源组中的新或现有 PV。

• 用于 AKS 的 Azure 备份支持矩阵