評(píng)估K8s可用的最常見的存儲(chǔ)解決方案

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

目前CNCF的存儲(chǔ)格局和解決方案已經(jīng)更新，它已從2019年的30個(gè)解決方案增長(zhǎng)到目前的45個(gè)解決方案，還進(jìn)行了公共云集成的管理擴(kuò)展，例如AWS EBS，Google永久磁盤或Azure磁盤存儲(chǔ)。一些新解決方案像Alluxio一樣，更側(cè)重于分布式文件系統(tǒng)或?qū)ο蟠鎯?chǔ)。

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

• 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年的存儲(chǔ)方案，GlusterFS Heketi在性能結(jié)果上排名倒數(shù)第二，它的改進(jìn)為零，并且大多數(shù)情況下是一個(gè)沉寂的項(xiàng)目（Heketi作為REST協(xié)調(diào)器而不是GlusterFS本身）。如果查看它們的官方GitHub，您會(huì)發(fā)現(xiàn)他們近乎將其置于維護(hù)模式，并且云本地存儲(chǔ)功能沒有任何更新。

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

本機(jī)Azure存儲(chǔ)

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

無(wú)需使用任何特殊功能。當(dāng)您配置新的AKS群集時(shí)，將自動(dòng)預(yù)定義2個(gè)存儲(chǔ)類，分別稱為“默認(rèn)”和“高級(jí)托管”。高級(jí)類對(duì)卷使用基于SSD的高性能和低延遲磁盤。

優(yōu)點(diǎn)

• AKS上的默認(rèn)設(shè)置無(wú)需執(zhí)行任何操作。

缺點(diǎn)

• 故障轉(zhuǎn)移情況下非常慢，有時(shí)需要將近10分鐘才能將卷重新連接到其他節(jié)點(diǎn)上的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代表了新的容器附加存儲(chǔ)（CAS）概念，其中是單個(gè)基于微服務(wù)的存儲(chǔ)控制器和多個(gè)基于微服務(wù)的存儲(chǔ)副本。它與Portworx一起屬于云本機(jī)存儲(chǔ)類別。

它是完全開源的，目前提供2個(gè)后端，分別是Jiva和cStor。我從Jiva開始，然后切換到cStor。cStor進(jìn)行了一些改進(jìn)，因?yàn)榭刂破骷捌涓北静渴鹪趩蝹€(gè)名稱空間（安裝openebs的名稱空間）中，或者它使用原始磁盤而不是格式化分區(qū)。每個(gè)k8s卷都有其自己的存儲(chǔ)控制器，該存儲(chǔ)可以在節(jié)點(diǎn)上可用存儲(chǔ)容量的允許范圍內(nèi)進(jìn)行擴(kuò)展。

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

1.我必須連接到所有k8s節(jié)點(diǎn)的控制臺(tái)并安裝iSCSI，因?yàn)樗褂胕SCSI協(xié)議在Pod和存儲(chǔ)控制器與k8s節(jié)點(diǎn)之間進(jìn)行連接。

apt-get updateapt install -y open-iscsi

2.然后，我將單個(gè)YAML定義應(yīng)用于我的k8s集群

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

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

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

4.然后，將這些磁盤添加到標(biāo)準(zhǔn)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

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

優(yōu)點(diǎn)

• 開源的

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

• 總的來(lái)說(shuō)，CAS概念–我非常喜歡容器存儲(chǔ)背后的想法，并且我相信會(huì)有未來(lái)。

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

缺點(diǎn)

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

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

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

注意：OpenEBS團(tuán)隊(duì)在文檔中調(diào)整了相關(guān)的測(cè)試用例場(chǎng)景

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

Portworx

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

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

1.首選，我選擇了Portworx托管的etcd來(lái)簡(jiǎn)化設(shè)置，并填充了k8s 1.11.4版本。

2.我必須將數(shù)據(jù)網(wǎng)絡(luò)接口修改為azure0，因?yàn)槲沂褂玫氖蔷哂懈呒?jí)聯(lián)網(wǎng)功能的Azure cni。否則，Portworx將使用來(lái)自docker bridge的IP地址而不是VM接口。

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

4.引導(dǎo)后，我在每個(gè)k8s節(jié)點(diǎn)上運(yùn)行了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)先級(jí)和3個(gè)副本的Storage Class，然后可以配置k8s pvc。

優(yōu)點(diǎn)

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

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

• 云原生存儲(chǔ)，它可以在硬件集群和公共云上運(yùn)行。

• 存儲(chǔ)感知的服務(wù)等級(jí)（COS）和應(yīng)用感知的I/O調(diào)整

缺點(diǎn)

• 閉源，專有供應(yīng)商解決方案。

GlusterFS Heketi

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

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

1. 首先，我基于示例一創(chuàng)建了一個(gè)拓?fù)湮募渲邪疟P和主機(jī)名。

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

2.由于Heketi主要是在基于RHEL的操作系統(tǒng)上開發(fā)和測(cè)試的，因此我在使用Ubuntu主機(jī)的AKS上遇到了一個(gè)問(wèn)題，該內(nèi)核路徑錯(cuò)誤。這是解決此問(wèn)題的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的另一個(gè)問(wèn)題是非空磁盤，因此我使用了擦拭來(lái)清理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.最后一步，我運(yùn)行命令gk-deploy -g -t topology.json，該命令在由heketi控制器控制的每個(gè)節(jié)點(diǎn)上部署了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

然后，我面臨著動(dòng)態(tài)配置的問(wèn)題。Heketi restURL對(duì)k8s控制平面不可用。我嘗試了kube dns記錄，pod IP和svc IP。兩者都不起作用。因此，我不得不通過(guò)Heketi CLI手動(dòng)創(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)點(diǎn)

