Kasten k10 实战系列 08 – Kasten K10 云原生应用的灾备与迁移

1. 前言

在多种 K8S 集群之间灾备和迁移云原生的应用程序，同时又不影响现有集群内的容器与应用的正常工作有时是极具挑战性的。无论是有状态的应用灾备，或是由于平台升级、资源重组引发的迁移，虽然看上去任务并不困难，但随着应用程序之间的依赖性增加，以及操作过程中减少停机时间的要求，该操作可能会变得难以处理。

文章目录

  1. 前言
  2. Kasten 支持的应用迁移场景
  3. 用 Kasten 复制 K8S 云原生应用
    • 3.1 复制应用之前的准备工作
    • 3.2 从源端 export 应用还原点到对象存储
    • 3.3 从源端记录原始应用的 Config data
    • 3.4 在目标 K8S Cluster 上创建导入策略 Import Policy
    • 3.5 运行导入策略，生成应用还原点
    • 3.6 基于还原点数据，还原应用到目标端的 K8S 集群
    • 3.7 应用还原完成
  4. 云原生应用复制的注意事项
  5. 总结
  6. 参考链接

Kasten 实战系列回顾

2. Kasten 支持的应用迁移场景

利用 Kasten 的应用灾备与迁移功能，我们可以在集群之间，轻松的复制应用，进而满足 Day 2 Operation 需要，支持的用例包括: 灾难恢复 (DR)、数据集重用，测试/开发以及隔离环境中的性能测试等。目前 Kasten K10 支持跨越多种资源进行灾备与迁移：

跨命名空间 整个应用程序堆栈可以跨越同一集群中的不同命名空间进行基于应用的复制，操作时只需要在 Kasten 恢复应用程序时，指定新的名空间即可。
跨K8S集群 跨 K8S 集群进行复制云原生应用，实现起来很简单，利用两个集群都可以访问的对象存储,即可完成应用的导出与导入操作。
跨越云账户 还支持跨不同云账户。例如： 不同的 AWS 账户或 GCP项目 例如, 在 Google Cloud 中不同的项目之间，来践行 K8S 应用的移动性。
跨可用区域 可以在同一云提供商的不同 Region 区域进行应用复制 ，例如，从美国东部复制应用，到美国西部。
跨云端平台 可以跨不同的云服务提供商与 K8S 分发版本。例如，从 AWS 到 Azure。

3. 用 Kasten 复制 K8S 云原生应用

在 K8S 中 复制应用的场景和方法很多，我们在本次的实例中，以跨 K8S 集群复制应用为例，与读者进行探讨与分析，场景示意图如下。利用对象存储库，在图中以 APP + Data Snapshot 为图标，备份数据后，我们就可以在同一集群不同名空间，或是不同的集群之间复制应用。

20210707142544

3.1 复制应用之前的准备工作

1. 外部存储配置

为了让两个集群可以共享数据，两个集群需要共同访问一个对象存储桶或 NFS 文件共享服务，利用 Kasten 将应用程序的数据还原点导出到对象存储桶或是 NFS，再利用目标端的 K10 进行导入即完成应用复制的操作。源集群需要对这个存储桶有写权限，目的集群至少需要有读权限。下图以腾讯云的 COS 为例，配置成为 K10 的 Location Profile。

20210703041124

2. 确认目标 K8S K10 安装完毕 

$ kubectl config view |grep cluster
    cluster: cls-hbjxi3pz

$ kubectl get po -n kasten-io
NAME                                  READY   STATUS    RESTARTS   AGE
aggregatedapis-svc-5d585974d9-85r7r   1/1     Running   0          7h40m
auth-svc-865fc676d6-f7z6c             1/1     Running   0          7h40m
catalog-svc-7cb86f96cf-pcz5c          2/2     Running   0          7h40m
config-svc-6c9f5dc695-h7gv4           1/1     Running   0          7h40m
crypto-svc-796c7f6c68-krrbz           1/1     Running   0          7h40m
dashboardbff-svc-97b8f8ccb-4llds      1/1     Running   0          7h40m
executor-svc-6cd8547867-dnjf7         2/2     Running   0          7h40m
executor-svc-6cd8547867-jgct2         2/2     Running   0          7h40m
executor-svc-6cd8547867-qgkxb         2/2     Running   0          7h40m
frontend-svc-6d5bc5b4f6-p8gn2         1/1     Running   0          7h40m
gateway-779686f446-xmxtw              1/1     Running   0          7h40m
jobs-svc-85bc8446bf-89f2v             1/1     Running   0          7h40m
kanister-svc-7668fd974b-zp9hk         1/1     Running   0          7h40m
logging-svc-69cd88456-tkbhd           1/1     Running   0          7h40m
metering-svc-5f958567b4-htfdp         1/1     Running   0          7h40m
prometheus-server-5f55997d87-zprf4    2/2     Running   0          7h40m
state-svc-85d456bf86-d7qsk            1/1     Running   0          7h40m

