如果你正在運行K8s，其中最大的難題之一是如何為k8s集群選擇正確的存儲技術，你可能會考慮使用通過動態(tài)預配置的塊存儲卷。實際上，這很大程度上取決于您要運行的工作負載的類型。本篇文章的目標主要是評估K8s可用的最常見的存儲解決方案，并進行基本性能測試。

目前CNCF的存儲格局和解決方案已經(jīng)更新，它已從2019年的30個解決方案增長到目前的45個解決方案，還進行了公共云集成的管理擴展，例如AWS EBS，Google永久磁盤或Azure磁盤存儲。一些新解決方案像Alluxio一樣，更側重于分布式文件系統(tǒng)或對象存儲。

本文的目標是采用K8s可用的最常見的存儲解決方案，并準備基本的性能比較。文章使用以下后端在Azure AKS上執(zhí)行所有測試：

• AKS native storage class — Azure native premium

• AWS cloud volume mapped into instance — Azure hostPath with attached Azure managed disk

• OpenEBS with cStor backend

• OpenEBS MayaStor

• Portworx

• Gluster managed by Heketi

• Ceph managed by Rook

• Longhorn

相比于19年的存儲方案，GlusterFS Heketi在性能結果上排名倒數(shù)第二，它的改進為零，并且大多數(shù)情況下是一個沉寂的項目（Heketi作為REST協(xié)調器而不是GlusterFS本身）。如果查看它們的官方GitHub，您會發(fā)現(xiàn)他們近乎將其置于維護模式，并且云本地存儲功能沒有任何更新。

另外根據(jù)GIGAOM 2020報告， PortWorx仍然是K8s的頂級商業(yè)存儲解決方案。但是，從性能的角度來看，版本2.0和2.5之間的發(fā)行說明中并沒有重大的技術或體系結構更改。最好的開源存儲，是通過Rook精心策劃的CEPH，他發(fā)布了2個新版本，并推出了一個新的CEPH版本，稱為Octopus。Octopus對緩存機制進行了一些優(yōu)化，并使用了更現(xiàn)代的內核接口。今年唯一的主要體系結構更改發(fā)生在OpenEBS中，它引入了一個稱為MayaStor的新后端。這個后端看起來非常有前途。這些k8s常用的解決方案性能到底怎么樣了？我們一起來看下。

本機Azure存儲

之所以選擇該存儲類，是為了獲得所有測試的基準。此存儲類應提供最佳性能。Azure動態(tài)創(chuàng)建托管磁盤，并將其映射到具有k8s作為Pod卷的VM。

無需使用任何特殊功能。當您配置新的AKS群集時，將自動預定義2個存儲類，分別稱為“默認”和“高級托管”。高級類對卷使用基于SSD的高性能和低延遲磁盤。

優(yōu)點

• AKS上的默認設置無需執(zhí)行任何操作。

缺點

• 故障轉移情況下非常慢，有時需要將近10分鐘才能將卷重新連接到其他節(jié)點上的Pod。

$ kubectl get storageclassesNAME                PROVISIONER                AGEdefault (default)   kubernetes.io/azure-disk   8mmanaged-premium     kubernetes.io/azure-disk   8m
$ kubectl get pvcNAME              STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGEdbench-pv-claim   Bound     pvc-e7bd34a4-1dbd-11e9-8726-ae508476e8ad   1000Gi     RWO            managed-premium   10s
$ kubectl get poNAME           READY     STATUS              RESTARTS   AGEdbench-w7nqf0/1ContainerCreating029s

OpenEBS

OpenEBS代表了新的容器附加存儲（CAS）概念，其中是單個基于微服務的存儲控制器和多個基于微服務的存儲副本。它與Portworx一起屬于云本機存儲類別。

它是完全開源的，目前提供2個后端，分別是Jiva和cStor。我從Jiva開始，然后切換到cStor。cStor進行了一些改進，因為控制器及其副本部署在單個名稱空間（安裝openebs的名稱空間）中，或者它使用原始磁盤而不是格式化分區(qū)。每個k8s卷都有其自己的存儲控制器，該存儲可以在節(jié)點上可用存儲容量的允許范圍內進行擴展。

如何在AKS上獲取它？在AKS上安裝其實非常容易。

1.我必須連接到所有k8s節(jié)點的控制臺并安裝iSCSI，因為它使用iSCSI協(xié)議在Pod和存儲控制器與k8s節(jié)點之間進行連接。

apt-get updateapt install -y open-iscsi

