Kasten k10 多云适配系列 04 – 利用 Kasten K10 保护 Redhat Openshift 云原生应用

1. 概览

1.1 Kasten k10 on Redhat OCP

1.1.1 Kasten k10 介绍

Kasten K10 是专为 Kubernetes 所构建的数据管理平台,为企业运营团队提供了易于使用、可扩展、安全的解决方案,用于 Kubernetes 应用程序的备份还原,灾难恢复和迁移。

K10 的核心概念是以应用为中心的方法进行数据管理,它与多种数据库、Kubernetes 发行版本与各大云平台进行了深度的集成,这为企业提供了自由选择基础架构手段,同时带来了极大的操作的简便性。

K10 通过基于策略驱动和可扩展数据管理方法论,为企业提供了原生的 Kubernetes API,用户通过其强大而简捷的 Web 界面就可以轻松操作。在数据保护的领域,K10 实现了自动化地感知并发现应用,与数据库原生工具的集成,对数据一致性场景进行了全面的覆盖,使K8S应用可以在多云环境下轻松地按需迁移,备份和容灾。

img1

1.1.2 Kasten K10 产品特点

原生的架构适配
自动发现集群上运行的所有应用程序组件与相关配置,保证应用一致性与完整性

出色的恢复能力
还原应用程序及其相关组件到所需位置,可自由定义还原的粒度与时间点。

一切为运营服务
为运营团队提供所需的工作流,满足合规性和监视要求,操作自服务与Restful API。

完美的安全管控
支持以RBAC的方式进行权限管理,无论在传输还是存储过程中将数据端到端加密。

灵活的可移动性
在多个云原生云平台之间,自由的进行,应用程序备份,容灾与迁移。

1.1.3 Redhat OCP 介绍

红帽® OpenShift® 是一个企业就绪型 Kubernetes 容器平台,可以实现全堆栈自动化运维,以管理混合云、多云和边缘部署。红帽 OpenShift 已进行过专门优化,可以有效提高开发人员的生产力并推动创新。 凭借红帽 OpenShift 的全堆栈自动化运维、跨所有环境的一致体验以及面向开发人员的自助服务置备,团队可以紧密携手合作,更有效地从构思想法过渡到生产阶段。红帽 OpenShift 既可作为领先公共云中的全托管式云服务提供,也可作为自我管理软件提供给需要更高定制化程度的企业。

1.2 Kasten K10 在 红帽® OpenShift®上的用例

鉴于 K10 广泛的生态系统支持,您可以灵活地选择部署环境,无论公共云、私有云、混合云、还是私有化部署的企业云,主要支持三个主要用例:备份和恢复、灾难恢复和应用程序迁移。

  • 数据保护
    快照是 K10 中持久数据捕获的基础。通常与 K8S 应用程序所使用的存储类与磁盘卷有关,在云环境中 Kasten 推荐用户使用云原生支持存储与 CSI 存储接口的方式。Kasten K10 也可以应用于应用程序级数据捕获,如,通过利用Kanister的应用程序蓝图。考虑到快照的局限性,通常建议设置应用程序的备份,即数据的长期保留。K10 会采用重复数据删除技术降低数据长期保留的成本,同时支持在不同的云提供商之间,利用数据备份实现跨云备份。通过策略或手动操作保护了应用程序之后,就可以就地恢复应用或将应用复制到不同的名空间。

  • 无缝迁移:
    跨 K8S 集群迁移应用程序的能力是 K10 的特性之一,无缝迁移支持多种用例,包括灾难恢复(DR)、真实数据集的测试与开发,以及在隔离环境中进行性能测试。 K10 平台的设计之初就是为了支持多种不同类型的应用程序迁移,可以跨名称空间、跨集群、跨存储平台、跨云服务提供商。

  • 整体灾备:
    任何备份软件必须考虑的是如何进行自我保护,Kasten 也不例外, K10 是以一个应用的状态存在于 K8S 集群中的。虽然 K8S 集群本身具有平台的冗余性,但必须要警惕的是,灾难总是在不经意之间发生。例如 K10 被意外删除,或是 K10 使用的底层存储发生故障,甚至K10 所在的集群被意外破坏等等。Kasten K10 的灾难恢复,旨在保护 K10 免受底层基础架构故障的影响,以达成在各种灾难情况下恢复 K10 灾备平台的能力。

2.Kasten K10 工作原理

Kasten K10 工作原理图如下图所示,当用户执行备份或还原命令时,调用自定义资源 API 创建查找备份对象。

20210627180420

Step1:发现应用组件 : 通过 Orchestrator API, K10 应用可以在几分钟内部署到在您的 Kubernetes 集群上,并与 IAM 身份和访问管理集成,K10 的自动应用程序发现功能。

Step2:发现应用配置 : K10 API Controller 控制器 watch 到生成的备份对象时,执行备份计划,此时 K10 与 将与存储基础架构 API 相集成发现应用的配置,如 Namespaces, deployments , configmaps , secrets , serivceaccounts , serivecs ,storageclass 等等