• 成熟的存儲(chǔ)解決方案

• 比Ceph更輕

缺點(diǎn)

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

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

Ceph Rook

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

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

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

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

2.我必須配置特定于AKS的FLEXVOLUME_DIR_PATH，因?yàn)樗鼈兪褂?etc/kubernetes/volumeplugins/ 而不是默認(rèn)的Ubuntu /usr/libexec。沒有此更改，kubelet無(wú)法安裝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中使用的設(shè)備。我的附加磁盤始終位于/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塊池和存儲(chǔ)類

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。最后，我通過(guò)以下部署工具檢查狀態(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)點(diǎn)

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

• Rook使生命周期管理變得更加簡(jiǎn)單。

缺點(diǎn)

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

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

如何在AKS上獲取它？當(dāng)然也可以輕松安裝到AKS，只需要運(yùn)行一個(gè)命令，它將所有組件安裝到我的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，這是卷存儲(chǔ)的默認(rèn)路徑。最好在Longhorn安裝之前將磁盤安裝到那里。

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

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

# 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)點(diǎn)

• 開源的

• 云原生存儲(chǔ)，它可以在硬件集群和公共云上運(yùn)行。

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

• 自動(dòng)卷備份/還原到S3

缺點(diǎn)

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

• 卷的掛載有時(shí)會(huì)花費(fèi)很長(zhǎng)時(shí)間（幾分鐘），并且會(huì)顯示最終從中恢復(fù)的錯(cuò)誤。

OpenEBS MayaStor

上文有介紹OpenEBS使用cStor的方案，其性能結(jié)果確實(shí)很差。但是一年半后的時(shí)間，OpenEBS團(tuán)隊(duì)引入了一個(gè)名為MayStor的新后端。

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

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

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

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

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

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

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

但是我決定通過(guò)下面的k8s daemonset強(qiáng)制執(zhí)行它們，而不是通過(guò)ssh進(jìn)入我的每個(gè)實(shí)例。

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.我必須標(biāo)記我的存儲(chǔ)節(jié)點(diǎn)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.然后，我應(yīng)用了MayaStor存儲(chǔ)庫(kù)中指定的所有清單。

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.當(dāng)所有內(nèi)容都在運(yùn)行時(shí)，您可以開始創(chuàng)建用于卷置備的存儲(chǔ)池。在我的情況下，我創(chuàng)建了3個(gè)存儲(chǔ)池，每個(gè)節(jié)點(diǎn)有一個(gè)磁盤。

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ù)進(jìn)行StorageClass定義之前，檢查每個(gè)存儲(chǔ)池的狀態(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.該過(guò)程的最后一步是StorageClass定義，在其中，我配置了3個(gè)副本以具有與之前的存儲(chǔ)解決方案相同的測(cè)試環(huán)境。

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

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

優(yōu)點(diǎn)

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

• 云原生存儲(chǔ)，它可以在硬件集群和公共云上運(yùn)行。

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

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

缺點(diǎn)

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

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

性能測(cè)試結(jié)果

重要說(shuō)明：?jiǎn)蝹€(gè)存儲(chǔ)性能測(cè)試的結(jié)果無(wú)法單獨(dú)評(píng)估，但必須將測(cè)量結(jié)果相互比較。這里多種執(zhí)行比較測(cè)試的方法是相對(duì)比較簡(jiǎn)單的。

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

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

• 隨機(jī)讀寫帶寬

• 隨機(jī)讀寫IOPS

• 讀寫延遲

• 順序讀/寫

• 混合讀/寫IOPS

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

隨機(jī)讀寫帶寬

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

隨機(jī)讀寫IOPS

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

讀寫延遲

延遲讀取獲勝者與上次相同。LongHorn和OpenEBS幾乎是PortWorx的兩倍。這仍然不錯(cuò)，因?yàn)楸緳C(jī)Azure pvc比大多數(shù)其他經(jīng)過(guò)測(cè)試的存儲(chǔ)要慢。但是，在OpenEBS和Longhorn上寫入期間的延遲更好。GlusterFS仍然比其他存儲(chǔ)要好。

順序讀/寫

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

混合讀/寫IOPS

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

結(jié)論

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

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

在選擇存儲(chǔ)空間時(shí)，請(qǐng)僅將結(jié)果作為標(biāo)準(zhǔn)之一，不要僅根據(jù)文章做出最終判斷。我們可以從上述的測(cè)試中得出以下結(jié)論：

• Portworx和OpenEBS是AKS上最快的容器存儲(chǔ)。

• 圍繞NVMe的穩(wěn)健設(shè)計(jì)，OpenEBS似乎已成為最好的開源容器存儲(chǔ)選項(xiàng)之一。

• 對(duì)于硬件集群，Ceph是最好的開源后端存儲(chǔ)。對(duì)于公共云而言，操作過(guò)于復(fù)雜，最終與默認(rèn)的云存儲(chǔ)類相比并沒有增加太多價(jià)值。

• 對(duì)于簡(jiǎn)單的塊存儲(chǔ)用例，Longhorn絕對(duì)是有效的選擇，它與OpenEBS Jiva后端非常相似。

當(dāng)然，以上只是評(píng)測(cè)容器存儲(chǔ)選項(xiàng)的一種方法。存儲(chǔ)評(píng)測(cè)應(yīng)該還包括縮放和穩(wěn)定性等。后期將密切關(guān)注CNCF存儲(chǔ)領(lǐng)域中其他正在發(fā)展的項(xiàng)目，并從性能測(cè)試和擴(kuò)展中帶來(lái)跟多有趣的更新。

參考鏈接

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

責(zé)任編輯：xj

原文標(biāo)題：K8s最常見的存儲(chǔ)解決方案之性能評(píng)測(cè)