2.然后，我將單個YAML定義應用于我的k8s集群

kubectl apply -f https://openebs.github.io/charts/openebs-operator-0.8.0.yaml

3.下一步，OpenEBS控制器在底層節(jié)點發(fā)現(xiàn)了我所有的磁盤。但是我必須手動確定附加的AWS托管磁盤。

kubectl get diskNAME                                      AGEdisk-184d99015253054c48c4aa3f17d137b1     5mdisk-2f6bced7ba9b2be230ca5138fd0b07f1     5mdisk-806d3e77dd2e38f188fdaf9c46020bdc     5m

4.然后，將這些磁盤添加到標準StorageClass引用的自定義k8s資源StoragePoolClaim中。

---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:  name: openebs-custom  annotations:    openebs.io/cas-type: cstor    cas.openebs.io/config: |      - name: StoragePoolClaim        value: "cstor-disk"provisioner: openebs.io/provisioner-iscsi---apiVersion: openebs.io/v1alpha1kind: StoragePoolClaimmetadata:  name: cstor-diskspec:  name: cstor-disk  type: disk  maxPools: 3  poolSpec:    poolType: striped  disks:    diskList:    - disk-2f6bced7ba9b2be230ca5138fd0b07f1    - disk-806d3e77dd2e38f188fdaf9c46020bdc    - disk-184d99015253054c48c4aa3f17d137b1

完成這些步驟后，我便能夠通過k8s PVC動態(tài)配置新卷。

優(yōu)點

• 開源的

• Maya在資源使用可視化方面做得很好。您可以輕松地在k8s集群中部署多個服務，并輕松設置監(jiān)視和日志記錄以收集集群的所有重要方面。這是調試的理想工具。

• 總的來說，CAS概念–我非常喜歡容器存儲背后的想法，并且我相信會有未來。

• OpenEBS背后的社區(qū)—我能夠在幾分鐘內解決任何問題。Slack上的團隊非常有幫助。

缺點

• 不成熟-OpenEBS是一個相當新的項目，尚未達到穩(wěn)定版本。核心團隊仍在進行后端優(yōu)化，這將在接下來的幾個月中顯著提高性能。

• Kubelet和存儲控制器之間的iSCSI連接由k8s服務實現(xiàn)，這在某些覆蓋網(wǎng)絡CNI插件（例如Tungsten Fabric）中可能是一個問題。

• 需要在Kubernetes節(jié)點上安裝其他軟件（iSCSI），這使其在托管Kubernetes集群的情況下不切實際。

注意：OpenEBS團隊在文檔中調整了相關的測試用例場景

https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench

Portworx

Portworx是為k8s設計的另一種容器本機存儲，專注于高度分布式的環(huán)境。它是一個主機可尋址的存儲，其中每個卷都直接映射到其連接的主機。它提供基于應用程序I/O類型的自動調整。那里有更多信息。不幸的是，它是本篇文章中唯一的不開源的存儲解決方案。但是，它免費提供3個節(jié)點試用版。

如何在AKS上安裝它？在AKS上安裝也非常容易。我使用了可在其網(wǎng)站上找到的Kubernetes spec生成器。

1.首選，我選擇了Portworx托管的etcd來簡化設置，并填充了k8s 1.11.4版本。

2.我必須將數(shù)據(jù)網(wǎng)絡接口修改為azure0，因為我使用的是具有高級聯(lián)網(wǎng)功能的Azure cni。否則，Portworx將使用來自docker bridge的IP地址而不是VM接口。

3.最后一步，網(wǎng)站生成器向我提供了渲染的k8s YAML清單以應用于我的集群。

4.引導后，我在每個k8s節(jié)點上運行了Portworx Pod

root@aks-agentpool-20273348-0:~# kubectl get pods -o wide -n kube-system -l name=portworxNAME             READY     STATUS    RESTARTS   AGE       IP          NODE                       NOMINATED NODEportworx-g9csq   1/1       Running   0          14m       10.0.1.66   aks-agentpool-20273348-2   <none>portworx-nt2lq   1/1       Running   0          14m       10.0.1.4    aks-agentpool-20273348-0   <none>portworx-wcjnx   1/1       Running   0          14m       10.0.1.35   aks-agentpool-20273348-1   <none>

我創(chuàng)建了具有高優(yōu)先級和3個副本的Storage Class，然后可以配置k8s pvc。

優(yōu)點

• 易于部署-具有詳細配置的網(wǎng)站配置器。

