作者 :
Adam Bergh, Solutions Architect, Cloud Native Technical Partnerships, Kasten by VeeamTerry Smith, Global Partner Solutions Director, SUSE
Gerson Guevara, IHV Solutions Architect, SUSE
1. 简介
1.1 用处
当初,企业在逐步向云原生转移(例如应用容器化工作负载和 SUSE Rancher 等 Kubernetes 治理平台)。企业的指标是进步灵活性、规模和弹性,来减速翻新并疾速适应动静条件。在这种永远在线的 IT 环境中,应用程序的可移植性和数据保护就非常要害。
Kasten K10 by Veeam® 数据管理平台为企业经营团队提供了一个易于应用、可扩大且平安的零碎,用于云原生应用程序的备份和复原、劫难复原和迁徙。
1.2 范畴
本指南概述了在 SUSE Rancher Kubernetes 环境中装置和设置 Kasten K10 by Veeam,以及执行应用程序的简略备份和复原的步骤。
1.3 受众
本文档实用于 IT 经营团队、备份管理员、DevOps 和 DevSecOps 团队,以及负责云原生环境的业务连续性、劫难复原、勒索软件和威逼管制以及应用程序迁徙的其余人员。
2. 技术概述
Kasten K10 by Veeam® 数据管理平台与 SUSE Rancher 深度集成,并提供了跨 Kubernetes 发行版和云平台的生态系统反对,这为企业经营团队提供了灵便的部署环境选项(本地、私有云和混合云)。K10 是由策略驱动并可扩大的。它提供了很多企业性能,例如全局一致性、数据库集成、主动应用程序发现、多云迁徙和弱小的 Web UI。
3. 先决条件
本指南波及以下内容:
- SUSE Rancher
本指南应用的是 Rancher 2.6。无关详细信息,请参阅 SUSE Rancher 装置指南。 - 由 SUSE Rancher 治理的 Kubernetes 集群。你能够应用任何 CNCF 认证的 Kubernetes 集群。请参阅 SUSE Rancher 反对矩阵。
- 备份指标的存储
内部备份存储指标(例如 NFS 文件服务器或云对象存储)。本文档将应用与 S3 兼容的内部对象存储桶。 - 用于演示备份和复原性能的用户应用程序
例如,你能够应用 Helm Chart 轻松装置 WordPress。
K10 能够装置在各种不同的环境中。为了确保装置顺利,你能够应用 primer 工具来执行几个施行前查看(pre-flight check)。该工具在集群的 pod 中运行,且会执行以下操作:
- 验证 Kubernetes 设置是否满足 K10 要求。
- 注销可用的 StorageClass。
- 如果存在 CSI provisioner,它还会对集群的 CSI 性能和相干对象进行根本验证。无关详细信息,请参阅文档中的 CSI pre-flight。
运行以下命令部署 primer 工具:
curl https://docs.kasten.io/tools/k10_primer.sh | bash
留神:
这将创立并清理 ServiceAccount 和 ClusterRoleBinding,以便对 Kubernetes 集群执行健全性查看。
4. 装置 Kasten K10
能够在 SUSE Rancher 的 Apps & Marketplace 页面中轻松部署 Kasten K10。
4.1 为 Kasten K10 应用程序创立一个新的命名空间
- 在 SUSE Rancher 的 UI 中,导航到 Clusters > Project/Namespaces:
- 为 Kasten K10 创立一个“kasten-io”命名空间:
4.2 装置 Kasten K10
- 在 SUSE Rancher UI 中导航到 Apps & Marketplace > Charts 并搜寻“Kasten”:
- 抉择 K10 Chart 并单击 Install:
- 在 Namespace 下拉框中抉择“kasten-io”命名空间。你也能够抉择 Customize Helm options before install 来自定义部署(非必选)。无关具体阐明,请参阅 Helm 选项残缺列表。
- 设置 Chart 值后,单击 Next,而后单击 Install。
4.3 验证装置
要验证 Kasten K10 是否已正确装置,请在“kasten-io”命名空间中运行以下命令并查看所有 K10 pod 的状态:
kubectl get pods --namespace kasten-io --watch
Pod 须要几分钟后能力全副呈现并显示“Running”状态:
kubectl get pods --namespace kasten-ioNAMESPACE NAME READY STATUS RESTARTS AGEkasten-io aggregatedapis-svc-b45d98bb5-w54pr 1/1 Running 0 1m26skasten-io auth-svc-8549fc9c59-9c9fb 1/1 Running 0 1m26skasten-io catalog-svc-f64666fdf-5t5tv 2/2 Running 0 1m26s...
留神:
如果 pod 卡在其余状态,请参阅反对文档以进一步进行调试。
5. 拜访 K10 仪表板
Kasten K10 仪表板默认不对外裸露。要建设连贯,请运行以下 kubectl 命令:
kubectl --namespace kasten-io port-forward service/gateway 8080:8000
留神:
如果你装置的 Kasten K10 的版本名称不是 k10(通过装置命令中的--name
选项指定),请将上述 URL 中最初面的k10
替换为你的版本名称。批改后的 URL 的格局为http://127.0.0.1:8080//#/
。留神:
如果你应用 GKE 并且想要在没有本地kubectl
权限的状况下拜访仪表板,请参阅间接在 Google Cloud Console 中拜访 K10 仪表板。
如果要间接拜访 K10 仪表板,你须要正确配置身份验证来爱护拜访。无关详细信息,请参阅 Kubernetes 身份验证。
在本指南中,咱们概述了配置根本身份验证和令牌身份验证的步骤,你能够抉择其中一种身份验证办法。
5.1 根本身份验证
根本身份验证能让你应用用户名和明码来爱护对 K10 仪表板的拜访。
首先,应用在线工具或零碎上的 htpasswd
命令(大多数零碎上都反对)生成 htpasswd 凭证来启用根本身份验证。
生成后,你须要在 helm install
或 helm upgrade
命令中应用以下标记来提供获取的字符串:
--set auth.basicAuth.enabled=true \
--set auth.basicAuth.htpasswd='example:$apr1$qrAVXu.v$Q8YVc50vtiS8KPmiyrkld0'
或者,你能够应用由 htpasswd
创立的文件中蕴含的 secret。secret 必须位于 K10 命名空间中,密钥名为“auth”,值为应用 htpasswd
生成的明码:
--set auth.basicAuth.enabled=true \
--set auth.basicAuth.secretName=my-basic-auth-secret
5.2 令牌身份验证
令牌身份验证能让你应用任何能够被 Kubernetes 服务器验证的令牌。无关令牌身份验证的更多信息,请参阅:
- 获取令牌
- 身份验证策略
-
在
helm install
或后续的helm upgrade
命令中应用以下标记,从而启用令牌身份验证:--set auth.tokenAuth.enabled=true
-
而后,提供要在拜访仪表板时应用的持有者令牌:
最常见的令牌类型是 ServiceAccount 持有者令牌。
- 你能够应用
kubectl
从具备适当权限的 ServiceAccount 中提取此类令牌。 -
获取 SA secret:
sa_secret=$(kubectl get serviceaccount my-kasten-sa -o jsonpath="{.secrets[0].name}" --namespace kasten-io)
-
提取令牌:
kubectl get secret $sa_secret --namespace kasten-io -ojsonpath="{.data.token}{'\n'}" | base64 --decode
-
你也能够创立一个新的 ServiceAccount 来提取令牌:
kubectl create serviceaccount my-kasten-sa --namespace kasten-io
在这种状况下,你须要为该账号创立角色绑定或集群角色绑定,从而确保该账号具备适当的 K10 权限。如需具体理解必要的 K10 权限,请参阅受权。
5.3 Kasten K10 仪表板概览
K10 仪表板分为几个局部,如下所述。
提醒:
首次拜访 K10 仪表板,或通过 Settings 页面上的仪表板选项进行拜访时,你会看到 K10 仪表板的导览。
K10 仪表板的上方会显示以后映射到命名空间的应用程序、零碎中可能存在的策略以及集群备份数据占用状况的概览:
在过滤具备状态服务(定义为蕴含长久卷)的应用程序后,此界面将应用程序进一步分类为:
- Unmanaged:没有爱护此对象的策略。
- Non-compliant:具备利用于此对象的策略,但策略相干的操作失败(起因可能是底层存储迟缓、配置问题等)或尚未调用操作。
- Compliant:这些对象具备策略并且恪守策略 SLA。
提醒:
你能够通过单击 Compliant、Non-Compliant 或 Unmanaged 按钮来过滤视图。
K10 将命名空间等同于应用程序,因而更加易于应用并且与 Kubernetes 的最佳实际保持一致,更容易应用 RBAC,并能镜像最常见的应用程序部署模式。然而,你能够将策略定义为操作多个命名空间(后文会介绍),或者仅对单个命名空间中的应用程序的子集进行操作。
假如你曾经装置了应用程序。单击仪表板上的 Applications 后你将看到以下视图:
一个应用程序由多个 Kubernetes 资源和工作负载组成,其中包含 Deployment 和 Statefulset:
K10 策略能自动化你的数据管理工作流程。策略定义了要执行的操作(例如制作快照)、操作的执行频率或打算,以及如何抉择要治理的资源。
单击主仪表板中的 Policies 后,你会发现装置时没有创立默认策略,然而你能够从此页面或上文提及的 Applications 页面中创立策略:
6. 创立 location 配置文件
K10 能够在集群内调用爱护操作(例如快照)而无需额定的凭证。如果 K10 运行在支流的私有云中并且仅进行单集群操作,这可能就足够了。然而,对于大多数生产状况来说,这还不足够。在这种状况下,执行真正的备份、启用跨集群和跨云应用程序迁徙以及启用劫难复原是必要的。
要启用逾越集群生命周期的操作,K10 须要配置为能拜访内部对象存储或内部 NFS 文件存储,而这是通过 location 配置文件实现的:
你能够单击仪表板右上角的 Settings 图标,或通过 CRD-based Profiles API 来创立配置文件。Location 配置文件用于应用快照创立备份、跨集群或跨云平台挪动应用程序及其数据,并将备份导出 / 导入集群。
要创立 location 配置文件,单击配置文件页面上的 New Profile:
在对象存储地位进行导出或导入时,你须要选择对象存储提供程序、存储桶的区域(如果在公共云中应用)以及存储桶名称。如果该名称的存储桶不存在,则会创立该存储桶。
如果应用了不受反对的云厂商的 S3 兼容对象存储系统,则须要指定 S3 端点 URL,并且可能须要禁用 SSL 验证。仅倡议在测试场景下禁用 SSL 验证。
留神:
抉择云厂商(例如 AWS 或 Microsoft Azure)后,云厂商对应的选项(例如 IAM Roles)则会显示。
单击 Validate and Save 后将创立配置文件,而后会呈现相似以下的配置文件:
7. 创立策略
要应用 K10 来爱护应用程序,你通常须要创立策略。你须要理解以下的三个概念:
- 快照和备份 :你可能须要应用这两种数据捕捉形式中的一种或两种,具体取决于你的环境和要求。
- 打算 :你能够指定应用程序捕捉频率和快照 / 备份保留工夫。
- 抉择 :确定受策略爱护的应用程序。你还能够通过过滤资源来限度每个应用程序捕捉的内容。
本节演示如何在 K10 策略中应用这些概念来爱护应用程序。
K10 将利用程序定义为命名空间中的 Kubernetes 资源的汇合,这些资源与以下内容关联:
- 工作负载(例如 ConfigMap 和 Secret)
- 应用程序应用的非命名空间资源(例如 StorageClass)
- Kubernetes 工作负载(包含 Deployment、StatefulSet、独立的 pod 等)
- Helm v3 提供的 Deployment 和版本信息
- 所有长久存储资源(例如 PersistentVolumeClaim 和 PersistentVolume)
你能够在策略页面从零开始创立策略,然而,为利用程序定义策略最简略办法是单击主仪表板中的 Applications。这样,你能查看 Kubernetes 集群中的所有应用程序:
要爱护 Unmanaged 的应用程序,只需单击 Create a Policy 以关上 New Policy 对话框即可:
7.1 快照和备份
操作执行是所有策略的核心。你能够先抉择具备可选备份(称为 export)的快照操作。详细信息,请参阅 Kasten 文档中的快照和备份。
7.1.1 快照
快照是 K10 中持久数据捕捉的根底。它们通常用于应用程序应用的磁盘卷 (PVC/PV) 的上下文中,但也能够利用于应用程序级别的数据捕捉(例如应用 Kanister)。
留神:
一些私有云厂商(包含 AWS、Azure 和 Google Cloud)实际上将快照存储在对象存储中,而且它们的保留与主卷的生命周期是离开的。然而,并非所有私有云都是这样的,因而独立备份更加平安。请查阅你的云厂商的文档以获取更多信息。
在大多数存储系统中,快照是十分高效的,而且对次要工作负载的性能影响非常低,不须要停机,反对疾速复原,并反对增量数据捕捉。
快照的存储通常会受到限制,例如每个卷 / 存储阵列的最大快照数量绝对较低。最重要的是,快照并不都是长久的。如果产生灾难性的存储系统故障,你的快照和次要数据都会被毁坏。此外,在一些存储系统中,快照的生命周期与源卷是相关联的。因而,如果卷被删除,那么所有关联的快照都可能被主动回收。
提醒:
强烈建议你备份应用程序的快照以确保持久性。
7.1.2 备份
备份能克服应用程序和卷快照的限度,其原理是通过将快照转换为独立于基础设施的格局,在存储到内部对象存储或 NFS 卷之前对其进行反复数据删除、压缩和加密。
要将快照转换为备份,请在策略创立期间启用 Enable Backups via Snapshot Exports:
7.2 调度
K10 调度有四个组成部分:
- 操作频率:执行主快照操作的频率
- 导出频率:将快照导出到备份的频率
- 保留打算:如何轮换和保留快照和备份
- 工夫:执行次要快照操作的工夫
7.2.1 操作频率
快照的频率能够设置为 Hourly、Daily、Weekly、Monthly、Yearly 或 On Demand。默认状况下,Hourly 快照会在整点执行,而 Weekly、Monthly 和 Yearly 快照会在 UTC 零点执行。
你还能够指定执行打算操作的工夫以及单个频率内执行多个操作的子频率。在爱护 Kubernetes 对象或小型数据集时,按小时执行操作会十分有用。无关详细信息,请参阅 Kasten 文档中的高级调度选项。
正告:
请不要加紧底层存储基础设施或存储 API 速率的限度。此外,子频率与保留工夫(如下所述)也是相互作用的。例如,如果你以 15 分钟的距离保留 24 小时的快照,那么实际上只会保留 6 小时的快照。
7.2.2 导出频率
启用 Enable Backups via Snapshot Exports 后,快照将作为备份导出。默认状况下会导出每个快照,但你能够通过抉择 Daily、Weekly、Monthly 或 Yearly 的导出频率将其限度为一个子集:
7.2.3 保留打算
K10 可能应用 GFS 保留计划来节省成本和确保合规性。如果你应用这个备份轮换计划,Hourly 快照和备份会每小时轮换一次,而后其中一个会逐步轮换成 Daily 频率;同理,Daily 快照和备份会每天轮换一次,而后其中一个会逐步轮换成 Weekly 频率,以此类推。你能够设置须要保留的 Hourly、Daily、Weekly、Monthly 和 Yearly 正本数,K10 将依照设置进行清理。
留神:
不反对为 On Demand 策略设置保留打算。
默认状况下,备份保留打算与快照保留打算是雷同的。你也能够设置不同的打算。你能够创立保留无限快照数量的策略,从而在意外中断时进行疾速复原,同时存储大量备份。如果卷仅反对无限数量的快照,但须要大量备份保留数来实现合规性,这种独自的保留打算就十分有用。
通过将 k10.kasten.io/doNotRetire: "true"
标签增加到为策略运行而创立的 RunAction,你能够从保留计数中保留和省略策略创立的快照和备份。
留神:
策略的保留打算不适用于手动运行策略生成的快照和备份。你须要清理手动运行策略期间创立的任何工件。
7.2.4 定时
默认状况下,设置为 Hourly 执行的操作会在整点执行,而其余频率的操作会在 UTC 午夜执行。
你能够勾销暗藏 Advanced Options,从而抉择在频率距离内执行操作的次数。例如,如果操作频率是 Daily,你能够指定开始操作的具体小时和分钟:
你还能够设置哪些快照和备份须要保留更长时间:
提醒:
你能够抉择以本地工夫或 UTC 工夫来显示和输出工夫,但所有工夫都将转换为 UTC,并且不会更改为夏令时。
7.3 抉择
在 K10 中,你能够通过名称或标签来指定要绑定到策略的应用程序。
7.3.1 应用程序名称
在 K10 中,将策略利用于应用程序的最间接的办法是应用名称(源自命名空间名称)。你甚至能够为同一策略抉择多个应用程序名称。
如果你须要跨类似应用程序的策略,请应用星号 (*
) 通配符。例如,如果你指定了 mysql-*
,K10 将匹配所有名称以 mysql-
结尾的应用程序。
留神:
对于须要跨所有应用程序的策略,请独自应用星号通配符。
7.3.2 应用程序标签
你还能够应用标签将策略绑定到多个应用程序。例如,你能够爱护所有应用 MongoDB 或应用“gold”标签进行正文的应用程序。命名空间、deployment 和 statefulset 的标签会被匹配。如果抉择了多个标签,将执行并集(逻辑 OR),也就是让所有应用程序至多匹配一个标签。
标签可用于创立前瞻性策略,因为此类策略将主动利用于后续带有匹配标签的任何应用程序。例如,如果你应用了“heritage: Tiller”(Helm v2)或“heritage: Helm”(Helm v3)标签,因为标签会利用于 Helm 包管理器创立的任何 Kubernetes 工作负载,因而选择器会将策略利用于任何 Helm 新部署的应用程序。
7.3.3 其余资源
K10 还能够爱护集群级别的资源,而不针对具体应用程序。要应用此选项,请抉择 None:
无关爱护集群级别资源的更多信息,请参阅集群级别资源。
7.3.4 自定义
你能够通过以下形式进一步自定义 K10 应用程序爱护策略:
- 命名空间排除
- 例外
- 资源过滤
8. 应用策略
创立策略并导航回主仪表板后,你将看到选定的应用程序从 Unmanaged 切换到 Non-Compliant。也就是说,策略涵盖了对象,但尚未执行任何操作。当快照和备份已运行且应用程序进入受爱护状态时,应用程序将切换到 Compliant 状态。你还能够向下滚动页面,从而查看流动、每个快照所用的工夫以及生成的工件。
留神:
你能够单击进行中或已实现的 Job 来获取更具体的信息。
8.1 手动运行策略
你能够通过单击策略上的 run once 按钮来手动运行策略。此操作创立的工件都不合乎主动停用的条件,因而须要手动清理。
8.2 复原现有应用程序
你能够通过 Applications 页面来复原应用程序。要复原应用程序,单击 Applications 卡片中的 restore 图标:
留神:
尽管 UI 中应用了“export”术语,然而复原备份不须要应用导入策略。只有在将应用程序复原到其余集群时才须要导入策略。
而后,能够抉择一个还原点。UI 中将它们辨别为主动生成(应用备份策略)和手动生成。
还原点可能包含具备雷同数据的快照(集群本地)和备份(已导出到集群外)。当快照和备份都存在时,UI 能让你抉择要用于复原应用程序的实例:
抉择还原点后,一个侧面板将会关上,其中蕴含还原点的详细信息,你能够在开始复原应用程序之前进行预览:
单击 Restore 时,零碎会主动将整个应用程序堆栈从新创立到选定的命名空间中,其中不仅包含与原始应用程序相干的数据,还包含版本化的容器镜像。
留神:
复原的 PersistentVolume 可能没有原始 PersistentVolume 中的正文。
复原实现后,你能够返回应用程序并验证它是否已复原到获取还原点时的状态。
8.3 复原已删除的应用程序
复原已删除的应用程序的流程也差不多,但默认状况下,已删除的应用程序不会显示在 Applications 页面上。因而,你须要过滤并抉择 Removed:
过滤器失效后,你会看到 K10 爱护过但不再存在的应用程序。当初,你能够依照失常的复原流程来复原它们。
9 总结
SUSE Rancher 让企业能通过对立的平安、策略和用户治理办法来简化多集群 Kubernetes 操作。而 Kasten K10 by Veeam 能使 Kubernetes 原生应用程序的备份和复原、劫难复原和迁徙变得简略。SUSE 和 Veeam 独特为企业提供升高危险和放慢云原生实现所需的工具。
在本指南中,你理解了如何将 Kasten K10 无缝部署到 Rancher Kubernetes 环境中、如何创立策略驱动的备份,以及如何复原应用程序。
如需理解更多信息,请参阅:
- 应用 Kasten K10 by Veeam 和 SUSE Rancher 来爱护云原生工作负载 – 演示视频
- Kasten K10 by Veeam 和 SUSE Rancher:企业 K8s 数据保护 – 博客文章
- 应用 SUSE Rancher、Fleet 和 Kasten K10 部署多集群 Day 2 操作 – 博客文章
- 通过 2 个简略步骤开始应用 SUSE Rancher
- 收费下载 Kasten K10 并在最多 5 个节点上应用它
- Kasten K10 文档
- Rancher 文档