Step3:发现应用数据 : 通过自动扫描 Kubernetes 环境中需保护的应用和相关组件,发现数据的所在位置。通过使用自动化策略高效执行数据管理操作,如通过CSI接口实现的快照操作,可以保证数据的高速备份、还原、以及应用的可移动性。同理,针对有状态的应用,还可以通过开源应用程序框架 Kanister,提供可扩展的、无代理的、以数据应用程序为中心的蓝图部署与保护方式,实现数据备份和恢复的一致性。

3. Kasten K10 部署规划

3.1 技术资源准备与要求

Kasten K10 部署在 Redhat OCP 需要以下先决条件 :

  • Redhat OCP Redhat Openshift plaftform 4.7 基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务。
  • Opensift 管理账号 用于管理OCP 中所有的组件,包括 K10的应用管理。
  • CSI 存储组件 无论是通过 OCS 存储组件 ,还是通过其它的CSI 组件,只要支持 OCP 集群通过控制台快捷选择存储类型,并创建对应块存储云硬盘类型的 PV 和 PVC。本文的OCP就建立在AWS平台之上的,所以提供的是 GP2-CSI 组件功。
  • 对象存储, 用于存放备份的数据集,用于存储部署 Kasten K10 的自动化检测脚本,本文中我们使用的是 AWS S3 与 腾讯 COS
  • 技术人员要求 部署人员除了对 Redhat OCP 有一定了解以外,还应该具备 其它 K8S发行版本的知识。

3.2 K8S 集群资源需求

对于 Kasten K10 在 TKE 容器平台环境的部署,Kasten K10 将需要以下资源,鉴于 K10 所保护的应用数量不同,对应的数值也做相应的调整。

3.2.1 资源需求

K10 的资源需求总是与 Kubernetes 集群中的应用程序数量和正在执行的数据管理任务类型有关(例如,快照与备份)。一些资源需求是静态的,我们称之为基本资源需求,而其他资源的占用仅在完成某些数据管理工作时才被需要,因此我们称之为动态资源需求。K10 的自动扩展特性确保了在不执行任何工作时,动态需求资源的消耗缩减为零。虽然以下资源需求与限制的建议适用于大多数 K8S 集群,但需注意的是,最终需求将取决于您的集群和应用程序规模、数据总量、文件大小、分布和数据变化率。比较科学的方式是通过 Prometheus 或 Kubernetes Vertical Pod Autoscaling (VPA) 来检查您的资源需求。

3.2.2 需求类型

我们将需求分为三种类型,即基本工作需求,备份工作需求和灾难恢复需求,并做以下陈述:

  • 基本工作需求:这些是 K10 的内部调度和清理服务所需的资源,主要由监控和目录规模需求驱动。这些基本要求的资源占用通常是静态的,通常不会随着受保护的 Kubernetes 资源数量或受保护应用程序数量的增长而显着增长。

  • 备份工作需求:当数据从卷快照传输到对象存储或 NFS 文件存储时,需要调用备份工作所需的资源。虽然备份需求取决于您的数据量、变化率和文件系统布局,但这些需求并非没有限制,很容易适应相对廋供给的资源范围。当然在提供额外资源时,K10 还可以加快备份操作的完成。为了在保护大量工作负载时防止无限并行,K10 限制了同时备份作业的数量(默认为 9 个任务并行)。备份资源占用是动态的,在不执行备份时会缩减为零。

  • 灾难恢复需求:这些需求是在执行 K10 安装的灾难恢复所需的资源,主要用于压缩、重复数据删除、加密以及将 K10 目录传输到对象存储。提供额外资源还可以加快 DR 操作。DR 资源占用是动态的,并且在不执行 DR 时会缩减为零。

3.3.3 需求配置指引

下表列出了保护 100 个云原生应用程序或命名空间的 K10 安装的资源要求。需要注意的是,DR 作业也包含在最大并行度限制中,因此您只能 N 同时拥有备份作业 或 N-1 备份作业 + 1 个 DR 作业同时进行。

Type Requested CPU (Cores) Limit CPU (Cores) Requested Memory (GB) Limit Memory (GB)
Base 1 2 1 4
Dynamic (per parallel job) 1 1 0.4 0.4
DR 1 1 0.3 0.3
Total 3 4 1.8 4.8

4. Kasten k10 on OCP 部署

4.1 通过 Operator Hub 进行安装

点击 Operator , Operator Hub 查找 Kasten Operator
20210730103634

创建项目
20210730103915

创建 K10 release
20210730103950

使用 Yaml 视图进行参数调整, 搜索 route 两次,直到看见 Route 配置, route 与 tls 都设置为 true

route:
    annotations: {}
    enabled: true
    host: ''
    labels: {}
    path: ''
    tls:
      enabled: true
      insecureEdgeTerminationPolicy: Redirect
      termination: edge