• AKS集群的配置器，不需要任何其他步驟，如ceph或glusterfs。

• 云原生存儲，它可以在硬件集群和公共云上運行。

• 存儲感知的服務等級（COS）和應用感知的I/O調整

缺點

• 閉源，專有供應商解決方案。

GlusterFS Heketi

GlusterFS是眾所周知的開源存儲解決方案。它沿用Ceph，這是RedHat支持的傳統(tǒng)開源存儲之一。Heketi是用于GlusterFS的RESTful卷管理接口。它提供了一種釋放動態(tài)配置的GlusterFS卷功能的便捷方法。如果沒有此訪問權限，則必須手動創(chuàng)建GlusterFS卷并將其映射到k8s pv。

如何在AKS上安裝它？我使用了默認的Heketi快速入門指南。

1. 首先，我基于示例一創(chuàng)建了一個拓撲文件，其中包含磁盤和主機名。

https://github.com/gluster/gluster-kubernetes/blob/master/deploy/topology.json.sample

2.由于Heketi主要是在基于RHEL的操作系統(tǒng)上開發(fā)和測試的，因此我在使用Ubuntu主機的AKS上遇到了一個問題，該內核路徑錯誤。這是解決此問題的PR。

https://github.com/gluster/gluster-kubernetes/pull/557

+++ b/deploy/kube-templates/glusterfs-daemonset.yaml@@ -67,7 +67,7 @@ spec:           mountPath: "/etc/ssl"           readOnly: true         - name: kernel-modules-          mountPath: "/usr/lib/modules"+          mountPath: "/lib/modules"           readOnly: true         securityContext:           capabilities: {}@@ -131,4 +131,4 @@ spec:           path: "/etc/ssl"       - name: kernel-modules         hostPath:-          path: "/usr/lib/modules"+          path: "/lib/modules"

3.我遇到的AKS的另一個問題是非空磁盤，因此我使用了擦拭來清理glusterfs的磁盤。該磁盤以前沒有用于其他任何用途。

wipefs -a /dev/sdc/dev/sdc: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31

4.最后一步，我運行命令gk-deploy -g -t topology.json，該命令在由heketi控制器控制的每個節(jié)點上部署了glusterfs pod。

root@aks-agentpool-20273348-0:~# kubectl get po -o wideNAME                     READY   STATUS    RESTARTS IP        NODE                       NOMINATED NODEglusterfs-fgc8f          1/1     Running   0       10.0.1.35  aks-agentpool-20273348-1glusterfs-g8ht6          1/1     Running   0       10.0.1.4   aks-agentpool-20273348-0glusterfs-wpzzp          1/1     Running   0       10.0.1.66  aks-agentpool-20273348-2heketi-86f98754c-n8qfb   1/1     Running   0       10.0.1.69  aks-agentpool-20273348-2

然后，我面臨著動態(tài)配置的問題。Heketi restURL對k8s控制平面不可用。我嘗試了kube dns記錄，pod IP和svc IP。兩者都不起作用。因此，我不得不通過Heketi CLI手動創(chuàng)建卷。

root@aks-agentpool-20273348-0:~# export HEKETI_CLI_SERVER=http://10.0.1.69:8080root@aks-agentpool-20273348-0:~# heketi-cli volume create --size=10 --persistent-volume --persistent-volume-endpoint=heketi-storage-endpoints | kubectl create -f -persistentvolume/glusterfs-efb3b155 created
root@aks-agentpool-20273348-0:~# kubectl get pvNAME                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGEglusterfs-efb3b155   10Gi       RWX            Retain           Available                                      19s

然后，必須為我的dbench工具將現(xiàn)有的PV映射到PVC。

kind: PersistentVolumeClaimapiVersion: v1metadata:  name: glusterfs-efb3b155spec:  accessModes:    - ReadWriteMany  storageClassName: ""  resources:    requests:      storage: 10Gi  volumeName: glusterfs-efb3b155
kubectl get pvcNAME                 STATUS    VOLUME               CAPACITY   ACCESS MODES   STORAGECLASS   AGEglusterfs-efb3b155   Bound     glusterfs-efb3b155   10Gi       RWX                           36m

從k8s上的Heketi Gluster安裝獲得更多輸出。

gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849
Volume Name: vol_efb3b15529aa9aba889d7900f0ce9849Type: ReplicateVolume ID: 96fde36b-e389-4dbe-887b-baae32789436Status: StartedSnapshot Count: 0Number of Bricks: 1 x 3 = 3Transport-type: tcpBricks:Brick1: 10.0.1.66:/var/lib/heketi/mounts/vg_5413895eade683e1ca035760c1e0ffd0/brick_cd7c419bc4f4ff38bbc100c6d7b93605/brickBrick2: 10.0.1.35:/var/lib/heketi/mounts/vg_3277c6764dbce56b5a01426088901f6d/brick_6cbd74e9bed4758110c67cfe4d4edb53/brickBrick3: 10.0.1.4:/var/lib/heketi/mounts/vg_29d6152eeafc57a707bef56f091afe44/brick_4856d63b721d794e7a4cbb4a6f048d96/brickOptions Reconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: off
kubectl get svcNAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGEheketi                     ClusterIP   192.168.101.75           8080/TCP   5hheketi-storage-endpoints   ClusterIP   192.168.103.66           1/TCP      5h
root@aks-agentpool-20273348-0:~# kubectl get endpointsNAME                       ENDPOINTS                            AGEheketi                     10.0.1.69:8080                       5hheketi-storage-endpoints   10.0.1.35:1,10.0.1.4:1,10.0.1.66:1   5hkubernetes                 172.31.22.152:443                    1droot@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yamlapiVersion: v1kind: Endpointsmetadata:  creationTimestamp: 2019-01-29T15:14:28Z  name: heketi-storage-endpoints  namespace: default  resourceVersion: "142212"  selfLink: /api/v1/namespaces/default/endpoints/heketi-storage-endpoints  uid: 91f802eb-23d8-11e9-bfcb-a23b1ec87092subsets:- addresses:  - ip: 10.0.1.35  - ip: 10.0.1.4  - ip: 10.0.1.66  ports:  - port: 1    protocol: TCP

優(yōu)點

• 成熟的存儲解決方案

• 比Ceph更輕

缺點

• Heketi不是為公共管理的k8設計的。它與HW群集配合使用，安裝更容易。

• 并非真正為“結構化數(shù)據(jù)”設計的，如SQL數(shù)據(jù)庫。但是，您可以使用Gluster備份和還原數(shù)據(jù)庫。

Ceph Rook

OpenStack私有云常見和Ceph進行搭配。它始終需要設計特定的硬件配置，根據(jù)數(shù)據(jù)類型生成pg組，配置日志SSD分區(qū)（在bluestore之前）并定義Crush Map。因此，當我第一次聽說在3節(jié)點k8s集群中使用Ceph時，我不敢相信它實際上可以工作。但是，Rook編排工具給我留下了深刻的印象，該工具為我完成了所有痛苦的步驟，并且與k8s編排一起提供了一種非常簡單的方法來處理整個存儲集群的安裝。

如何在AKS上安裝它?在默認安裝中，Rook不需要任何特殊步驟，并且如果您不希望使用高級配置，它會非常平滑。

1.我使用了Ceph快速入門指南

https://github.com/rook/rook/blob/master/Documentation/ceph-quickstart.md#ceph-storage-quickstart

2.我必須配置特定于AKS的FLEXVOLUME_DIR_PATH，因為它們使用/etc/kubernetes/volumeplugins/ 而不是默認的Ubuntu /usr/libexec。沒有此更改，kubelet無法安裝pvc 。

diff --git a/cluster/examples/kubernetes/ceph/operator.yaml b/cluster/examples/kubernetes/ceph/operator.yamlindex 73cde2e..33f45c8 100755--- a/cluster/examples/kubernetes/ceph/operator.yaml+++ b/cluster/examples/kubernetes/ceph/operator.yaml@@ -431,8 +431,8 @@ spec:         # - name: AGENT_MOUNT_SECURITY_MODE         #   value: "Any"         # Set the path where the Rook agent can find the flex volumes-        # - name: FLEXVOLUME_DIR_PATH-        #  value: ""+        - name: FLEXVOLUME_DIR_PATH+          value: "/etc/kubernetes/volumeplugins"         # Set the path where kernel modules can be found         # - name: LIB_MODULES_DIR_PATH         #  value: ""

3.然后，我必須指定要在deviceFilter中使用的設備。我的附加磁盤始終位于/dev/sdc上

diff --git a/cluster/examples/kubernetes/ceph/cluster.yaml b/cluster/examples/kubernetes/ceph/cluster.yamlindex 48cfeeb..0c91c48 100755--- a/cluster/examples/kubernetes/ceph/cluster.yaml+++ b/cluster/examples/kubernetes/ceph/cluster.yaml@@ -227,7 +227,7 @@ spec:   storage: # cluster level storage configuration and selection     useAllNodes: true     useAllDevices: false-    deviceFilter:+    deviceFilter: "^sdc"     location:     config:

