k8s 分布式存储平台 -- Longhorn

一、什么是 Longhorn

Longhorn官网

Longhorn 是针对 Kubernetes 的轻量级、可靠且易于使用的分布式块存储系统。

Longhorn 是一款免费的开源软件。它最初由 Rancher Labs 开发，目前正作为云原生计算基金会的孵化项目进行开发。

使用 Longhorn，可以：

• 使用 Longhorn 卷作为 Kubernetes 集群中分布式有状态应用程序的持久存储
• 将块存储分区为 Longhorn 卷，这样无论是否有云提供商，都可以使用 Kubernetes 卷
• 跨多个节点和数据中心复制块存储以提高可用性
• 将备份数据存储在外部存储中，例如 NFS 或 AWS S3
• 创建跨集群灾难恢复卷，以便可以从第二个 Kubernetes 集群的备份中快速恢复主 Kubernetes 集群的数据
• 安排卷的定期快照，并安排定期备份到 NFS 或 S3 兼容的辅助存储
• 从备份恢复卷
• 在不破坏持久卷的情况下升级 Longhorn

Longhorn 带有独立的 UI，可以使用 Helm、kubectl 或 Rancher 应用程序目录进行安装。

二、架构设计

Longhorn 设计有两层：数据平面和控制平面。Longhorn Engine 是存储控制器，对应数据平面，Longhorn Manager 对应控制平面。

1、工作原理

Longhorn Manager Pod 作为 Kubernetes DaemonSet在 Longhorn 集群中的每个节点上运行。它负责在 Kubernetes 集群中创建和管理卷，并处理来自 UI 或 Kubernetes 卷插件的 API 调用。它遵循 Kubernetes 控制器模式，有时也称为操作员模式。

Longhorn Manager 与 Kubernetes API 服务器通信以创建一个新的 Longhorn 卷CR。然后 Longhorn Manager 监视 API 服务器的响应，当它看到 Kubernetes API 服务器创建了新的 Longhorn 卷 CR 时，Longhorn Manager 就会创建一个新的卷。

当 Longhorn Manager 被要求创建卷时，它会在卷所连接的节点上创建一个 Longhorn Engine 实例，并在将要放置副本的每个节点上创建一个副本。副本应放置在单独的主机上以确保最大可用性。

副本的多条数据路径保证了 Longhorn 卷的高可用性，即使某个副本或者 Engine 出现问题，也不会影响所有副本或者 Pod 对卷的访问，Pod 依然可以正常运行。

Longhorn Engine 始终与使用 Longhorn 卷的 Pod 运行在同一个节点上。它会在存储在多个节点上的多个副本之间同步复制该卷。

引擎和副本使用 Kubernetes 进行编排。

2、工作流程

Longhorn 引擎、副本实例和磁盘之间的读/写数据流

下图所示

• 有三个具有 Longhorn 卷的实例。
• 每个卷都有一个专用的控制器，称为 Longhorn Engine，作为 Linux 进程运行。
• 每个 Longhorn 卷都有两个副本，每个副本都是一个 Linux 进程。
• 图中的箭头表示卷、控制器实例、副本实例和磁盘之间的读写数据流。
• 通过为每个卷创建一个单独的 Longhorn Engine，如果一个控制器出现故障，其他卷的功能不会受到影响。

3、基于微服务设计的优势

在 Longhorn 中，每个 Engine 只需服务一个卷，从而简化了存储控制器的设计。由于控制器软件的故障域被隔离到各个卷，因此控制器崩溃只会影响一个卷。

Longhorn 引擎足够简单和轻量，因此我们可以创建多达 100,000 个独立引擎。Kubernetes 调度这些独立引擎，从一组共享磁盘中提取资源，并与 Longhorn 一起形成一个弹性分布式块存储系统。

由于每个卷都有自己的控制器，因此每个卷的控制器和副本实例也可以升级，而不会导致 IO 操作明显中断。

Longhorn 可以创建一个长期运行的作业来协调所有活动卷的升级，而不会中断系统的持续运行。为了确保升级不会导致不可预见的问题，Longhorn 可以选择升级一小部分卷，如果升级过程中出现问题，则回滚到旧版本。

三、安装

1、安装要求

安装 Longhorn 的 Kubernetes 集群中的每个节点都必须满足以下要求：

• 与 Kubernetes 兼容的容器运行时（Docker v1.13+、containerd v1.3.7+ 等）

