其他
基于 IOMesh 与 Kasten K10 的云原生存储数据管理方案实操
Editor's Note
本文详细演示并验证了 IOMesh 云原生存储解决方案用 Kasten K10 对应用进行备份及恢复。作者使用 K10 对存储 CSI 进行调用生成快照，实现最快速的 RPO 与 RTO 的备份与恢复，同时验证将快照数据导出到对象存储，实现异地容灾与数据长期保留。
The following article is from 云端数据管理 Author Mars Zhang
内容提要
发展云原生生态圏是 Veeam 的又一重要战略，以 Kasten by Veeam 为圆心，这个战略又分为三个重要的组成部分，公有云厂商、K8S 分发版本和云原生存储厂商。云原生的领域中，与云原生生态所适配的存储又成为大家所关注的热点。Veeam China 在中国的云原生生态战略布局中也积极的与国内多家云原生存储厂商合作。IOMesh 是 SmartX 为 Kubernetes 云原生应用设计的存储产品，其具备容器化部署、自动运维、声明式接口等云原生特性，可加速数据库等有状态应用的容器化进程，同时，IOMesh 是国内首款通过红帽 OpenShift 认证的存储产品。SmartX 是国内率先通过 K8S CSI 认证的 SDS 厂商与国内加入 CNCF Landscape 全景图的厂商之一，目前其为 CNCF 白银会员。今天我们要讲解的是如何在与 IOMesh CSI 容器存储解决方案结合保护云原生应用。
关键章节
背景与验证目标 Kasten 与 SmartX IOMesh 测试环境搭建 安装 IOMesh CSI 配置测试环境存储与快照类 用 Kasten kubestr 对云原生存储进行评测 安装 Kasten K10 到 K8S 集群 结合 IOMesh CSI 容器存储解决方案保护云原生应用测试 将数据 Export 到 MINIO 的对象存储实现数据的长期保留 总结 欢迎您关注云端数据管理 参考链接
1. 背景与验证目标
1.1. 背景
发展云原生生态圏是 Veeam 的又一重要战略，以 Kasten by Veeam 为圆心，这个战略又分为三个重要的组成部分，公有云厂商、K8S 分发版本和云原生存储厂商。云原生的领域中，与云原生生态所适配的存储又成为大家所关注的热点。Veeam China 在中国的云原生生态战略布局中也积极的与国内多家云原生存储厂商合作。IOMesh 是 SmartX 为 Kubernetes 云原生应用设计的存储产品，其具备容器化部署、自动运维、声明式接口等云原生特性，可加速数据库等有状态应用的容器化进程，同时，IOMesh 是国内首款通过红帽 OpenShift 认证的存储产品。SmartX 是国内率先通过 K8S CSI 认证的 SDS 厂商与国内加入 CNCF Landscape 全景图的厂商之一，目前其为 CNCF 白银会员。今天我们要讲解的是如何在与IOMesh CSI 容器存储解决方案结合保护云原生应用。
1.2. 验证目标
在本次验证场景中，我们将结合 IOMesh CSI 容器存储解决方案保护云原生应用的方式。
安装 IOMesh 与配置容器存储解决方案 利用 Kubestr 对云原生存储进行评测 利用 K10 对存储 CSI API 进行调用生成快照，达成最快速的 RPO 与 RTO的备份与恢复
达成效果：
建立带有 IOMesh 云原生存储系统 利用 IOMesh CSI 快照，在本地 Kubenetes 环境，云原生应用的快速备份与恢复（利用CSI快照） 利用 Kasten K10 直接将数据容灾到远端，或利用 MINIO 对象存储实现数据长期保留，达成 3-2-1-1-0 的数据保护黄金法则。
2. Kasten 与 SmartX IOMesh
Kasten K10
Kasten 是 Veeam 在 Kubernetes 平台的数据管理解决方案，通过部署 Kasten K10 企业可以安全地备份和还原、执行灾难恢复以及迁移云原生的应用。Kubernetes 集群资源和持久卷等存储资源。解决用户备份、灾难恢复、迁移过程中的数据管理问题，提高云原生环境数据管理的便捷性，帮助用户降低灾备成本，提高生产执行效率。
SmartX IOMesh
IOMesh 以 SmartX 自主研发且“生产就绪”的分布式存储系统 ZBS 为核心，为运行在 Kubernetes 环境中的业务关键型应用，如 MySQL、Cassandra、MongoDB 等提供生产级别的高性能和可靠的持久化存储能力，有力支撑有状态应用的容器化改造。IOMesh 现已加入 CNCF 云原生全景图 。
Kubernetes 云原生
IOMesh 完全基于 Kubernetes 自身能力构建，运维团队可以使用标准的 Kubernetes 工具对运行在容器上的应用程序和 IOMesh 存储系统进行统一管理，可极大地降低管理复杂度和运维成本。
性能卓越
存储性能对于数据库等 IO 密集型应用的稳定运行至关重要。在标准的 Kubernetes 存储性能测试中，IOMesh 在获得高 IOPS 的同时保持了极低且稳定的延迟，可为目标应用的稳定运行提供强有力的保障。
高可靠性
IOMesh 运行在用户空间内，不引入额外的内核模块，从而有效确保了隔离性，不会影响同节点其它应用的正常运行。
高扩展性
IOMesh 集群最少只需 3 个节点，用户可根据业务需要增加节点或磁盘，对存储集群进行横向或纵向在线扩容，且性能随节点线性增长，真正实现弹性扩展。
高性价比
IOMesh 支持多种存储介质的灵活组合部署，包括 NVMe SSD、SATA SSD、HDD 等，并通过冷热分层算法将活跃和非活跃数据分别放在不同的存储介质中，充分发挥不同存储介质的容量、性能和成本优势，实现成本效益最大化。
3. 测试环境搭建
3.1. 检查 Nodes 及其资源
测试环境如下，由 3 个 Master Nodes 与 3 个 Worker Node 组成
$ kubectl get nodes -owide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
iomesh-master-0 Ready master 336d v1.19.3 192.168.30.200 <none> CentOS Linux 8 4.18.0-240.1.1.el8_3.x86_64 containerd://1.3.9
iomesh-master-1 Ready master 336d v1.19.3 192.168.30.201 <none> CentOS Linux 8 4.18.0-240.1.1.el8_3.x86_64 containerd://1.3.9
iomesh-master-2 Ready master 336d v1.19.3 192.168.30.202 <none> CentOS Linux 8 4.18.0-240.1.1.el8_3.x86_64 containerd://1.3.9
iomesh-worker-0 Ready <none> 3d4h v1.19.3 192.168.17.85 <none> CentOS Linux 8 4.18.0-305.25.1.el8_4.x86_64 containerd://1.2.13
iomesh-worker-1 Ready <none> 3d3h v1.19.3 192.168.17.86 <none> CentOS Linux 8 4.18.0-305.25.1.el8_4.x86_64 containerd://1.2.13
iomesh-worker-2 Ready <none> 3d2h v1.19.3 192.168.17.87 <none> CentOS Linux 8 4.18.0-305.25.1.el8_4.x86_64 containerd://1.2.13
3.2. 查看节点上的存储情况
$ kubectl describe nodes | grep -E 'Hostname|cpu|memory|ephemeral-storage'
Hostname: iomesh-master-0
cpu: 8
ephemeral-storage: 130553924Ki
memory: 16184716Ki
Hostname: iomesh-master-1
cpu: 4
ephemeral-storage: 130553924Ki
memory: 7927196Ki
Hostname: iomesh-master-2
cpu: 4
ephemeral-storage: 130553924Ki
memory: 7927196Ki
Hostname: iomesh-worker-0
cpu: 32
ephemeral-storage: 976279804Ki
memory: 263752752Ki
Hostname: iomesh-worker-1
cpu: 32
ephemeral-storage: 976279804Ki
memory: 263752752Ki
Hostname: iomesh-worker-2
cpu: 32
ephemeral-storage: 976279804Ki
memory: 263752748Ki
4. 安装 IOMesh CSI
4.1. 检查 OS 版本
$ cat /etc/os-release
NAME="CentOS Linux"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
4.2. 执行安装
安装时按手册的指引，按之前查询的 Linux 版本进行安装，详见如下手册。
# Every node running IOMesh must have an IP address belongs to IOMESH_DATA_CIDR
$ export IOMESH_DATA_CIDR=10.234.1.0/24; curl -sSL https://iomesh.run/install_iomesh_el8.sh | sh -
Install IOMesh
https://docs.iomesh.com/deploy/install-iomesh
4.3. 检查 IOMesh 是否部署成功
$ kubectl get --namespace iomesh-system pods
NAME READY STATUS RESTARTS AGE
csi-driver-controller-plugin-b5dd7fd85-5w4fg 6/6 Running 0 5h16m
csi-driver-controller-plugin-b5dd7fd85-j94fk 6/6 Running 1 5h16m
csi-driver-controller-plugin-b5dd7fd85-khl89 6/6 Running 0 5h16m
csi-driver-node-plugin-b722c 3/3 Running 0 5h16m
csi-driver-node-plugin-g92sj 3/3 Running 0 5h16m
csi-driver-node-plugin-x6ccw 3/3 Running 0 5h16m
iomesh-chunk-0 3/3 Running 0 5h16m
iomesh-chunk-1 3/3 Running 0 5h16m
iomesh-chunk-2 3/3 Running 0 5h16m
iomesh-iscsi-redirector-5zxps 2/2 Running 2 5h16m
iomesh-iscsi-redirector-tts7t 2/2 Running 2 5h16m
iomesh-iscsi-redirector-wkkmf 2/2 Running 2 5h16m
iomesh-meta-0 2/2 Running 0 5h16m
iomesh-meta-1 2/2 Running 0 5h16m
iomesh-meta-2 2/2 Running 1 5h16m
iomesh-zookeeper-0 1/1 Running 0 5h17m
iomesh-zookeeper-1 1/1 Running 0 5h17m
iomesh-zookeeper-2 1/1 Running 0 5h17m
ndm-cluster-exporter-8675b6f567-59htp 1/1 Running 0 5h18m
ndm-node-exporter-5svzp 1/1 Running 0 5h18m
ndm-node-exporter-b5cq5 1/1 Running 0 5h18m
ndm-node-exporter-rvxp9 1/1 Running 0 5h18m
node-disk-manager-8xb28 1/1 Running 0 5h18m
node-disk-manager-k96vx 1/1 Running 0 5h18m
node-disk-manager-zdv9z 1/1 Running 0 5h18m
node-disk-operator-7c84b8bd6c-qtxwc 1/1 Running 0 5h18m
operator-5d6654b765-nq4xf 1/1 Running 0 5h18m
operator-5d6654b765-rsxtl 1/1 Running 0 5h18m
operator-5d6654b765-xbff4 1/1 Running 0 5h18m
operator-hostpath-provisioner-92q8m 1/1 Running 0 5h18m
operator-hostpath-provisioner-fcc2n 1/1 Running 0 5h18m
operator-hostpath-provisioner-nqs87 1/1 Running 0 5h18m
operator-zookeeper-operator-7857446f9d-hdk58 1/1 Running 0 5h18m
4.4. 为 IOMesh 配置需要使用的磁盘
$ kubectl --namespace iomesh-system -o wide get blockdevice
NAME NODENAME PATH FSTYPE SIZE CLAIMSTATE STATUS AGE
blockdevice-172e6c145082946722af09de120e95cb iomesh-worker-2 /dev/sde 1000204886016 Unclaimed Active 4h33m
blockdevice-181fd7de984d1f3bf8a822231305d848 iomesh-worker-0 /dev/sdc 480103981056 Unclaimed Active 4h33m
blockdevice-2112d804c533a2e639dde2c8c2aa680c iomesh-worker-2 /dev/sdg 1000204886016 Unclaimed Active 4h33m
blockdevice-5f8f4a55223a4e31297bf5bbd1834d4d iomesh-worker-2 /dev/sdc 480103981056 Unclaimed Active 4h33m
blockdevice-7d5a19ae1d004bab5bdec5a865961431 iomesh-worker-0 /dev/sdf 1000204886016 Unclaimed Active 4h33m
blockdevice-af6eaf1ec86919299c97af504a32c2a4 iomesh-worker-1 /dev/sde 1000204886016 Unclaimed Active 4h33m
blockdevice-b02db4667a0182bd9c6a103afab03136 iomesh-worker-2 /dev/sdf 1000204886016 Unclaimed Active 4h33m
blockdevice-b20f47398cd0ee2b877482d2b19a9509 iomesh-worker-1 /dev/sdc 480103981056 Unclaimed Active 4h33m
blockdevice-b7648c5f99e59eb503e27563697d9399 iomesh-worker-2 /dev/sdb 480103981056 Unclaimed Active 4h33m
blockdevice-d9a0950d2472f25bb609aed6f4dc8397 iomesh-worker-1 /dev/sdb 480103981056 Unclaimed Active 4h33m
blockdevice-e0661c3e4bbfea76770506d505a17778 iomesh-worker-0 /dev/sde 1000204886016 Unclaimed Active 4h33m
blockdevice-ea469fb8e07e3c668bb97529abccbd0a iomesh-worker-0 /dev/sdb 480103981056 Unclaimed Active 4h33m
blockdevice-ed95a33533b021d8247f3a8478180717 iomesh-worker-0 /dev/loop0 ext4 62914560 Unclaimed Active 4h33m
4.5. 为节点配置存储
在日常使用过程中，我们通常会指定节点中的一部分磁盘给 IOMesh 使用，配置时请在特定节点的 Chunk 小节中加相应参数就好，例如：
我们只用节点中 2 块 SSD 和 1 块 HDD，分别做为 Cache 盘 与容量盘使用，在这里 SDD 为 dev.sdb 、dev.sdc 与 HDD 为 dev.sde。
$ kubectl edit iomesh -n iomesh-system
...
<!tuncated>
...
spec:
chunk:
dataCIDR: 10.234.1.0/24
deviceMap:
cacheWithJournal:
selector:
matchExpressions:
- key: iomesh.com/bd-devicePath
operator: In
values:
- dev.sdb
- dev.sdc
dataStore:
selector:
matchLabels:
iomesh.com/bd-devicePath: dev.sde
配置完成之后我们可以在以下输出中看到存储的情况, id 代表 Node，totalCacheCapacity 代表我们配置的 SSD， totalDataCapacity 代表我们配置的容量盘。
$ kubectl edit iomesh -n iomesh-system -oyaml
...
<!tuncated>
...
summary:
chunkSummary:
chunks:
- id: 1
ip: 10.234.1.3
spaceInfo:
dirtyCacheSpace: 1.91Gi
totalCacheCapacity: 854.26Gi
totalDataCapacity: 876.72Gi
usedCacheSpace: 9.91Gi
usedDataSpace: 65.00Gi
status: CHUNK_STATE_IN_USE
- id: 2
ip: 10.234.1.1
spaceInfo:
dirtyCacheSpace: 2.15Gi
totalCacheCapacity: 854.26Gi
totalDataCapacity: 876.72Gi
usedCacheSpace: 26.15Gi
usedDataSpace: 95.00Gi
status: CHUNK_STATE_IN_USE
- id: 3
ip: 10.234.1.2
spaceInfo:
dirtyCacheSpace: 577.50Mi
totalCacheCapacity: 854.26Gi
totalDataCapacity: 876.72Gi
usedCacheSpace: 16.56Gi
usedDataSpace: 36.00Gi
status: CHUNK_STATE_IN_USE
clusterSummary:
spaceInfo:
dirtyCacheSpace: 4.62Gi
totalCacheCapacity: 2.50Ti
totalDataCapacity: 2.57Ti
usedCacheSpace: 52.62Gi
usedDataSpace: 196.00Gi
metaSummary:
aliveHost:
- 10.233.79.21
- 10.233.85.22
- 10.233.88.16
leader: 10.233.79.21:10100
status: META_RUNNING
4.6. 再次查看存储使用情况
再次查看存储使用情况, 确认 Claimed 的磁盘与设计的一致, 2 块 SSD 和 1 块 HDD
$ kubectl --namespace iomesh-system -o wide get blockdevice |grep Claimed
blockdevice-172e6c145082946722af09de120e95cb iomesh-worker-2 /dev/sde 1000204886016 Claimed Active 6d23h
blockdevice-5f8f4a55223a4e31297bf5bbd1834d4d iomesh-worker-2 /dev/sdc 480103981056 Claimed Active 6d23h
blockdevice-b7648c5f99e59eb503e27563697d9399 iomesh-worker-2 /dev/sdb 480103981056 Claimed Active 6d23h
blockdevice-af6eaf1ec86919299c97af504a32c2a4 iomesh-worker-1 /dev/sde 1000204886016 Claimed Active 6d23h
blockdevice-b20f47398cd0ee2b877482d2b19a9509 iomesh-worker-1 /dev/sdc 480103981056 Claimed Active 6d23h
blockdevice-d9a0950d2472f25bb609aed6f4dc8397 iomesh-worker-1 /dev/sdb 480103981056 Claimed Active 6d23h
blockdevice-e0661c3e4bbfea76770506d505a17778 iomesh-worker-0 /dev/sde 1000204886016 Claimed Active 6d23h
blockdevice-ea469fb8e07e3c668bb97529abccbd0a iomesh-worker-0 /dev/sdb 480103981056 Claimed Active 6d23h
blockdevice-181fd7de984d1f3bf8a822231305d848 iomesh-worker-0 /dev/sdc 480103981056 Claimed Active 6d23h
5. 配置测试环境存储与快照类
5.1. 配置 storageclass
设置存储类为默认
$ kubectl patch storageclass iomesh-csi-driver -p '{"metadata": {"annotations":{"storageclass.beta.kubernetes.io/is-default-class":"true"}}}'
storageclass.storage.k8s.io/iomesh-csi-driver patched
$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
hostpath kubevirt.io/hostpath-provisioner Delete WaitForFirstConsumer false 24h
iomesh-csi-driver (default) com.iomesh.csi-driver Retain Immediate true 24h
5.2. 配置 Volumesnapshotclass
$ vim iomesh-snapshotter.yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
name: iomesh-snapshotter
driver: com.iomesh.csi-driver
deletionPolicy: Delete
$ kubectl apply -f iomesh-snapshotter.yaml
$ kubectl get volumesnapshotclass
NAME DRIVER DELETIONPOLICY AGE
iomesh-csi-driver com.iomesh.csi-driver Delete 121d
iomesh-snapshotter com.iomesh.csi-driver Delete 25h
$ kubectl annotate storageclass iomesh-csi-driver k10.kasten.io/volume-snapshot-class=iomesh-snapshotter
$ kubectl get sc iomesh-csi-driver -oyaml
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
k10.kasten.io/volume-snapshot-class: iomesh-snapshotter # 与 K10 联动的快照类
meta.helm.sh/release-name: csi-driver
meta.helm.sh/release-namespace: iomesh-system
storageclass.beta.kubernetes.io/is-default-class: "true" # 设置为默认存储类
name: iomesh-csi-driver
parameters:
csi.storage.k8s.io/fstype: ext4
replicaFactor: "2"
thinProvision: "true"
provisioner: com.iomesh.csi-driver
reclaimPolicy: Retain
volumeBindingMode: Immediate
6. 用 Kasten kubestr 对存储进行评测
Kubestr 是一个简单的轻量级云原生存储跑分工具，用于评估集群中的存储选项。它可以帮助您发现、验证和评估 您的云原生存储，以明确当前配置的状态与存储能力是否满足应用的要求。当比较跨多个集群、云平台与存储选项的性能时，还可以通过切换 Kubeconfig 使其跨多个集群运行。
6.1. Kubestr 的安装
下载 Kubestr, 从如下链接可以直接下载您所需要的 Kubestr 版本
https://github.com/kastenhq/kubestr/releases/tag/v0.4.17
用 wget 可以直接获取 Kubestr 软件包, 并解包
$ wget https://github.com/kastenhq/kubestr/releases/download/v0.4.17/kubestr-v0.4.17-linux-amd64.tar.gz
$ tar -zxvf kubestr-v0.4.17-linux-amd64.tar.gz
LICENSE
README.md
kubestr
6.2. 检查 kubenetes 环境 与 Storage Provisioners
$ ./kubestr
**************************************
_ ___ _ ___ ___ ___ _____ ___
| |/ / | | | _ ) __/ __|_ _| _ \
| ' <| |_| | _ \ _|\__ \ | | | /
|_|\_\\___/|___/___|___/ |_| |_|_\
Explore your Kubernetes storage options
**************************************
Kubernetes Version Check:
Valid kubernetes version (v1.19.3) - OK
RBAC Check:
Kubernetes RBAC is enabled - OK
Aggregated Layer Check:
The Kubernetes Aggregated Layer is enabled - OK
Available Storage Provisioners:
com.iomesh.csi-driver:
Storage Classes:
* iomesh-csi-driver
To perform a FIO test, run-
./kubestr fio -s <storage class>
6.3. 进行快照功能测试
经过Kubestr 测试，可以看到 IOMesh CSI 快照功能与 Kasten 可以正常联动，详细情况见如下的测试结果。
$ ./kubestr csicheck -s iomesh-csi-driver -v iomesh-snapshotter
Creating application
-> Created pod (kubestr-csi-original-podx5v6c) and pvc (kubestr-csi-original-pvc997kf)
Taking a snapshot
-> Created snapshot (kubestr-snapshot-20211112154849)
Restoring application
-> Restored pod (kubestr-csi-cloned-pod5llrx) and pvc (kubestr-csi-cloned-pvc46rbr)
Cleaning up resources
CSI checker test:
CSI application successfully snapshotted and restored. - OK
6.4. 进行简单的性能测试
性能测试的默认用例将涉及如下场景，配置文件如下所示。同时存储性能测试会创建一个 20G 的卷， 如果您希望调整测试场景与卷大小，可使用 -f 来写配置文件， -z 选项来指定卷的大小。经过调优配置，从测试的结果来看 IOMesh 的表现非常出色，详细情况见如下的测试结果。
$ cat ziyin-fio
[global]
ioengine=libaio
direct=1
size=2G
[warmup]
stonewall
iodepth=256
bs=256k
rw=write
[job1]
stonewall
name=read_iops
bs=4K
iodepth=128
readwrite=randread
[job2]
stonewall
name=write_iops
bs=4K
iodepth=128
readwrite=randwrite
$./kubestr fio -s iomesh-csi-driver -f ziyin-fio -z 20Gi
PVC created kubestr-fio-pvc-ptld8
Pod created kubestr-fio-pod-hncmn
Running FIO test (ziyin-fio) on StorageClass (iomesh-csi-driver) with a PVC of Size (20Gi)
Elapsed time- 33.070795754s
FIO test results:
FIO version - fio-3.20
Global options - ioengine=libaio verify= direct=1 gtod_reduce=
JobName:
blocksize=256k filesize= iodepth=256 rw=write
write:
IOPS=3369.806641 BW(KiB/s)=862670
iops: min=3338 max=3508 avg=3400.333252
bw(KiB/s): min=854528 max=898048 avg=870532.687500
JobName: read_iops
blocksize=4K filesize= iodepth=128 rw=randread
read:
IOPS=71594.703125 BW(KiB/s)=286378
iops: min=69477 max=75236 avg=71802.703125
bw(KiB/s): min=277909 max=300944 avg=287211.312500
JobName: write_iops
blocksize=4K filesize= iodepth=128 rw=randwrite
write:
IOPS=32949.222656 BW(KiB/s)=131796
iops: min=25750 max=35708 avg=33020.582031
bw(KiB/s): min=103001 max=142832 avg=132082.359375
Disk stats (read/write):
sdi: ios=523901/524713 merge=387/7600 ticks=913316/1727700 in_queue=2641015, util=97.184769%
- OK
7. 安装 Kasten K10 到 K8S 集群
7.1. 添加 Kasten Helm charts 存储库
1. 获取 Helm Chart 供本地使用
$ helm repo add kasten https://charts.kasten.io/
$ helm repo list
NAME URL ls
kasten https://charts.kasten.io/
$ helm repo update
#以下这条命令会把 k10-4.0.x.tgz 包下载下来，如果不加任何参数，则会下载最新的版本
#在Air Gapped 的环境中安装时，可以先行下载再使用。
$ helm fetch kasten/k10 --version=4.0.13
7.2. 为 Kasten 建立命名空间
$ kubectl create namespace kasten-io
namespace/kasten-io created
7.3. 安装 Kasten K10
$ helm install k10 k10-4.0.13.tgz --namespace kasten-io --set global.airgapped.repository=ccr.ccs.tencentyun.com/kasten \
--set auth.basicAuth.enabled=true \
--set auth.basicAuth.htpasswd='mars:$apr1$Cgu1sGVZ$w/8aLHZkVT73OqYZ06C0v.' \
--set metering.mode=airgap \
--set global.persistence.storageClass=iomesh-csi-driver
目前在不同的 K8S 环境下部署 K10 有很多参数需要设置，此时我们需要查阅部署参数。
查看 Kasten Helm 部署的参数
Complete List of K10 Helm Options
https://docs.kasten.io/latest/install/advanced.html
确认 Kasten K10 Pod 及 Service 的部署情况
# 查看 Pod 部署与运行的情况
$ kubectl get po -n kasten-io
NAME READY STATUS RESTARTS AGE
aggregatedapis-svc-578f8c55d-gjz4p 1/1 Running 0 7m1s
auth-svc-59b588d887-fq9b9 1/1 Running 0 7m1s
catalog-svc-7f8c548fb5-qns75 2/2 Running 0 7m1s
config-svc-6b76cdbc87-k6sf5 1/1 Running 0 7m1s
crypto-svc-774bbf4b4d-mx9qd 2/2 Running 0 7m
dashboardbff-svc-5979b74c84-9z4gp 1/1 Running 0 7m1s
executor-svc-7f875fdf69-b52g8 2/2 Running 0 7m1s
executor-svc-7f875fdf69-gfnnc 2/2 Running 0 7m1s
executor-svc-7f875fdf69-qk6t7 2/2 Running 0 7m1s
frontend-svc-8597b758d5-cxt49 1/1 Running 0 7m
gateway-866949d965-qrbmb 1/1 Running 0 7m1s
jobs-svc-7dd6d754b9-6m7zj 1/1 Running 0 7m1s
kanister-svc-7dc69d8ff7-vxggv 1/1 Running 0 7m1s
logging-svc-6d879f9f74-fwt6c 1/1 Running 0 7m
metering-svc-75d688585-hwvzt 1/1 Running 0 7m1s
prometheus-server-6976c79945-4chfq 2/2 Running 0 7m1s
state-svc-7f7978fbfc-8fffk 1/1 Running 0 7m1s
# 查看 PVC 的使用情况
$ kubectl get pvc -n kasten-io
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
catalog-pv-claim Bound pvc-194a11e5-cd24-48e2-ab21-75c013898831 20Gi RWO iomesh-csi-driver 8m32s
jobs-pv-claim Bound pvc-6de0bee8-55e9-4786-9f1a-ae8205e9c70f 20Gi RWO iomesh-csi-driver 8m32s
logging-pv-claim Bound pvc-90e5519d-4705-406c-85aa-f3293cc78529 20Gi RWO iomesh-csi-driver 8m32s
metering-pv-claim Bound pvc-b6f864ee-0757-426f-928d-0472e44739e0 2Gi RWO iomesh-csi-driver 8m32s
prometheus-server Bound pvc-6444280c-eb45-422e-9fa1-59b454469066 8Gi RWO iomesh-csi-driver 8m32s
# 查看服务的运行情况
$ kubectl get svc -n kasten-io
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
aggregatedapis-svc ClusterIP 10.233.17.24 <none> 443/TCP 8m40s
auth-svc ClusterIP 10.233.61.177 <none> 8000/TCP 8m41s
catalog-svc ClusterIP 10.233.8.43 <none> 8000/TCP 8m41s
config-svc ClusterIP 10.233.54.100 <none> 8000/TCP 8m40s
crypto-svc ClusterIP 10.233.60.84 <none> 8000/TCP,8001/TCP 8m40s
dashboardbff-svc ClusterIP 10.233.62.183 <none> 8000/TCP 8m40s
executor-svc ClusterIP 10.233.46.88 <none> 8000/TCP 8m40s
frontend-svc ClusterIP 10.233.24.176 <none> 8000/TCP 8m41s
gateway ClusterIP 10.233.53.97 <none> 8000/TCP 8m41s
gateway-admin ClusterIP 10.233.3.50 <none> 8877/TCP 8m41s
jobs-svc ClusterIP 10.233.18.108 <none> 8000/TCP 8m41s
kanister-svc ClusterIP 10.233.6.98 <none> 8000/TCP 8m41s
logging-svc ClusterIP 10.233.14.189 <none> 8000/TCP,24224/TCP,24225/TCP 8m41s
metering-svc ClusterIP 10.233.19.201 <none> 8000/TCP 8m41s
prometheus-server ClusterIP 10.233.4.142 <none> 80/TCP 8m41s
prometheus-server-exp ClusterIP 10.233.54.81 <none> 80/TCP 8m41s
state-svc ClusterIP 10.233.47.50 <none> 8000/TCP 8m40s
7.5. 访问 Kasten K10 控制台
通过查看 K8S Service，我们可以看到 K10的 ingress 配置， 暴露 gateway service 给 NodePort, 查看 访问 K10 的 IP 地址，访问 http://192.168.30.200:32462/k10/#
# 暴露 gateway service 给 NodePort
$ kubectl expose service gateway -n kasten-io --type=NodePort --name=gateway-nodeport
service/gateway-nodeport exposed
# 查看 NodePort端口
$ kubectl get svc -n kasten-io gateway-nodeport
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gateway-nodeport NodePort 10.233.31.169 <none> 8000:32462/TCP 19s
# 查看 Node IP 任意一个 Node IP 都有效
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
iomesh-master-0 Ready master 337d v1.19.3 192.168.30.200 <none> CentOS Linux 8 4.18.0-240.1.1.el8_3.x86_64 containerd://1.3.9
iomesh-master-1 Ready master 337d v1.19.3 192.168.30.201 <none> CentOS Linux 8 4.18.0-240.1.1.el8_3.x86_64 containerd://1.3.9
iomesh-master-2 Ready master 337d v1.19.3 192.168.30.202 <none> CentOS Linux 8 4.18.0-240.1.1.el8_3.x86_64 containerd://1.3.9
iomesh-worker-0 Ready <none> 4d1h v1.19.3 192.168.17.85 <none> CentOS Linux 8 4.18.0-305.25.1.el8_4.x86_64 containerd://1.2.13
iomesh-worker-1 Ready <none> 4d v1.19.3 192.168.17.86 <none> CentOS Linux 8 4.18.0-305.25.1.el8_4.x86_64 containerd://1.2.13
iomesh-worker-2 Ready <none> 3d23h v1.19.3 192.168.17.87 <none> CentOS Linux 8 4.18.0-305.25.1.el8_4.x86_64 containerd://1.2.13
访问 http://192.168.30.200:32462/k10/# in chrome web browser
8. 结合 IOMesh CSI 保护云原生应用测试
8.1. 测试应用 MySQL 的安装
$ kubectl create namespace mysql
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install mysql-release bitnami/mysql --namespace mysql \
--set auth.rootPassword='Start123' \
--set primary.persistence.size=10Gi
$ kubectl get pvc,po,svc,statefulset -n mysql
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/data-mysql-release-0 Bound pvc-d470bf21-0f72-4cf8-b87b-25eddaa1f24d 10Gi RWO iomesh-csi-driver 25h
NAME READY STATUS RESTARTS AGE
pod/mysql-release-0 1/1 Running 0 24h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/mysql-release ClusterIP 10.233.3.18 <none> 3306/TCP 25h
service/mysql-release-headless ClusterIP None <none> 3306/TCP 25h
NAME READY AGE
statefulset.apps/mysql-release 1/1 25h
8.2. 应用程序发现
在应用程序安装完成之后,我们就可以在 Application 列表中发现这个应用了
8.3. 应用程序的备份与恢复
8.3.1 建立 MySQL 数据集
# 登录到 MySQL 容器
$ kubectl exec -ti $(kubectl get pods -n mysql --selector=app.kubernetes.io/instance=mysql-release -o=jsonpath='{.items[0].metadata.name}') -n mysql -- bash
# 登录 MySQL
$ mysql --user=root --password=Start123
# 建立 "test" 数据库， 并使用这个库
$ mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.01 sec)
$ mysql> USE test;
Database changed
# 创建 "pets" 表
$ mysql> CREATE TABLE pets (name VARCHAR(20), owner VARCHAR(20), species VARCHAR(20), sex CHAR(1), birth DATE, death DATE);
Query OK, 0 rows affected (0.03 sec)
# 插入一行数据
$ mysql> INSERT INTO pets VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL);
Query OK, 1 row affected (0.01 sec)
# 查看 "pets" 表中的数据
$ mysql> SELECT * FROM pets;
+----------+-------+---------+------+------------+-------+
| name | owner | species | sex | birth | death |
+----------+-------+---------+------+------------+-------+
| Puffball | Diane | hamster | f | 1999-03-30 | NULL |
+----------+-------+---------+------+------------+-------+
1 row in set (0.00 sec)
8.3.2 创建 Policy 保护 MySQL 应用
创建 Policy 保护 MySQL 应用，之后点击 Run Once
查看 Dashboard 中的快照备份已经完成，并生成了还原点。
查看系统中快照已经生成
$ kubectl get pvc -n mysql
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-mysql-release-0 Bound pvc-d470bf21-0f72-4cf8-b87b-25eddaa1f24d 10Gi RWO iomesh-csi-driver 41h
$ kubectl get volumesnapshotcontent -n mysql
NAME READYTOUSE RESTORESIZE DELETIONPOLICY DRIVER VOLUMESNAPSHOTCLASS VOLUMESNAPSHOT AGE
snapcontent-f3cfb1be-fe52-49f5-ac1a-7473112fb15e true 10737418240 Delete com.iomesh.csi-driver iomesh-snapshotter k10-csi-snap-bwdzlxpkjc4qfxc6 4h46m
snapcontent-f5f1638c-efb2-410f-90b1-875e90991da0 true 10737418240 Delete com.iomesh.csi-driver iomesh-snapshotter k10-csi-snap-5gljr2d4vqgxzvbc 46m
8.3.3 模拟灾难 删除 MySQL 数据
# 登录 Mysql Pod 中的 MySQL 数据库
$ kubectl exec -ti $(kubectl get pods -n mysql --selector=app.kubernetes.io/instance=mysql-release -o=jsonpath='{.items[0].metadata.name}') -n mysql -- bash
$ mysql --user=root --password=Start123
# Drop the test database
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| my_database |
| mysql |
| performance_schema |
| sys |
| test |
+--------------------+
6 rows in set (0.00 sec)
mysql> DROP DATABASE test;
Query OK, 1 row affected (0.15 sec)
mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| my_database |
| mysql |
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.00 sec)
8.3.4 还原 MySQL 数据
要恢复丢失的数据， 我们需要使用之前创建的备份时间点，进行 Policy 的 Restore 操作，在这里我们新建一个 namespace mysql-resore。
在恢复的过程中我们可以观察 Dashboard 或从命令行查看新的 Namesspace 中 Pod 的部署情况, 这时查看系统可以发现 K10 利用快照 Clone 出的新的 PVC , DataSource 为 Snapshot , k10-csi-snap-qgrkmcbs8ffdm8jm
$ kubectl get po -n mysql-restore -w
NAME READY STATUS RESTARTS AGE
mysql-release-0 1/2 Running 0 44s
mysql-release-0 1/2 Running 0 100s
mysql-release-0 2/2 Running 0 110s
# 查看系统,发现 K10 利用快照 Clone 出的新的 PVC , DataSource 为 Snapshot , k10-csi-snap-qgrkmcbs8ffdm8jm
$ kubectl get volumesnapshotcontent -n mysql-restore
NAME READYTOUSE RESTORESIZE DELETIONPOLICY DRIVER VOLUMESNAPSHOTCLASS VOLUMESNAPSHOT AGE
k10-csi-snap-qgrkmcbs8ffdm8jm-content-e67a687d-719a-4c55-b940-47b1aeeb1553 true 0 Retain com.iomesh.csi-driver k10-clone-iomesh-snapshotter k10-csi-snap-qgrkmcbs8ffdm8jm 8m44s
$ kubectl get pvc data-mysql-release-0 -n mysql-restore
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-mysql-release-0 Bound pvc-d00fcbe3-fec7-4b55-b2ad-d5a4ed93763f 10Gi RWO iomesh-csi-driver 5m59s
$ kubectl get pvc data-mysql-release-0 -n mysql-restore -oyaml
<truncated...>
dataSource:
apiGroup: snapshot.storage.k8s.io
kind: VolumeSnapshot
name: k10-csi-snap-qgrkmcbs8ffdm8jm
resources:
requests:
storage: "10737418240"
storageClassName: iomesh-csi-driver
volumeMode: Filesystem
volumeName: pvc-d00fcbe3-fec7-4b55-b2ad-d5a4ed93763f
status:
accessModes:
- ReadWriteOnce
capacity:
storage: 10Gi
phase: Bound
8.3.5 查看还原后的 MySQL 数据
查看已经删除的数据表,可以看到数据已经恢复了
# 登录 Mysql Pod 中的 MySQL 数据库
$ kubectl exec -ti $(kubectl get pods -n mysql-restore --selector=app.kubernetes.io/instance=mysql-release -o=jsonpath='{.items[0].metadata.name}') -n mysql -- bash
$ mysql --user=root --password=Start123
# 查看已经删除的数据表,可以看到数据已经恢复了
$ mysql> SHOW DATABASES;
+--------------------+
| Database |
+--------------------+
| information_schema |
| my_database |
| mysql |
| performance_schema |
| sys |
| test |
+--------------------+
6 rows in set (0.01 sec)
$ mysql> USE test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
$ mysql> SELECT * FROM pets;
+----------+-------+---------+------+------------+-------+
| name | owner | species | sex | birth | death |
+----------+-------+---------+------+------------+-------+
| Puffball | Diane | hamster | f | 1999-03-30 | NULL |
+----------+-------+---------+------+------------+-------+
1 row in set (0.03 sec)
9. 将数据 Export 到对象存储实现长期保留
在与 IOMesh 一起测试时，我们了解到 IOMesh 也在对象存储领域上进行了研发，在不久就将会有自主的对象存储产品面世。
9.1 创建 Location Profile
9.2 编辑 Policy 设定将快照备份导出到 MINIO 对象存储
9.3 点击 Run Once 运行新规则
9.4 查看数据备份进程
如下图，我们可以看到数据已经 Export 到 MINIO Bucket ，并且意识到这是数据库类型的应用，需要启动 Kanister 应用感知的备份。
从 MINIO 的 对象存储桶上可以浏览到数据已经存在
9.5 利用对象存储库的备份集进行恢复
查看还原的进程
9.6 从 k8s 上确认数据已经恢复
$ kubectl get po -n mysql-from-minio
NAME READY STATUS RESTARTS AGE
mysql-release-0 1/1 Running 0 3m
9.7 从 Kasten K10 上观察存储库的数据使用情况
10. 总结
在本期文章中我们验证了结合 IOMesh CSI 容器存储解决方案保护云原生应用的方法。首先，我们利用 Kubestr 对云原生存储进行评测，并使用 Kasten K10 对存储 CSI 进行调用生成快照，达成最快速的 RPO 与 RTO 的备份与恢复，之后，我们利用 MINIO 的对象存储，将快照数据导出到对象存储桶上，实现了异地容灾与数据长期保留，欢迎与我们讨论您的观点与想法！
欢迎您关注云端数据管理
最后，还是希望与您多多讨论，详细内容也可以参考 Kasten by Veeam 的官方手册查看详细内容，今后还会计划推出更多精彩内容。请长按下并关注，为了让更多的人看到请点下右下角“在看”啊！;-)
参考链接
Kubernetes Container Storage Interface (CSI) Documentation https://kubernetes-csi.github.io/docs/ Kasten k10 实战系列 03 CSI 存储快照适配 https://www.data2clouds.com/?p=69 Kasten k10 实战系列 04 - 利用 Kubestr 进行云原生存储能力评测https://www.data2clouds.com/?p=71/ Kasten K10 系统需求 https://docs.kasten.io/latest/operating/footprint.html 详解支持 IOMesh 安装文档 https://docs.iomesh.com/deploy/install-iomesh IOMesh 介绍 https://docs.iomesh.com/about-iomesh/introduction MINIO 介绍 https://docs.min.io/