4.安裝后，我使用以下配置創(chuàng)建了Ceph塊池和存儲類

apiVersion: ceph.rook.io/v1kind: CephBlockPoolmetadata:  name: replicapool  namespace: rook-cephspec:  failureDomain: host  replicated:    size: 3---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:   name: rook-ceph-blockprovisioner: ceph.rook.io/blockparameters:  blockPool: replicapool  clusterNamespace: rook-ceph  fstype: xfsreclaimPolicy: Retain

5。最后，我通過以下部署工具檢查狀態(tài)：https://github.com/rook/rook/blob/master/Documentation/ceph-toolbox.md

ceph status  cluster:    id:     bee70a10-dce1-4725-9285-b9ec5d0c3a5e    health: HEALTH_OK
  services:    mon: 3 daemons, quorum c,b,a    mgr: a(active)    osd: 3 osds: 3 up, 3 in
  data:    pools:   0 pools, 0 pgs    objects: 0  objects, 0 B    usage:   3.0 GiB used, 3.0 TiB / 3.0 TiB avail    pgs:
[root@aks-agentpool-27654233-0 /]#[root@aks-agentpool-27654233-0 /]#[root@aks-agentpool-27654233-0 /]# ceph osd status+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+| id |           host           |  used | avail | wr ops | wr data | rd ops | rd data |   state   |+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+| 0  | aks-agentpool-27654233-0 | 1025M | 1021G |    0   |     0   |    0   |     0   | exists,up || 1  | aks-agentpool-27654233-1 | 1025M | 1021G |    0   |     0   |    0   |     0   | exists,up || 2  | aks-agentpool-27654233-2 | 1025M | 1021G |    0   |     0   |    0   |     0   | exists,up |+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+

優(yōu)點

• 在大型生產(chǎn)環(huán)境中運行的強大存儲

• Rook使生命周期管理變得更加簡單。

缺點

• 復雜且更重，甚至不適合在公共云中運行。最好只在配置正確的硬件群集上運行。
  
  Longhorn

Longhorn是Rancher開發(fā)的用于K8s的云原生分布式塊存儲。它主要是為微服務用例設計的。它為每個塊設備卷創(chuàng)建一個專用的存儲控制器，并跨存儲在多個節(jié)點上的多個副本同步復制該卷。Longhorn在附加了卷的節(jié)點上創(chuàng)建了Longhorn Engine，并在復制了卷的節(jié)點上創(chuàng)建了副本。與其他存儲方案類似，整個控制平面正常運行，而數(shù)據(jù)平面由K8s編排。它是完全開源的。有趣的是，OpenEBS Jiva后端實際上是基于Longhorn的，或者至少最初是基于Longhorn的。主要區(qū)別在于Longhorn使用TCMU Linux驅動程序，而OpenEBS Jiva使用的是gotgt。

如何在AKS上獲取它？當然也可以輕松安裝到AKS，只需要運行一個命令，它將所有組件安裝到我的AKS集群中

$ kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml
$ kubectl -n longhorn-system get poNAME                                        READY   STATUS    RESTARTS   AGEcsi-attacher-7965bb8b59-c4g2c               1/1     Running   0          116scsi-attacher-7965bb8b59-jqk9t               1/1     Running   0          116scsi-attacher-7965bb8b59-qrxl6               1/1     Running   0          116scsi-provisioner-5896666d9b-9lss2            1/1     Running   0          115scsi-provisioner-5896666d9b-v7wwd            1/1     Running   0          115scsi-provisioner-5896666d9b-vsq6v            1/1     Running   0          115scsi-resizer-98674fffd-27wgb                 1/1     Running   0          115scsi-resizer-98674fffd-q6scx                 1/1     Running   0          115scsi-resizer-98674fffd-rr7qc                 1/1     Running   0          115sengine-image-ei-ee18f965-5npvk              1/1     Running   0          2m44sengine-image-ei-ee18f965-9lp7w              1/1     Running   0          2m44sengine-image-ei-ee18f965-h7b4x              1/1     Running   0          2m44sinstance-manager-e-27146777                 1/1     Running   0          2m42sinstance-manager-e-58362831                 1/1     Running   0          2m40sinstance-manager-e-6043871c                 1/1     Running   0          2m43sinstance-manager-r-5cdb90bf                 1/1     Running   0          2m40sinstance-manager-r-cb47162a                 1/1     Running   0          2m41sinstance-manager-r-edd5778b                 1/1     Running   0          2m42slonghorn-csi-plugin-7xzw9                   2/2     Running   0          115slonghorn-csi-plugin-m8cp4                   2/2     Running   0          115slonghorn-csi-plugin-wzgp8                   2/2     Running   0          115slonghorn-driver-deployer-699db744fd-8j6q6   1/1     Running   0          3m8slonghorn-manager-c5647                      1/1     Running   1          3m10slonghorn-manager-dlsmc                      1/1     Running   0          3m10slonghorn-manager-jrnfx                      1/1     Running   1          3m10slonghorn-ui-64bd57fb9d-qjmsl                1/1     Running   0          3m9s