• Kubernetes >= v1.21

• open-iscsi 已安装，并且iscsid 守护程序在所有节点上运行。Longhorn 依赖于 iscsiadm 主机为 Kubernetes 提供持久卷。

• RWX 支持要求每个节点都安装 NFSv4 客户端。

• 主机文件系统支持file extents存储数据的功能。目前支持：

  • ext4
  • XFS

• bash，curl，findmnt，grep，awk，blkid，lsblk 必须安装。

• Mount propagation 必须启用，它允许将一个容器挂载的卷与同一 pod 中的其他容器共享，甚至可以与同一节点上的其他 pod 共享

  • Mount propagation

为了正确部署和运行 Longhorn，Longhorn 工作负载必须能够以 root 身份运行。

2、使用 Longhorn 命令行工具（验证方式一）

该 longhornctl 工具是用于 Longhorn 操作的 CLI。要检查先决条件和配置，请下载该工具并运行 check 子命令：

# For AMD64 platform
curl -sSfL -o longhornctl https://github.com/longhorn/cli/releases/download/v1.7.1/longhornctl-linux-amd64
# For ARM platform
curl -sSfL -o longhornctl https://github.com/longhorn/cli/releases/download/v1.7.1/longhornctl-linux-arm64

chmod +x longhornctl
./longhornctl check preflight

3、使用环境检查脚本（验证方式之二）

自 Longhorn v1.7.0 以来，引入了Longhorn 命令行工具。环境检查脚本environment_check.sh的功能与 Longhorn 命令行工具的功能重叠。因此，该脚本已在 v1.7.0 中弃用，并计划在 v1.8.0 中删除。

3.1、安装 jq

jq ，在运行环境检查脚本之前可能需要在本地安装。

yum install -y jq

3.2、运行脚本

curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.7.1/scripts/environment_check.sh | bash

4、安装 open-iscsi

4.1、SUSE 和 openSUSE

zypper install open-iscsi
systemctl enable iscsid
systemctl start iscsid

4.2、Debian 和 Ubuntu

apt-get install open-iscsi

4.3、RHEL、CentOS 和 EKS （带有 AmazonLinux2 映像的 EKS Kubernetes Worker AMI）

yum --setopt=tsflags=noscripts install iscsi-initiator-utils
echo "InitiatorName=$(/sbin/iscsi-iname)" > /etc/iscsi/initiatorname.iscsi
systemctl enable iscsid
systemctl start iscsid

4.4、open-iscsi 安装程序

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.1/deploy/prerequisite/longhorn-iscsi-installation.yaml

# 检查安装程序的 pod 状态
kubectl get pod | grep longhorn-iscsi-installation

5、安装 NFSv4 客户端

在 Longhorn 系统中，备份功能需要 NFSv4、v4.1 或 v4.2，而 ReadWriteMany (RWX) 卷功能需要 NFSv4.1。在安装 NFSv4 客户端用户空间守护程序和实用程序之前，请确保在每个 Longhorn 节点上都启用了客户端内核支持。

• 检查NFSv4.1内核是否启用了支持

cat /boot/config-`uname -r`| grep CONFIG_NFS_V4_1

• 检查NFSv4.2内核是否启用了支持

cat /boot/config-`uname -r`| grep CONFIG_NFS_V4_2

5.1、Debian 和 Ubuntu

apt-get install nfs-common

5.2、对于 RHEL、CentOS 和 EKS （EKS Kubernetes Worker AMI with AmazonLinux2 image）

yum install -y nfs-utils

5.3、SUSE/OpenSUSE

zypper install nfs-client

5.4、nfs 安装程序

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.1/deploy/prerequisite/longhorn-nfs-installation.yaml

# 检查安装程序的 pod 状态
kubectl get pod | grep longhorn-nfs-installation

6、检查 Kubernetes 版本

kubectl version --short

应该Server Version是> = v1.21。

7、安装 Cryptsetup 和 LUKS

7.1、Debian 和 Ubuntu

apt-get install cryptsetup

apt-get install dmsetup

7.2、RHEL、CentOS、Rocky Linux 和 EKS（EKS Kubernetes Worker AMI with AmazonLinux2 image）

yum install -y cryptsetup

yum install -y device-mapper

7.3、SUSE/OpenSUSE

zypper install cryptsetup

zypper install device-mapper

8、验证

curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.7.1/scripts/environment_check.sh | bash

9、【ERROR】kernel module iscsi_tcp is not enabled on k8s-node1/2

9.1、解决方案

# 将iscsi_tcp模块加载到内核中
modprobe iscsi_tcp

# 验证模块是否成功加载
lsmod | grep iscsi_tcp

再次重新运行检查脚本应该就没有问题了

四、部署

• Rancher catalog app
• kubectl
• Helm
• Fleet
• Flux
• ArgoCD

我们使用 helm 部署

1、添加 Longhorn Helm 存储库

helm repo add longhorn https://charts.longhorn.io

helm repo update

2、helm 安装 1.7.1 版本的 longhorn

helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --version 1.7.1

3、查看应用 pod 状态

kubectl get pods -n longhorn-system

• csi-attacher-xxx、csi-provisioner-xxx、csi-resizer-xxx、csi-snapshotter-xxx 是 csi 原生的组件
• longhorn-manager-xxx 是运行在每个节点上的 Longhorn Manager，是一个控制器，也为 Longhorn UI 或者 CSI 插件提供 API，主要功能是通过修改 Kubernetes CRD 来触发控制循环，比如 volume attach/detach 操作
• longhorn-ui-xxx 提供 Longhorn UI 服务，提供一个可视化的控制页面
• Longhorn Engine 数据平面，提供两种工作模式：Engine Mode（instance-manager-e-xxx 的 Pod）、Replica Mode（instance-manager-r-xxx 的 Pod），Replica 负责实际数据的写入，每个副本包含数据的完整副本，Engine 连接到副本实现 volume 的数据平面，任何写操作都会同步到所有副本，读操作从任意一个副本读取数据

4、开启 UI

直接使用 NodePort 开放 longhorn UI 服务

4.1、编辑使用 NodePort 类型的 svc 资源清单

cat >> longhorn-ui-svc.yaml << EOF
kind: Service
apiVersion: v1
metadata:
  name: longhorn-ui-nodeport
  namespace: longhorn-system
  labels:
    app: longhorn-ui
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: http
      nodePort: 32222
  selector:
    app: longhorn-ui
  clusterIP: 
  type: NodePort
EOF

4.2、创建 SVC

kubectl apply -f longhorn-ui-svc.yaml

4.3、访问 Longhorn UI

打开浏览器访问，http://集群任意节点IP:32222

http://192.168.112.10:32222

Longhorn UI 界面中展示了当前存储系统的状态。

关于存储的几种状态：

• Schedulable: 可用于 Longhorn 卷调度的实际空间(actual space)
• Reserved: 为其他应用程序和系统保留的空间(space reserved)
• Used: Longhorn、系统和其他应用程序已使用的实际空间(space reserved)
• Disabled: 不允许调度 Longhorn 卷的磁盘/节点的总空间

在 Node 页面，Longhorn 会显示每个节点的空间分配、调度和使用信息：

• Size 列：Longhorn 卷可以使用的最大实际可用空间，它等于节点的总磁盘空间减去保留空间。
• Allocated 列：左边的数字是**卷调度(volume scheduling)**已使用的大小，并不代表该空间已被用于 Longhorn 卷数据存储。右边的数字是卷调度的 max 大小，它是 Size 乘以 Storage Over Provisioning Percentage 的结果，因此，这两个数字之间的差异（我们称之为可分配空间 allocable space）决定了卷副本是否可以调度到这个节点。
• Used 列：左边部分表示该节点当前使用的空间，整个条形表示节点的总空间。

5、查看默认创建的存储类 StorageClass

kubectl get sc longhorn

kubectl get sc longhorn -o yaml

五、使用 Longhorn 为 MySQL 应用提供数据持久化

1、创建 PVC 测试使用 longhorn 动态创建 PV

cat >> mysql-pvc.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  storageClassName: longhorn
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi
EOF

2、部署一个 MySQL 应用来使用上面的 PVC 进行数据持久化

cat >> mysql-deploy.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - image: mysql:5.6
          name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: password
          ports:
            - containerPort: 3306
              name: mysql
          volumeMounts:
            - name: data
              mountPath: /var/lib/mysql
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: mysql-pvc
EOF

3、创建上面的 PVC、Deployment

kubectl apply -f mysql-pvc.yaml -f mysql-deploy.yaml

kubectl get pods -l app=mysql

