实战：k8s之Longhorn备份恢复-2022.2.26

最新推荐文章于 2024-04-19 11:06:23 发布

一念一生～one

最新推荐文章于 2024-04-19 11:06:23 发布

阅读量1.5k

点赞数 1

分类专栏： k8s 文章标签： java linux docker

本文链接：https://blog.csdn.net/weixin_39246554/article/details/123145198

版权

k8s 专栏收录该内容

118 篇文章 31 订阅

订阅专栏

实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

实验软件

链接：https://pan.baidu.com/s/15jonSS_pK60GWnjzfqQafA?pwd=l8rj
提取码：l8rj
2022.2.25-47.Longhorn备份恢复-实验代码

1、备份恢复

Longhorn 提供了备份恢复功能，要使用这个功能我们需要给卷创建一个 snapshot 快照，快照是 Kubernetes Volume 在任何指定时间点的状态。

📍 案例演示：longhorn备份恢复(成功测试)

1️⃣ 手动快照

🍀 在 Longhorn UI 的 Volume 页面中点击要创建快照的卷，进入卷的详细信息页面，点击下方的 Take Snapshot 按钮即可创建快照了。

创建快照后，将在卷头(Volume Head)之前的快照列表中可以看到它，比如这里我们会前面测试使用的 mysql 卷创建一个快照：

同样在节点的数据目录下面也可以看到创建的快照数据：(随便进一个节点就好)