2.將帶有ext4文件系統(tǒng)的/dev/sdc1掛載到/var/lib/longhorn，這是卷存儲的默認路徑。最好在Longhorn安裝之前將磁盤安裝到那里。

Longhorn中節(jié)點磁盤配置的屏幕截圖

3.最后一步是創(chuàng)建一個具有3個副本定義的默認存儲類。

# kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/master/examples/storageclass.yaml
kind: StorageClassapiVersion: storage.k8s.io/v1metadata:  name: longhornprovisioner: driver.longhorn.ioallowVolumeExpansion: trueparameters:  numberOfReplicas: "3"  staleReplicaTimeout: "2880" # 48 hours in minutes  fromBackup: ""

優(yōu)點

• 開源的

• 云原生存儲，它可以在硬件集群和公共云上運行。

• 易于部署，它只需要一個命令，并且“開箱即用”。

• 自動卷備份/還原到S3

缺點

• 它使用標準文件系統(tǒng)（ext4或xfs）到/var/lib/longhorn的掛載點。每個卷就像一個磁盤文件。它可以隨著許多控制器副本進行擴展，從而帶來額外的網(wǎng)絡開銷。類似于我為OpenEBS Jiva描述的內容。

• 卷的掛載有時會花費很長時間（幾分鐘），并且會顯示最終從中恢復的錯誤。

OpenEBS MayaStor

上文有介紹OpenEBS使用cStor的方案，其性能結果確實很差。但是一年半后的時間，OpenEBS團隊引入了一個名為MayStor的新后端。

這是用Rust編寫的云原生聲明性數(shù)據(jù)平面，由2個組件組成：

• 以CSI概念和數(shù)據(jù)平面實現(xiàn)的控制平面。與以前的后端相比，主要區(qū)別在于利用NVMe而不是NVMe-oF，這有望為存儲敏感型工作負載提供更好的IOPS和延遲價值。

• 這種存儲設計的另一個優(yōu)點是，它在主機用戶空間中完全用盡了內核，并消除了由不同Linux發(fā)行版中可用的各種內核引起的差異。它根本不依賴于內核進行訪問。下面的鏈接中，詳細介紹了MayStor的設計說明。

https://blog.mayadata.io/openebs/mayastor-crossing-the-chasm-to-nvmf-infinity-and-beyond

如何在AKS上獲取它？在AKS上進行安裝也非常簡單，我遵循了他們的快速入門指南。

1. 我必須在AKS群集中的每個節(jié)點上用512個數(shù)字配置2MB的大頁面。

echo 512 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

但是我決定通過下面的k8s daemonset強制執(zhí)行它們，而不是通過ssh進入我的每個實例。

apiVersion: apps/v1kind: DaemonSetmetadata:  name: hugepages-ensure  namespace: mayastor  labels:    app: hugepages-ensurespec:  selector:    matchLabels:      name: hugepages-ensure  updateStrategy:    type: OnDelete  template:    metadata:      name: hugepages-ensure      labels:        name: hugepages-ensure        app: hugepages-ensure    spec:      containers:      - name: shell        image: busybox:latest        imagePullPolicy: IfNotPresent        command:          - /bin/sh        args:          - -c          - "while true; do echo 512 | tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages;grep HugePages /proc/meminfo; sleep 6000; done"        volumeMounts:          - mountPath: /host-root            name: host-root        securityContext:          privileged: true      dnsPolicy: ClusterFirstWithHostNet      hostNetwork: true      volumes:        - name: host-root          hostPath:            path: /

2.我必須標記我的存儲節(jié)點VM。