kubectl get pvc -o wide

kubectl get pv -owide

4、进入容器内部创建数据

kubectl exec -it mysql-56f4797d-76hz2 -- mysql -uroot -ppassword

show databases;

create database longhorn;

show databases;

5、登录到 Pod 所在节点验证数据是否存在

我的测试 pod 调度到 k8s-node1

ls /var/lib/longhorn/

ls /var/lib/longhorn/replicas/

ls pvc-4b35bd04-a6ff-45d4-8701-7f6ab934a896-dd42df6b

1. volume-head-000.img：
   • 这个文件是当前活动的数据文件，包含了最新的数据快照。在 Longhorn 中，卷的数据是以快照形式存在的，每次数据更新都会创建一个新的快照。volume-head-000.img 指的是最新一次的快照数据文件，通常这个文件名会随着快照版本号的增加而改变，但是在某些情况下，它可能是固定的名称，代表当前正在读写的数据。
2. volume-head-000.img.meta：
   • 这是快照的元数据文件，它包含了与 volume-head-000.img 相关的信息，比如文件的大小、快照的时间戳等。
3. volume.meta：
   • 这是一个包含了整个卷的元数据信息的文件，包括卷的大小、快照列表等。volume.meta 文件记录了卷的所有状态信息。

6、重建 Pod 查看数据是否依然存在

kubectl get pods -l app=mysql -owide

kubectl delete po mysql-56f4797d-76hz2

kubectl exec -it mysql-56f4797d-fxxcp -- mysql -uroot -ppassword

可以看到上一个被销毁的 Pod 创建的数据库依然存在，说明数据持久化成功

7、【ERROR】Scheduling Failure Replica Scheduling Failure Error Message: replica scheduling failed

7.1、原因

默认 Longhorn 的 StorageClass 的副本数 replica 设置为 3

这意味着 Longhorn 将始终尝试在三个不同的节点上为三个副本分配足够的空间，如果不满足此要求比如集群的节点数少于3个，则卷调度会失败

kubectl get sc longhorn -o yaml

kubectl get nodes

# 应该是这样的关系
numberOfReplicas <= nodes

7.2、解决方案

• 设置Node Level Soft Anti-affinity为true。
• 或者，创建一个新的 StorageClass，并将副本数设置为1或2。
• 或者，向集群添加更多节点。

kubectl -n longhorn-system edit cm longhorn-storageclass

7.3、再次动态创建 PV 持久卷

没有问题

六、使用 Longhorn 备份恢复

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

在 Longhorn UI 的 Volume 页面中点击要创建快照的卷，进入卷的详细信息页面，点击下方的 Take Snapshot 按钮即可创建快照了，创建快照后，将在卷头(Volume Head)之前的快照列表中可以看到它。

1、对测试的 MySQL 卷创建快照

2、查看 Pod 的调度节点数据目录

同样在节点的数据目录下面也可以看到创建的快照数据：

k8s-node1

其中的 volume-snap-xxx 后面的数据和页面上的快照名称是一致的，比如页面中我们刚刚创建的快照名称为 988f587a-c765-441b-9c7b-c5bae5a113a4，其中的 .img 文件是镜像文件，而 .img.meta 是保存当前快照的元信息：

cat volume-snap-988f587a-c765-441b-9c7b-c5bae5a113a4.img.meta

{"Name":"volume-head-000.img","Parent":"","Removed":false,"UserCreated":true,"Created":"2024-09-26T12:10:35Z","Labels":null}

3、创建周期任务 Create Recurring Job

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

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

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

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

4、使用 Longhorn 的 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
    }
  ]'

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

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

5、创建 RecurringJob 以创建重复快照和备份（重复作业）

apiVersion: longhorn.io/v1beta1
kind: RecurringJob
metadata:
  name: snapshot-1
  namespace: longhorn-system
spec:
  cron: "* * * * *"
  task: "snapshot"
  groups:
  - default
  - group1
  retain: 1
  concurrency: 2
  labels:
    label/1: a
    label/2: b

5.1、配置参数

• name： 循环任务的名称，请勿使用重复的名称，且长度name不超过40个字符。