3.2 从源端 export 应用还原点到对象存储

从原来的 cluster export 应用, 我们以 minio 应用为例，在原端我们 Export 还原点到存储桶

20210706131210

选择将应用 export 到指定的对象存储，点击 Export

20210706131431

3.3 从源端记录原始应用的 Config data

Export 成功后，Kasten 会提示并会生成安全的凭据，复制此凭据以用于迁移

20210706131500

3.4 在目标 K8S Cluster 上创建导入策略 Import Policy

在目标端的 K8S 上我们将 Kasten背景设置为 Dark 以做区分。

首先，让我们来新建策略以导入数据 ，『Create New Policy』, 在对话框中，『Import Frequency』 选择 『Daily』 (导入的时间点可以非常密集，以减少 RPO 达到灾备的目地) 点击 『Import』， 将刚刚在剪贴板中的凭据粘贴到『Config Data for Import』文本框，在 『Profile import』 选择 『Create new Profile』，如下图。

20210704221003

依据刚刚我们使用的 COS 存储桶的信息，创建 『Location profile』， 点击 『Create Policy』 这个存储桶中就是我们刚刚导出的应用数据。

20210704221214

3.4 运行导入策略，生成应用还原点

如下图，可以看到我们刚刚建立的 Policy 已经配置好，让我们点击 『Run Once』 来运行导入作业

20210706133134

查看 『Dashboard』 中的 『Actions』 我们可以看到数据记录，也就是应用的数据还原点已经导入完成

20210706133446

3.5 基于还原点数据，还原应用到目标端的 K8S 集群

此时，我们可以在 『Applications』 的 『Removed』 中发现这个 minio 应用 ，点击『Resotre』

20210706133626

选择还原点，在这里我们新建一个命名空间以做区分， 如『minio-replica』 ，点击 『Create』，在『Restore Point』中，点击 『Restore』进行应用还原。

20210706133826

应用还原后， 在我在 K10 的应用发现器里会多出一个刚刚被还原的应用 "minio-replica"

20210706134108

3.6 应用还原完成

应用还原完成后，我们从 腾讯云 TKE 的控制台就可以查看到这个应用已经在运行了。

20210706134157

4. 云原生应用复制的注意事项

K10 在保护应用时会将命名空间中所以发现的资源都保护起来，但有些资源不会涉及，比如 CRDS、StorageClass、Cluster Role Bindings 等。K10 将默认这些资源已经由 K8S 管理员在目标集群部署的过程创建。

请注意，如果上述资源有问题将导致应用程序复制失败。另外，像有些网络配置，如 DNS，或是的映射端口，例如 NodePort 服务，如果目标集群没有配置好，也会发生复制后应用的不能正常工作的现象。

5. 总结

Day-2 Operation 翻译成为 “Day-2 运营”, 在云原生的世界里属于敏捷词汇，跟『精益运营』比较像。Day0、Day1、Day2 指的是软件生命周期的不同阶段。对于大多数企业来说，Day-2 Operation 是重复性的，但这是系统为组织产生结果的地方。利用 Kasten 我们可以达成跨集群、区域和云的应用复制，这使得 Day-2 Operation 中的一些操作变得更加轻松，但云原生的应用灾备与迁移也是一个非常专业的操作，需要以专业的软件与服务做为驱动来释放数据的价值，从而使企业在 Day-2 Operation 中不断寻求改进，收获更多效能。

6. 参考链接

Kasten Application migration
https://docs.kasten.io/4.0.5/usage/migration.html#mobility-configuration

Day 2 Operation
https://codilime.com/day-0-day-1-day-2-the-software-lifecycle-in-the-cloud-age/

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注