kubectl label node aks-agentpool-13651304-0 openebs.io/engine=mayastornode/aks-agentpool-13651304-0 labeledkubectl label node aks-agentpool-13651304-1 openebs.io/engine=mayastornode/aks-agentpool-13651304-1 labeledkubectl label node aks-agentpool-13651304-2 openebs.io/engine=mayastornode/aks-agentpool-13651304-2 labeled

3.然后，我應用了MayaStor存儲庫中指定的所有清單。

https://github.com/openebs/Mayastor/tree/develop/deploy

kubectl create -f nats-deployment.yamlkubectl create -f csi-daemonset.yamlkubectl create -f mayastorpoolcrd.yamlkubectl create -f moac-rbac.yamlkubectl create -f moac-deployment.yamlkubectl create -f mayastor-daemonset.yaml
kubectl get po -n mayastorNAME                     READY   STATUS    RESTARTS   AGEhugepages-ensure-5dr26   1/1     Running   0          47hhugepages-ensure-tpth6   1/1     Running   0          47hhugepages-ensure-z9mmh   1/1     Running   0          47hmayastor-csi-7rf2l       2/2     Running   0          47hmayastor-csi-hbqlb       2/2     Running   0          47hmayastor-csi-jdw7k       2/2     Running   0          47hmayastor-g9gnl           1/1     Running   7          47hmayastor-j7j4q           1/1     Running   4          47hmayastor-kws9r           1/1     Running   4          47hmoac-7d487fd5b5-hfvhq    3/3     Running   0          41hnats-b4cbb6c96-8drv4     1/1     Running   0          47h

4.當所有內容都在運行時，您可以開始創(chuàng)建用于卷置備的存儲池。在我的情況下，我創(chuàng)建了3個存儲池，每個節(jié)點有一個磁盤。

cat <apiVersion: openebs.io/v1alpha1kind: MayastorPoolmetadata:  name: pool-on-node-1  namespace: mayastorspec:  disks:  - /dev/sdc  node: aks-agentpool-13651304-1EOF
kubectl -n mayastor get MayastorPoolNAME             NODE                       STATE    AGEpool-on-node-0   aks-agentpool-13651304-0   online   40hpool-on-node-1   aks-agentpool-13651304-1   online   46hpool-on-node-2   aks-agentpool-13651304-2   online   46h

5.在繼續(xù)進行StorageClass定義之前，檢查每個存儲池的狀態(tài)很重要。狀態(tài)必須可見。

kubectl -n mayastor describe msp pool-on-node-1Name:         pool-on-node-1Namespace:    mayastorLabels:       API Version:  openebs.io/v1alpha1Kind:         MayastorPoolMetadata:  Creation Timestamp:  2020-08-19T0852Z  Generation:          1  Resource Version:    45513  Self Link:           /apis/openebs.io/v1alpha1/namespaces/mayastor/mayastorpools/pool-on-node-1  UID:                 5330a0be-bebe-445a-9285-856511e318dcSpec:  Disks:    /dev/sdc  Node:  aks-agentpool-13651304-1Status:  Capacity:  1098433691648  Disks:    aio:///dev/sdc  Reason:  State:   online  Used:    1073741824Events:    

6.該過程的最后一步是StorageClass定義，在其中，我配置了3個副本以具有與之前的存儲解決方案相同的測試環(huán)境。

cat <kind: StorageClassapiVersion: storage.k8s.io/v1metadata:  name: mayastorparameters:  repl: '3'  protocol: 'iscsi'provisioner: io.openebs.csi-mayastorEOF

完成這些步驟后，我便能夠通過K8s PVC動態(tài)預配新卷。

優(yōu)點

• 具有強大社區(qū)支持的開源

• 云原生存儲，它可以在硬件集群和公共云上運行。

• 與僅具有一個隊列的SCSI相比，NVMe的使用旨在實現(xiàn)高度并行性，并且可以具有64K隊列。

• 它使用NVMe-oF作為傳輸方式，可以在各種傳輸方式（nvmf，uring，pcie）上工作，并且完全在用戶空間（目標用戶和發(fā)起者）中完成。在用戶空間中運行可以避免進行大量的系統(tǒng)調用，避免后期崩潰/崩潰等。而且它與內核無關，因此跨云或物理環(huán)境的linux類型之間沒有區(qū)別。

缺點

• 早期版本-OpenEBS MayaStor的版本為0.3，因此它仍然存在一些限制和穩(wěn)定性問題。但是，它們走在正確的軌道上，并且在幾個月后，它可能是在K8中存儲的首選。