• task： 工作类型。Longhorn 支持以下内容：

  • backup： 定期创建快照，然后在清理过期快照后进行备份

  • backup-force-create： 定期创建快照并进行备份

  • snapshot： 定期清理过期快照后创建快照

  • snapshot-force-create： 定期创建快照

  • snapshot-cleanup： 定期清除可移动快照和系统快照

    • 注意：保留值对此任务没有影响，Longhorn 会自动将该retain值更改为 0。

  • filesystem-trim： 定期修剪文件系统以回收磁盘空间

  • snapshot-delete： 定期删除并清除所有超出保留计数的快照。

注意：该retain值与每个重复作业无关。

以具有 2 个重复作业的卷为例：

• snapshot保留值设置为 5
• snapshot-delete：保留值设置为 2
• 最终一次任务执行完成后会保留2个快照snapshot-delete。

• cron： Cron表达式。它告诉作业的执行时间。
• retain： Longhorn 将为每个卷作业保留多少个快照/备份。它不应少于 1。
• concurrency： 同时运行的作业数，不小于1。

可以指定可选参数：

• groups： 作业应属于的任何组。归入default组将自动将此重复作业安排到没有重复作业的任何卷。
• labels： 应应用于备份或快照的任何标签。

6、备份卷

要想使用 Longhorn 的备份卷功能就需要配置应该备份目标，可以是一个 NFS 服务或是 S3 兼容的对象存储服务，用于存储 Longhorn 卷的备份数据。

备份目标可以在 Settings/General/BackupTarget 中配置，最好的方式是定制 values 文件中的 defaultSettings.backupTarget(也是网上大部分教程使用的方式)，也可以在 Longhorn UI 中配置

6.1、配置备份目标为 NFS 服务以备份卷

比如这里我们先配置备份目标为 nfs 服务，Backup Target 值设置为 nfs://192.168.112.30:/var/lib/k8s/data（要确保目录存在），Backup Target Credential Secret 留空即可，然后拉到最下面点击 Save：

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

6.2、【ERROR】为什么设置了备份目标 BackupTarget 选择卷 Create Backup选项是不可选的呢？

6.2.1、原因

NFS 配置问题，我们前面只安装了 NFS 服务并启动并开机自启但是并未配置服务，因此 Longhorn 将卷无法挂载到指定的 NFS 服务器的共享目录

6.2.2、解决方案

配置 NFS 服务器

mkdir -pv /var/lib/k8s/data

echo "/var/lib/k8s/data 192.168.112.0/24(rw,sync,no_root_squash)" > /etc/exports

exportfs -arv

systemctl restart nfs

showmount -e localhost

6.2.3、验证

kubectl get backuptargets -n longhorn-system

6.3、查看对应备份数据

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

6.4、backupvolumes 对象

kubectl get backupvolumes -n longhorn-system

6.5、查看 NFS 服务器上备份的数据

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

tree -L 6 /var/lib/k8s/data/backupstore

6.6、选择需要备份的快照

6.7、基于备份数据恢复数据

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

七、ReadWriteMany 卷的使用

Longhorn 可以通过 NFSv4 服务器暴露 Longhorn 卷，原生支持 RWX 工作负载。

Longhorn 在命名空间 longhorn-system 内为当前正在使用的每个 RWX 卷创建一个专用的share-manager- Pod。该 Pod 有助于通过内部托管的 NFSv4 服务器导出 Longhorn 卷。此外，还为每个 RWX 卷创建相应的服务，作为实际 NFSv4 客户端连接的指定端点。

1、创建访问模式为 RWX 的 PVC

cat >> html-vol.yaml << EOF
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: html
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: longhorn
  resources:
    requests:
      storage: 1Gi
EOF

kubectl apply -f html-vol.yaml

会发现刚创建的 PVC 就会有 PV 动态生成并绑定了

2、创建 Deployment 使用上面创建的 PVC 做持久化数据

cat >> html-writer.yaml << EOF
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
EOF

kubectl apply -f html-writer.yaml

3、查看 share-manager 的 Pod 日志信息

kubectl get pods -n longhorn-system -l longhorn.io/component=share-manager

kubectl logs -f share-manager-pvc-1b1fb90b-a4e0-4551-85b1-9ec95c03d0e4 -n longhorn-system

4、创建一个用来读取数据的 Pod

cat >> html-reader.yaml << EOF
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:1.16.0
          ports:
            - containerPort: 80
          volumeMounts:
            - name
						

							上一篇：							
								婚恋交友小程序的设计理念和用户体验优化							
						
						

							下一篇：							
								2024 年主流前端框架比较与选择指南