在线观看日本亚洲一区二区三区,艳姐李铁柱王淑兰的小说,一二三区在线视频

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

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

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

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在性能結果上排名倒數第二，它的改進為零，并且大多數情況下是一個沉寂的項目（Heketi作為REST協調器而不是GlusterFS本身）。如果查看它們的官方GitHub，您會發現他們近乎將其置于維護模式，并且云本地存儲功能沒有任何更新。

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

本機Azure存儲

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

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

優點

AKS上的默認設置無需執行任何操作。

缺點

故障轉移情況下非常慢，有時需要將近10分鐘才能將卷重新連接到其他節點上的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的名稱空間）中，或者它使用原始磁盤而不是格式化分區。每個k8s卷都有其自己的存儲控制器，該存儲可以在節點上可用存儲容量的允許范圍內進行擴展。

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

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

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控制器在底層節點發現了我所有的磁盤。但是我必須手動確定附加的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動態配置新卷。

優點

開源的
Maya在資源使用可視化方面做得很好。您可以輕松地在k8s集群中部署多個服務，并輕松設置監視和日志記錄以收集集群的所有重要方面。這是調試的理想工具。
總的來說，CAS概念–我非常喜歡容器存儲背后的想法，并且我相信會有未來。
OpenEBS背后的社區—我能夠在幾分鐘內解決任何問題。Slack上的團隊非常有幫助。

缺點

不成熟-OpenEBS是一個相當新的項目，尚未達到穩定版本。核心團隊仍在進行后端優化，這將在接下來的幾個月中顯著提高性能。
Kubelet和存儲控制器之間的iSCSI連接由k8s服務實現，這在某些覆蓋網絡CNI插件（例如Tungsten Fabric）中可能是一個問題。
需要在Kubernetes節點上安裝其他軟件（iSCSI），這使其在托管Kubernetes集群的情況下不切實際。

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

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

Portworx

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

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

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

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

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

4.引導后，我在每個k8s節點上運行了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>

我創建了具有高優先級和3個副本的Storage Class，然后可以配置k8s pvc。

優點

易于部署-具有詳細配置的網站配置器。
AKS集群的配置器，不需要任何其他步驟，如ceph或glusterfs。
云原生存儲，它可以在硬件集群和公共云上運行。
存儲感知的服務等級（COS）和應用感知的I/O調整

缺點

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

GlusterFS Heketi

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

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

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

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

2.由于Heketi主要是在基于RHEL的操作系統上開發和測試的，因此我在使用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控制器控制的每個節點上部署了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

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

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工具將現有的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

優點

成熟的存儲解決方案
比Ceph更輕

缺點

Heketi不是為公共管理的k8設計的。它與HW群集配合使用，安裝更容易。
并非真正為“結構化數據”設計的，如SQL數據庫。但是，您可以使用Gluster備份和還原數據庫。

Ceph Rook

OpenStack私有云常見和Ceph進行搭配。它始終需要設計特定的硬件配置，根據數據類型生成pg組，配置日志SSD分區（在bluestore之前）并定義Crush Map。因此，當我第一次聽說在3節點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.安裝后，我使用以下配置創建了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。最后，我通過以下部署工具檢查狀態：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 |+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+

優點

在大型生產環境中運行的強大存儲
Rook使生命周期管理變得更加簡單。

缺點

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

Longhorn

Longhorn是Rancher開發的用于K8s的云原生分布式塊存儲。它主要是為微服務用例設計的。它為每個塊設備卷創建一個專用的存儲控制器，并跨存儲在多個節點上的多個副本同步復制該卷。Longhorn在附加了卷的節點上創建了Longhorn Engine，并在復制了卷的節點上創建了副本。與其他存儲方案類似，整個控制平面正常運行，而數據平面由K8s編排。它是完全開源的。有趣的是，OpenEBS Jiva后端實際上是基于Longhorn的，或者至少最初是基于Longhorn的。主要區別在于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文件系統的/dev/sdc1掛載到/var/lib/longhorn，這是卷存儲的默認路徑。最好在Longhorn安裝之前將磁盤安裝到那里。

Longhorn中節點磁盤配置的屏幕截圖

3.最后一步是創建一個具有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: ""

優點

開源的
云原生存儲，它可以在硬件集群和公共云上運行。
易于部署，它只需要一個命令，并且“開箱即用”。
自動卷備份/還原到S3

缺點

它使用標準文件系統（ext4或xfs）到/var/lib/longhorn的掛載點。每個卷就像一個磁盤文件。它可以隨著許多控制器副本進行擴展，從而帶來額外的網絡開銷。類似于我為OpenEBS Jiva描述的內容。
卷的掛載有時會花費很長時間（幾分鐘），并且會顯示最終從中恢復的錯誤。

OpenEBS MayaStor

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

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

以CSI概念和數據平面實現的控制平面。與以前的后端相比，主要區別在于利用NVMe而不是NVMe-oF，這有望為存儲敏感型工作負載提供更好的IOPS和延遲價值。
這種存儲設計的另一個優點是，它在主機用戶空間中完全用盡了內核，并消除了由不同Linux發行版中可用的各種內核引起的差異。它根本不依賴于內核進行訪問。下面的鏈接中，詳細介紹了MayStor的設計說明。

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

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

我必須在AKS群集中的每個節點上用512個數字配置2MB的大頁面。

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

但是我決定通過下面的k8s daemonset強制執行它們，而不是通過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.我必須標記我的存儲節點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.當所有內容都在運行時，您可以開始創建用于卷置備的存儲池。在我的情況下，我創建了3個存儲池，每個節點有一個磁盤。

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.在繼續進行StorageClass定義之前，檢查每個存儲池的狀態很重要。狀態必須可見。

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個副本以具有與之前的存儲解決方案相同的測試環境。

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

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

優點

具有強大社區支持的開源
云原生存儲，它可以在硬件集群和公共云上運行。
與僅具有一個隊列的SCSI相比，NVMe的使用旨在實現高度并行性，并且可以具有64K隊列。
它使用NVMe-oF作為傳輸方式，可以在各種傳輸方式（nvmf，uring，pcie）上工作，并且完全在用戶空間（目標用戶和發起者）中完成。在用戶空間中運行可以避免進行大量的系統調用，避免后期崩潰/崩潰等。而且它與內核無關，因此跨云或物理環境的linux類型之間沒有區別。

缺點

早期版本-OpenEBS MayaStor的版本為0.3，因此它仍然存在一些限制和穩定性問題。但是，它們走在正確的軌道上，并且在幾個月后，它可能是在K8中存儲的首選。
需要在Kubernetes節點上支持2MB的大頁面。但是，與1GB的大頁面相比，幾乎在所有物理或虛擬環境中都可用。

性能測試結果

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

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

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

隨機讀寫帶寬
隨機讀寫IOPS
讀寫延遲
順序讀/寫
混合讀/寫IOPS

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