20210730104228

使用 Token 方式认证, 搜索 tokenAuth 设置为 true

    tokenAuth:
      enabled: true

20210730104818

获取 token,点击复制登录命令,点击显示Token
20210730102027

复制Your API token is 的下一行

20210730101953

4.2 通过 helm 进行安装

通过 Helm 安装 Kasten K10
路由与 Token 认证方式通过,如下参数进行设定。

--set route.enabled=true
--set auth.tokenAuth.enabled=true

$ helm install k10 kasten/k10 --namespace=kasten-io --set scc.create=true --set route.enabled=true --set auth.tokenAuth.enabled=true
NAME: k10
LAST DEPLOYED: Mon Jul 26 02:25:50 2021
NAMESPACE: kasten-io
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing Kasten’s K10 Data Management Platform!
Documentation can be found at https://docs.kasten.io/.
How to access the K10 Dashboard:

The K10 dashboard is not exposed externally. To establish a connection to it use the following `kubectl` command:
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
The Kasten dashboard will be available at: `http://127.0.0.1:8080/k10/#/`

获取 Token

oc login -u opentlc-mgr
Authentication required for https://api.cluster-cb92.cb92.sandbox352.opentlc.com:6443 (openshift)
Username: opentlc-mgr
Password:
Login successful.

You have access to 64 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".
[xiaoyliu-redhat.com@bastion linux-amd64]$ oc whoami --show-token
sha256~XPu8Iz5X3ZS7KeK9y6MYKcpK2GyQuQKJG4k6yfZDbvo
[xiaoyliu-redhat.com@bastion linux-amd64]$ 

4.3 登录 K10

找到网络,路由。找到位置打开
20210730105642

访问 kasten 登录页面, 使用上文获取的Token 进行登录
20210730105740

5. Redhat OCP 应用的备份与恢复

5.1 部署测试应用: Django + Postgresql

开发者目录 , 新建项目
20210730110733

选择添加,从目录
20210730111726

实例化模板
20210730111534

回到 administrator 界面,在 Protject 里查看,项目部署情况
20210730112917

查看工作负载 pod 的状态,可以看到 django 与 postgresql 已经启动
20210730113124

找到Project的路由
20210730113814

进入 Django的 web 页面,刷新两次,注意下面的 page view 2
20210730113841

进入 Postgresql 终端, 输入命令查看,结果是相同的
20210730113700

5.2 云原生应用的发现

进入 k10 界面 应用数量的变化已经被捕捉,应用数量从 61 上升到 62

20210730114130

5.3 建立备份策略

查找应用test4ocp, 点击 create policy
20210730114209

一切默认,点击 create policy
20210730114345

5.4 运行备份策略

点击 Run Once , Run Ploicy
20210730114514
查看 Dashboard ,确认 程序备份完成
20210730114854

5.5 制造数据变化

进入 Django的 web 页面,刷新两次,注意下面的 page view 4
20210730115041
进入 Pod 终端,查看 pageview = 4
20210730115149

5.6 还原应用与数据

回到 K10 界面,点击 Restore
20210730115322

选择时间点
20210730115341

一切默认,选择 Restore
20210730115426

回 dashboard, 查看 Restore的情况
20210730115554

5.7 查看应用还原结果

回到 OCP 界面,查看,所有 pod running
20210730115647

回 k10 界面查看已经完成,Restore
20210730115914

回到 OCP 界面,查看,所有 pageview =2
20210730115948

6. 迁移 TKE 应用到 OCP

6.1 准备工作

,在 Redhat CCP 与 腾讯 TKE 中都安装好 K10 并设置好存储库,TKE 中我们将 K10 设置为 Dark 模式以以便区分
20210730154753

6.2 在 OCP 中 链接腾讯 TKE 的 COS 存储库

20210730154827

6.3 Export TKE 中应用的备份集

在源端将应用的备份集 Export 出来
20210730155603

点击 Export,生成Export 任务
20210730155759

点击 Copy to Clipboard! 将 config data 拷贝到剪贴板
20210730160011

查看 Export 导出的情况
20210730161046

6.4 导入 TKE 中的应用到 OCP

在 OCP 的 Kasten 建立 Import Policy
20210730162148

点击 Run Once
20210730163225

观察这个应用 Import 任务已经完成
20210730163707

从应用 Removed 的里面选取需要还原的应用
20210730163841

6.5 应用还原

点击 Restore
20210730163956

观察应用已经还原完成
20210806210641

7. 总结

K10 数据管理平台为企业运营团队提供了一个易于使用、可扩展和安全的系统,用于 Redhat OCP 的备份/恢复、容灾、应用迁移。K10 使用以应用程序为中心的方法,可以适配多种云原生应用、Kubernetes 发行版、Red Hat OpenShift 版本 和多种云的深度集成,为企业运维团队提供了选择基础设施的自由度。

发表回复

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