[root@master1 ~]#ssh node2
[root@node2 ~]#tree /var/lib/longhorn/replicas/pvc-52031b79-4905-47be-b8fc-09629c25de1f-863b6d00/
/var/lib/longhorn/replicas/pvc-52031b79-4905-47be-b8fc-09629c25de1f-863b6d00/
|-- revision.counter
|-- volume-head-001.img #是个二进制文件
|-- volume-head-001.img.meta
|-- volume-snap-68170f81-72c9-4a7e-b359-520938a49af3.img
|-- volume-snap-68170f81-72c9-4a7e-b359-520938a49af3.img.meta
`-- volume.meta

0 directories, 6 files

其中的 volume-snap-xxx 后面的数据和页面上的快照名称是一致的，比如页面中我们刚刚创建的快照名称为 68170f81-72c9-4a7e-b359-520938a49af3，其中的 img 文件是镜像文件，而 img.meta 是保持当前快照的元信息：

[root@node2 ~]#cat /var/lib/longhorn/replicas/pvc-52031b79-4905-47be-b8fc-09629c25de1f-863b6d00/volume-snap-68170f81-72c9-4a7e-b359-520938a49af3.img.meta 
{"Name":"volume-head-000.img","Parent":"","Removed":false,"UserCreated":true,"Created":"2022-02-24T13:26:33Z","Labels":null}

元信息里面包含父级的文件镜像，这其实表面快照是增量的快照。

2️⃣ 周期性快照和备份

🍀 此外除了手动创建快照之外，从 Longhorn UI 上还可以进行周期性快照和备份，同样在卷的详细页面可以进行配置，在 Recurring Jobs Schedule 区域点击 Add 按钮即可创建一个定时的快照。

定时快照

创建任务的时候可以选择任务类型是备份(backup)或快照(snapshot)，任务的时间以 CRON 表达式的形式进行配置，还可以配置要保留的备份或快照数量以及标签。

⚠️ 为了避免当卷长时间没有新数据时，recurring jobs 可能会用相同的备份和空快照覆盖旧的备份/快照的问题，Longhorn 执行以下操作：

Recurring backup job 仅在自上次备份以来卷有新数据时才进行新备份
Recurring snapshot job 仅在卷头(volume head)中有新数据时才拍摄新快照

3️⃣ 使用 Kubernetes 的 StorageClass 来配置定时快照

此外我们还可以通过使用 Kubernetes 的 StorageClass 来配置定时快照，可以通过 StorageClass 的 recurringJobs 参数配置定时备份和快照，recurringJobs 字段应遵循以下 JSON 格式：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  fromBackup: ""
  recurringJobs: '[
    {
      "name":"snap",
      "task":"snapshot",
      "cron":"*/1 * * * *",
      "retain":1
    },
    {
      "name":"backup",
      "task":"backup",
      "cron":"*/2 * * * *",
      "retain":1
    }
  ]'

应为每个 recurring job 指定以下参数：

name：认为的名称，不要在一个 recurringJobs 中使用重复的名称，并且 name 的长度不能超过 8 个字符
task：任务的类型，它仅支持 snapshot 或 backup
cron：Cron 表达式，指定任务的执行时间
retain：Longhorn 将为一项任务保留多少快照/备份，不少于 1

使用这个 StorageClass 创建的任何卷都将自动配置上这些 recurring jobs。

4️⃣ 使用备份卷

🍀 要备份卷就需要在 Longhorn 中配置一个备份目标，可以是一个 NFS 服务或者 S3 兼容的对象存储服务，用于存储 Longhorn 卷的备份数据，备份目标可以在 Settings/General/BackupTarget 中配置，我们这里使用 Helm Chart 安装的，最好的方式是去定制 values 文件中的 defaultSettings.backupTarget，当然也可以直接去通过 Longhorn UI 进行配置，比如这里我们先配置备份目标为 nfs 服务，Backup Target 值设置为 nfs://172.29.9.51:/var/lib/k8s/data（要确保目录存在），Backup Target Credential Secret 留空即可，然后拉到最下面点击 Save：

backup 配置

备份目标配置后，就可以开始备份了。

这里和修改下面是等价的：

同样导航到 Longhorn UI 的 Volume 页面，选择要备份的卷，点击 Create Backup，然后添加合适的标签点击 OK 即可。

创建备份

🍀 备份完成后导航到 Backup 页面就可以看到对应的备份数据了：

备份数据

🍀 这些备份的数据也会对应一个 backupvolumes crd 对象：

➜ kubectl get backupvolumes -n longhorn-system
NAME                                       CREATEDAT              LASTBACKUPNAME            LASTBACKUPAT           LASTSYNCEDAT
pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307   2022-02-22T09:23:24Z   backup-8ae4af9c49534859   2022-02-22T09:23:24Z   2022-02-22T09:41:09Z

然后我们去到 NFS 服务器上查看会在挂载目录下面创建一个 backupstore 目录，下面会保留我们备份的数据：

➜ tree /var/lib/k8s/data/backupstore
/var/lib/k8s/data/backupstore
└── volumes
    └── 5e
        └── b6
            └── pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307
                ├── backups
                │   └── backup_backup-8ae4af9c49534859.cfg
                ├── blocks
                │   ├── 02
                │   │   └── 2e
                │   │       └── 022eefc6526cd3d8fc3a9f9a4ba253a910c61a1c430a807403f60a2f233fa210.blk
                ......
                │   └── f7
                │       └── e3
                │           └── f7e3ae1f83e10da4ece5142abac1fafc0d0917370f7418874c151a66a18bfa15.blk
                └── volume.cfg

51 directories, 25 files

🍀 同样这个时候我们也可以去快照列表选择要备份的快照：

备份快照

🍀 有了备份数据后要想要恢复数据，只需要选择对应的备份数据，点击 Restore Latest Backup 恢复数据即可：

恢复数据

🍀 查看存在的crd

[root@master1 ~]#kubectl get crd |grep longhorn
backingimagedatasources.longhorn.io      2022-02-23T14:01:40Z
backingimagemanagers.longhorn.io         2022-02-23T14:01:40Z
backingimages.longhorn.io                2022-02-23T14:01:40Z
backups.longhorn.io                      2022-02-23T14:01:40Z
backuptargets.longhorn.io                2022-02-23T14:01:40Z
backupvolumes.longhorn.io                2022-02-23T14:01:40Z
engineimages.longhorn.io                 2022-02-23T14:01:40Z
engines.longhorn.io                      2022-02-23T14:01:40Z
instancemanagers.longhorn.io             2022-02-23T14:01:40Z
nodes.longhorn.io                        2022-02-23T14:01:40Z
recurringjobs.longhorn.io                2022-02-23T14:01:40Z
replicas.longhorn.io                     2022-02-23T14:01:40Z
settings.longhorn.io                     2022-02-23T14:01:40Z
sharemanagers.longhorn.io                2022-02-23T14:01:40Z
volumes.longhorn.io                      2022-02-23T14:01:40Z
[root@master1 ~]#kubectl get backuptargets -nlonghorn-system
NAME      URL                                   CREDENTIAL   INTERVAL   AVAILABLE   LASTSYNCEDAT
default   nfs://172.29.9.51:/var/lib/k8s/data                5m0s       true        2022-02-24T14:16:09Z

2、ReadWriteMany

Longhorn 可以通过 NFSv4 服务器暴露 Longhorn 卷，原生支持 RWX 工作负载，使用的 RWX 卷会在 longhorn-system 命名空间下面创建一个 share-manager-<volume-name> 的 Pod，该 Pod 负责通过在 Pod 内运行的 NFSv4 服务器暴露 Longhorn 卷。

当然一般块存储是不支持rwx的，但文件系统例如nfs是支持的；

RWX

📍 案例演示：LongHorn的RWX功能测试(测试成功)

🍀 要能够使用 RWX 卷，每个客户端节点都需要安装 NFSv4 客户端，对于 Ubuntu，可以通过以下方式安装 NFSv4 客户端：

➜ apt install nfs-common

对于基于 RPM 的发行版，可以通过以下方式安装 NFSv4 客户端：

➜ yum install nfs-utils

这个软包我们前面已经安装过了。

🍀 现在我们来创建一个如下所示的 PVC 对象，访问模式配置为 ReadWriteMany：

# 01-html-vol.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: html
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: longhorn
  resources:
    requests:
      storage: 1Gi

直接创建上面的资源对象就会动态创建一个 PV 与之绑定：

$ kubectl apply -f 01-html-vol.yaml 
persistentvolumeclaim/html created


[root@master1 ~]#kubectl get pvc html
NAME   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
html   Bound    pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f   1Gi        RWX            longhorn       38s
[root@master1 ~]#kubectl get pv pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM          STORAGECLASS   REASON   AGE    
pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f   1Gi        RWX            Delete           Bound    default/html   longhorn                61s

🍀 然后创建一个如下所示的名为 writer 的 Deployment 资源对象，使用上面创建的 PVC 来持久化数据：

# 02-html-writer.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: writer
spec:
  selector:
    matchLabels:
      app: writer
  template:
    metadata:
      labels:
        app: writer
    spec:
      containers:
      - name: content
        image: alpine:latest
        volumeMounts:
        - name: html
          mountPath: /html
        command: ["/bin/sh", "-c"]
        args:
        - while true; do
          date >> /html/index.html;
          sleep 5;
          done
      volumes:
      - name: html
        persistentVolumeClaim:
          claimName: html

🍀 部署后上面创建的 Longhorn 的卷就变成 Attached 状态了：

$ kubectl apply -f 02-html-writer.yaml 
deployment.apps/writer created

并且这个时候会自动启动一个 share-manager 的 Pod，通过该 Pod 内运行的 NFSv4 服务器来暴露 Longhorn 卷：

[root@master1 ~]#kubectl get pods -n longhorn-system -l longhorn.io/component=share-manager
NAME                                                     READY   STATUS    RESTARTS   AGE
share-manager-pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f   1/1     Running   0          6m1s

[root@master1 ~]#kubectl logs -f share-manager-pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f -nlonghorn-system
time="2022-02-25T06:07:26Z" level=info msg="starting RLIMIT_NOFILE rlimit.Cur 65536, rlimit.Max 65536"
time="2022-02-25T06:07:26Z" level=info msg="ending RLIMIT_NOFILE rlimit.Cur 1048576, rlimit.Max 1048576"
time="2022-02-25T06:07:28Z" level=debug msg="volume pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f device /dev/longhorn/pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f contains filesystem of format " encrypted=false volume=pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f
I0225 06:07:34.943294       1 mount_linux.go:425] Disk "/dev/longhorn/pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f" appears to be unformatted, attempting to format as type: "ext4" with options: [-F -m0 /dev/longhorn/pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f]
I0225 06:08:01.740766       1 mount_linux.go:435] Disk successfully formatted (mkfs): ext4 - /dev/longhorn/pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f /export/pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f
time="2022-02-25T06:08:03Z" level=info msg="starting nfs server, volume is ready for export" encrypted=false volume=pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f
time="2022-02-25T06:08:03Z" level=info msg="starting health check for volume" encrypted=false volume=pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7ftime="2022-02-25T06:08:03Z" level=info msg="Running NFS server!"

🍀 然后我们再创建一个如下所示的 Deployment：

# 03-html-reader.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: reader
spec:
  replicas: 3
  selector:
    matchLabels:
      app: reader
  template:
    metadata:
      labels:
        app: reader
    spec:
      containers:
      - name: nginx
        image: nginx:stable-alpine
        ports:
        - containerPort: 80
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      volumes:
      - name: html
        persistentVolumeClaim:
          claimName: html
---
apiVersion: v1
kind: Service
metadata:
  name: reader
spec:
  selector:
    app: reader
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

上面的 reader Pods 可以引用 writer Pod 相同的 PVC，是因为上面我们创建的 PV 和 PVC 是 ReadWriteMany 访问模式。

🍀 直接创建上面的资源对象，我们可以通过 NodePort 来访问应用：

$ kubectl apply -f 03-html-reader.yaml 
deployment.apps/reader created
service/reader created

[root@master1 ~]#kubectl get pods -l app=reader
NAME                     READY   STATUS    RESTARTS   AGE
reader-7b44f6f6c-bkb4b   1/1     Running   0          71s
reader-7b44f6f6c-llrnq   1/1     Running   0          71s
reader-7b44f6f6c-sgnds   1/1     Running   0          71s
[root@master1 ~]#kubectl get svc reader
NAME     TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE 
reader   NodePort   10.100.245.39   <none>        80:30234/TCP   106s


[root@master1 ~]#curl 172.29.9.51:30234
......
Fri Feb 25 06:16:15 UTC 2022
Fri Feb 25 06:16:20 UTC 2022
Fri Feb 25 06:16:35 UTC 2022
Fri Feb 25 06:16:40 UTC 2022
Fri Feb 25 06:16:46 UTC 2022
......

🍀 现在我们尝试从一个 reader Pod 中去产生一些数据，然后再去访问应用验证数据是否正确：

[root@master1 ~]#kubectl exec reader-7b44f6f6c-sgnds  -- /bin/sh -c "echo longhorn rwx access mode >> /usr/share/nginx/html/index.html"

[root@master1 ~]#curl 172.29.9.51:30234
......
Fri Feb 25 06:18:56 UTC 2022
Fri Feb 25 06:19:04 UTC 2022
Fri Feb 25 06:19:24 UTC 2022
longhorn rwx access mode
Fri Feb 25 06:19:30 UTC 2022
Fri Feb 25 06:19:35 UTC 2022
......

这里我们就验证了在 Longhorn 中使用 ReadWriteMany 访问模式的 Volume 卷。

QA

📍 注意:`LongHorn Engine`

这个volume engine不是单独作为一个pod运行的，而是作为pod里的某一个进程存在的；

📍 LongHorn的RWX使用场景：wordpress

关于我

我的博客主旨：我希望每一个人拿着我的博客都可以做出实验现象，先把实验做出来，然后再结合理论知识更深层次去理解技术点，这样学习起来才有乐趣和动力。并且，我的博客内容步骤是很完整的，也分享源码和实验用到的软件，希望能和大家一起共同进步！

各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人免费帮您解决问题：

个人微信二维码：x2675263825 （舍得）， qq：2675263825。
个人博客地址：www.onlyonexl.cn
个人微信公众号：云原生架构师实战
个人csdn

https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

个人已开源干货😘

名称	链接
01 实战：打造一款王者云笔记：typora+坚果云+阿里云oss	https://www.jianguoyun.com/p/DXS6qiIQvPWVCRiS0qoE
02 实战：定制宇宙中最美的typora主题皮肤	https://www.jianguoyun.com/p/DeUK9u0QvPWVCRib0qoE
03 玩转vscode	https://www.jianguoyun.com/p/DZe8gmsQvPWVCRid0qoE
04 陈果的幸福哲学课	https://www.jianguoyun.com/p/Db0kM7gQvPWVCRj2q6YE

最后

好了，关于Longhorn备份恢复实验就到这里了，感谢大家阅读，最后贴上我女神的photo，祝大家生活快乐，每天都过的有意义哦，我们下期见！

一念一生～one

关注

1
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
实战：k8s之Longhorn备份恢复-2022.2.26

目录文章目录目录实验环境实验软件1、备份恢复📍 案例演示：longhorn备份恢复(成功测试)1️⃣ 手动快照2️⃣ 周期性快照和备份3️⃣ 使用 Kubernetes 的 StorageClass 来配置定时快照4️⃣ 使用备份卷2、ReadWriteMany📍 案例演示：LongHorn的RWX功能测试(测试成功)QA📍 注意:`LongHorn Engine`📍 LongHorn的RWX使用场景：wordpress关于我最后实验环境实验环境：1、win10,vmwrokstation虚机；.
复制链接

扫一扫