• 需要在Kubernetes節(jié)點上支持2MB的大頁面。但是，與1GB的大頁面相比，幾乎在所有物理或虛擬環(huán)境中都可用。

性能測試結果

重要說明：單個存儲性能測試的結果無法單獨評估，但必須將測量結果相互比較。這里多種執(zhí)行比較測試的方法是相對比較簡單的。

為了進行驗證，我使用了與Azure AKS 3節(jié)點群集和每個實例均附有1TB高級SSD托管磁盤的完全相同的實驗室。

為了運行測試，我決定使用稱為Dbench的負載測試器。這是Pod的K8s部署清單，在其中運行FIO，這是帶有8個測試用例的Flexible IO Tester。在Docker映像的入口點中指定了測試：

• 隨機讀寫帶寬

• 隨機讀寫IOPS

• 讀寫延遲

• 順序讀/寫

• 混合讀/寫IOPS

首先，我運行了Azure PVC測試以獲得與去年進行比較的基準。結果幾乎相同，因此我們可以假設條件保持不變，并且使用相同的存儲版本將獲得相同的數(shù)量。可從https://gist.github.com/pupapaik/76c5b7f124dbb69080840f01bf71f924獲得來自2019年所有測試的更新的完整測試輸出以及新的MayStor和Longhorn測試

隨機讀寫帶寬

隨機讀取測試表明，GlusterFS，Ceph和Portworx的讀取性能比Azure本地磁盤上的主機路徑好幾倍。OpenEBS和Longhorn的性能幾乎是本地磁盤的兩倍。原因是讀取緩存。對于OpenEBS，寫入速度最快，但是Longhorn和GlusterFS的值也幾乎與本地磁盤相同。

隨機讀寫IOPS

Portworx和OpenEBS在隨機IOPS測試中表現(xiàn)出最好的結果。這次，OpenEBS在寫入方面的IOPS比本地Azure PVC更好，這在技術上幾乎是不可能的。它很可能與在測試用例運行的不同時間處的Azure存儲負載有關。

讀寫延遲

延遲讀取獲勝者與上次相同。LongHorn和OpenEBS幾乎是PortWorx的兩倍。這仍然不錯，因為本機Azure pvc比大多數(shù)其他經(jīng)過測試的存儲要慢。但是，在OpenEBS和Longhorn上寫入期間的延遲更好。GlusterFS仍然比其他存儲要好。

順序讀/寫

順序讀/寫測試顯示的結果與隨機測試相似，但是Ceph的讀性能比GlusterFS高2倍。寫入結果幾乎都處于同一水平，OpenEBS和Longhorn達到了相同的水平。

混合讀/寫IOPS

最后一個測試用例驗證了混合讀寫IOPS，在讀寫方面，OpenEBS交付的速度幾乎是PortWorx或Longhorn的兩倍。

結論

該文章驗證了一個開放源代碼項目在一年內可以有多大的變化！作為演示，讓我們看一下在完全相同的環(huán)境下，OpenEBS cStor和OpenEBS MayaStor的IOPS的比較。

OpenEBS cStor和MayaStor之間的混合讀寫IOPS比較

在選擇存儲空間時，請僅將結果作為標準之一，不要僅根據(jù)文章做出最終判斷。我們可以從上述的測試中得出以下結論：

• Portworx和OpenEBS是AKS上最快的容器存儲。

• 圍繞NVMe的穩(wěn)健設計，OpenEBS似乎已成為最好的開源容器存儲選項之一。

• 對于硬件集群，Ceph是最好的開源后端存儲。對于公共云而言，操作過于復雜，最終與默認的云存儲類相比并沒有增加太多價值。

• 對于簡單的塊存儲用例，Longhorn絕對是有效的選擇，它與OpenEBS Jiva后端非常相似。

當然，以上只是評測容器存儲選項的一種方法。存儲評測應該還包括縮放和穩(wěn)定性等。后期將密切關注CNCF存儲領域中其他正在發(fā)展的項目，并從性能測試和擴展中帶來跟多有趣的更新。

參考鏈接

1.https://medium.com/volterra-io/kubernetes-storage-performance-comparison-9e993cb27271

2.https://medium.com/volterra-io/kubernetes-storage-performance-comparison-v2-2020-updated-1c0b69f0dcf4

責任編輯：xj

原文標題：K8s最常見的存儲解決方案之性能評測