Kubernetes 幾種存儲方式性能對比
摘要
本文展示了一個簡單的存儲對比，使用未經(jīng)性能優(yōu)化的多種存儲提供的存儲卷進(jìn)行測試和比較。
忽略 Azure 的原生 PVC 或 hostPath ，我們可以得出如下測試結(jié)果：
- Portworx 是 AKS 上最快的容器存儲。
- Ceph 是私有云集群上最快的開源存儲后端。對公有云來說，其操作太過復(fù)雜，這些多余的復(fù)雜性并沒有能提供更好的測試表現(xiàn)。
- OpenEBS 的概念很棒，但是其后端需要更多優(yōu)化。
如果你正在運(yùn)行 Kubernetes，你可能正在使用，或者準(zhǔn)備使用動態(tài)供給的塊存卷 ，而首當(dāng)其沖的問題就是為集群選擇合適的存儲技術(shù)。這個事情并不能用一個簡單的測試來做出簡單的回答，告訴你目前市面上比較好的技術(shù)是什么。存儲技術(shù)的選擇過程中，集群上運(yùn)行的負(fù)載類型是一個重要的輸入。對于裸金屬集群來說，需要根據(jù)實際用例進(jìn)行選擇，并集成到自己的硬件之中。公有云中的托管 K8s，例如 AKS、EKS 或者 GKE，都具有開箱可用的塊存儲能力，然而這也不見得就是很好的選擇。有很多因素需要考慮，比如說公有云的 StorageClass 的故障轉(zhuǎn)移時間太長。例如在 一個針對 AWS EBS 的故障測試中，加載了卷的 Pod 用了超過五分鐘才成功的在另一個節(jié)點(diǎn)上啟動。Portworx 或者 OpenEBS 這樣的云原生存儲產(chǎn)品，正在嘗試解決這類問題。
本文的目標(biāo)是使用最常見的 Kubernetes 存儲方案，進(jìn)行基本的性能對比。我覺得在 Azure AKS 上使用下列后端：
- AKS 原生 Storageclass：Azure native premium
- 使用 cStor 后端的 OpenEBS
- Portworx
- Heketi 管理的 Gluster
- Rook 管理的 Ceph
現(xiàn)在我們來介紹每種存儲后端，并交代一下安裝過程，然后進(jìn)入 AKS 測試環(huán)境進(jìn)行測試，最后得出結(jié)果。
存儲
這一節(jié)中介紹測試中用到的存儲方案，包含安裝過程以及該方案的優(yōu)缺點(diǎn)。
Azure 原生 StorageClass
我選擇這一方案的動機(jī)是以此作為所有測試的基線。這個方案 應(yīng)該 提供優(yōu)質(zhì)性能。Azure 動態(tài)的創(chuàng)建托管磁盤，并把它們映射到 K8s 的虛擬機(jī)中，最終成為 Pod 的存儲卷。
這個方案很方便，什么多余的步驟都不需要。創(chuàng)建一個新的 AKS 集群之后，就自動提供了兩個預(yù)定義的 StorageClass，分別是 default 和 managed-premium ，premium 使用的是基于 SSD 的高性能低延遲磁盤。
- $ 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-w7nqf 0/1ContainerCreating029s
優(yōu)點(diǎn)
AKS 開箱即用。
缺點(diǎn)
故障轉(zhuǎn)移非常緩慢，有時需要十分鐘以后，存儲卷才能重新掛載到不同節(jié)點(diǎn)上的 Pod 里。
OpenEBS
對我來說 OpenEBS 是個全新事物，因此我很有興趣做他的測試。他提出了一個新的 Container Attached Storage(容器掛載存儲) 概念，這是一個基于微服務(wù)的存儲控制器，以及多個基于微服務(wù)的存儲副本。他和 Portworx 同樣，屬于云原生存儲分類的成員。
它是一個完全開源的方案，目前提供兩種后端——Jiva 和 cStor。我最開始選擇的是 Jiva，后來切換到 cStor。cStor 有很多長處，例如他的控制器和副本被部署到單一的 OpenEBS 所在的命名空間之中，能夠管理原始磁盤等。每個 K8s 卷都有自己的存儲控制器，能在節(jié)點(diǎn)存儲容量的許可范圍內(nèi)對存儲進(jìn)行擴(kuò)展。
在 AKS 上運(yùn)行
在 AKS 上的安裝非常容易。
- 連接到所有 K8s 節(jié)點(diǎn)上，安裝 iSCSI，這是因為他需要使用 iSCSI 協(xié)議在 K8s 節(jié)點(diǎn)之間進(jìn)行 Pod 和控制器的連接。apt-get update apt install -y open-iscsi
- 使用一個 YAML 定義在 K8s 集群上完成部署：kubectl apply -f https://openebs.github.io/charts/openebs-operator-0.8.0.yaml
- 下一步，OpenEBS 控制器發(fā)現(xiàn)了節(jié)點(diǎn)中的所有磁盤。但是我必須手工標(biāo)識出我附加的 AWS 托管磁盤。$ kubectl get disk NAME AGE disk-184d99015253054c48c4aa3f17d137b15m disk-2f6bced7ba9b2be230ca5138fd0b07f15m disk-806d3e77dd2e38f188fdaf9c46020bdc5m
- 然后把這些磁盤加入 StoragePoolClaim，這個對象會在 StorageClass 中進(jìn)行引用：--- apiVersion: storage.k8s.io/v1 kind:StorageClass metadata: 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/v1alpha1 kind:StoragePoolClaim metadata: name: cstor-disk spec: name: cstor-disk type: disk maxPools:3 poolSpec: poolType: striped disks: diskList: - disk-2f6bced7ba9b2be230ca5138fd0b07f1 - disk-806d3e77dd2e38f188fdaf9c46020bdc - disk-184d99015253054c48c4aa3f17d137b1
完成這些步驟之后，就可以用 K8s 的 PVC 來動態(tài)的創(chuàng)建存儲卷了。
優(yōu)點(diǎn)
- 開源
- Maya 在資源使用的可視化方面做得非常好?？梢栽?K8s 中部署多個服務(wù)，方便的為集群的各方面數(shù)據(jù)設(shè)置監(jiān)控和日志。對于排錯工作來說，這十分重要。
- CAS 概念：我非常欣賞這一概念，我相信這是未來的趨勢。
- OpenEBS 社區(qū)：在社區(qū)中我的任何問題都能在幾分鐘內(nèi)得到解決。Slack 上的團(tuán)隊非常有幫助。
缺點(diǎn)
- 不成熟：OpenEBS 還很年輕，目前還沒有發(fā)布穩(wěn)定版。核心團(tuán)隊還在進(jìn)行后端的優(yōu)化，未來幾個月里會對性能做出很大提升。
- Kubelet 和存儲控制器之間的 iSCSI 連接是通過 K8s Service 進(jìn)行的，這在 Tungsten Fabric 之類的 CNI 插件環(huán)境中可能會出問題。
- 需要在 K8s 節(jié)點(diǎn)上安裝額外的軟件(iSCSI)，這對于托管集群來說非常不便。
注：OpenEBS 團(tuán)隊對我的案例場景進(jìn)行了調(diào)整：
https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench
Portworx
Portworx 是另一個面向 Kubernetes 的容器原生存儲方案，它專注于高度分布式的環(huán)境。這是一個主機(jī)可尋址的存儲，每個卷都直接映射到掛在的主機(jī)上。他提供了基于應(yīng)用 I/O 類型的自動微調(diào)能力。 官方網(wǎng)站 提供了更多信息。不幸的是，它也是本文中唯一的非開源產(chǎn)品。然而它提供了 3 節(jié)點(diǎn)的免費(fèi)試用。
在 AKS 上運(yùn)行
在 AKS 上的安裝同樣簡單，我用了他們 網(wǎng)站 提供的生成器。
- azure0
- $ kubectl get pods -o wide -n kube-system -l name=portworxNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODEportworx-g9csq 1/1Running014m10.0.1.66 aks-agentpool-20273348-2<none>portworx-nt2lq 1/1Running014m10.0.1.4 aks-agentpool-20273348-0<none>portworx-wcjnx 1/1Running014m10.0.1.35 aks-agentpool-20273348-1<none>
為 PVC 創(chuàng)建一個 StorageClass，定義高優(yōu)先級，以及三個副本：
- root@aks-agentpool-20273348-0:~# kubectl get storageclass -o yaml portworx-scapiVersion: storage.k8s.io/v1kind:StorageClassmetadata: creationTimestamp:2019-01-28T21:10:28Z name: portworx-sc resourceVersion:"55332" selfLink:/apis/storage.k8s.io/v1/storageclasses/portworx-sc uid:23455e40-2341-11e9-bfcb-a23b1ec87092parameters: priority_io: high repl:"3"provisioner: kubernetes.io/portworx-volumereclaimPolicy:DeletevolumeBindingMode:Immediate
優(yōu)點(diǎn)
- 部署方便：生成器包含配置細(xì)節(jié)。
- 不像 Ceph 和 Glusterfs 那樣需要進(jìn)行額外配置。
- 云原生存儲：公有云和裸金屬都可以運(yùn)行。
- 存儲級別感知和應(yīng)用感知的 I/O 微調(diào)。
缺點(diǎn)
- 閉源：商業(yè)解決方案
GlusterFS Heketi
GlusterFS 是知名的開源存儲方案，是由 Redhat 提供的開源存儲方案。 Heketi 是 GlusterFS 的 RESTful 卷管理界面。它提供了易用的方式為 GlusterFS 卷提供了動態(tài)供給的功能。如果沒有 Heketi 的輔助，就只能手工創(chuàng)建 GlusterFS 卷并映射到 K8s PV 了。關(guān)于 GlusterFS 的更多信息，請閱讀 官方文檔 。
在 AKS 上運(yùn)行
根據(jù) Heketi 的 快速入門 文檔進(jìn)行部署。
- 參照 樣例 ，創(chuàng)建一個包含磁盤和主機(jī)名的拓?fù)湮募?/li>
- Heketi 主要的開發(fā)和測試都在基于 RHEL 的操作系統(tǒng)上，我在 AKS 上使用 Ubuntu 主機(jī)時，出現(xiàn)了內(nèi)核模塊路徑錯誤的問題，我提交了一個 PR 來修正這個問題。~~~ +++ b/deploy/kube-templates/glusterfs-daemonset.yaml @@ -67,7 +67,7 @@ spec: mountPath: “/etc/ssl” readOnly: true – name: kernel-modules name: kernel-modules hostPath: mountPath: “/usr/lib/modules” mountPath: “/lib/modules” readOnly: true securityContext: capabilities: {} @@ -131,4 +131,4 @@ spec: path: “/etc/ssl” path: “/usr/lib/modules” path: “/lib/modules” ~~~
- 我在 AKS 環(huán)境中遇到的另一個問題是一個非空磁盤，所以我用 wipefs 為 glusterfs 進(jìn)行清理。這個磁盤并未用過。 $ wipefs -a /dev/sdc /dev/sdc: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31
- 最后運(yùn)行 gk-deploy -g -t topology.json ，會在每個節(jié)點(diǎn)上運(yùn)行 Heketi 控制器管理之下的 GlusterFS Pod。$ kubectl get po -o wide NAME READY STATUS RESTARTS IP NODE NOMINATED NODE glusterfs-fgc8f 1/1Running010.0.1.35 aks-agentpool-20273348-1 glusterfs-g8ht6 1/1Running010.0.1.4 aks-agentpool-20273348-0 glusterfs-wpzzp 1/1Running010.0.1.66 aks-agentpool-20273348-2 heketi-86f98754c-n8qfb 1/1Running010.0.1.69 aks-agentpool-20273348-2 然后我遇到了新問題。K8s 控制面無法使用 Heketi 的 restURL 。我測試了一下 kube dns 的記錄，pod IP 和 svc IP 都沒有生效。最后只能手工使用 Heketi CLI 來創(chuàng)建存儲卷。
- $ export HEKETI_CLI_SERVER=http://10.0.1.69:8080$ heketi-cli volume create --size=10--persistent-volume --persistent-volume-endpoint=heketi-storage-endpoints | kubectl create -f -persistentvolume/glusterfs-efb3b155 created$ kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEglusterfs-efb3b155 10Gi RWX RetainAvailable
然后把現(xiàn)存 PV 映射為 PVC，加載給測試 工具 進(jìn)行測試。
- 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
Heketi 的更多輸出：
- $ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849VolumeName: vol_efb3b15529aa9aba889d7900f0ce9849Type:ReplicateVolume ID:96fde36b-e389-4dbe-887b-baae32789436Status:StartedSnapshotCount: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/brickOptionsReconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: off$ kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEheketi ClusterIP192.168.101.75<none>8080/TCP 5hheketi-storage-endpoints ClusterIP192.168.103.66<none>1/TCP 5h$ kubectl get endpointsNAME ENDPOINTS AGEheketi 10.0.1.69:80805hheketi-storage-endpoints 10.0.1.35:1,10.0.1.4:1,10.0.1.66:15hkubernetes 172.31.22.152:4431droot@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)
- 久經(jīng)考驗的存儲方案。
- 比 Ceph 輕量。
缺點(diǎn)
- Heketi 在公有云上表現(xiàn)不佳。在私有云上表現(xiàn)良好，安裝會方便一些。
- 并非為結(jié)構(gòu)化數(shù)據(jù)設(shè)計，例如 SQL 數(shù)據(jù)庫。然而可以使用 GlusterFS 為 數(shù)據(jù)庫 提供備份和恢復(fù)支持。
Ceph Rook
我在 OpenStack 私有云上嘗試過安裝和運(yùn)行 Ceph。它需要為特定硬件定制參數(shù)，根據(jù)數(shù)據(jù)類型設(shè)計 pg 組、SSD 分區(qū)和 CRUSH 圖等。所以第一次聽說在 3 節(jié)點(diǎn)的 K8s 集群上運(yùn)行 Ceph 的時候，我不太相信它能工作。結(jié)果 Rook 的編排工具讓我印象深刻，它把所有的步驟和 K8s 的編排能力結(jié)合在一起，讓安裝變得非常簡便。
在 AKS 上運(yùn)行
Rook 的缺省安裝無需任何特定步驟，如果沒什么高級配置，會非常簡單。
- 我使用的是 Ceph 快速入門指南
- 為 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.yaml index 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_PATHvalue: “/etc/kubernetes/volumeplugins” # Set the path where kernel modules can be found # – name: LIB_MODULES_DIR_PATH # value: ““ ~~~
- 還要在 deviceFilter 中指定要使用的設(shè)備，這里是 /dev/sdc 。~~~ diff –git a/cluster/examples/kubernetes/ceph/cluster.yaml b/cluster/examples/kubernetes/ceph/cluster.yaml index 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: ~~~
- 安裝之后，創(chuàng)建一個 Ceph block pool，以及 StorageClass，使用如下配置。apiVersion: ceph.rook.io/v1 kind:CephBlockPool metadata: name: replicapool namespace: rook-ceph spec: failureDomain: host replicated: size:3--- apiVersion: storage.k8s.io/v1 kind:StorageClass metadata: name: rook-ceph-block provisioner: ceph.rook.io/block parameters: blockPool: replicapool clusterNamespace: rook-ceph fstype: xfs reclaimPolicy:Retain
- 最后使用部署 工具 進(jìn)行檢查。
- $ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849VolumeName: vol_efb3b15529aa9aba889d7900f0ce9849Type:ReplicateVolume ID:96fde36b-e389-4dbe-887b-baae32789436Status:StartedSnapshotCount: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/brickOptionsReconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: off$ kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEheketi ClusterIP192.168.101.75<none>8080/TCP 5hheketi-storage-endpoints ClusterIP192.168.103.66<none>1/TCP 5h$ kubectl get endpointsNAME ENDPOINTS AGEheketi 10.0.1.69:80805hheketi-storage-endpoints 10.0.1.35:1,10.0.1.4:1,10.0.1.66:15hkubernetes 172.31.22.152:4431droot@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ǎn)環(huán)境上的健壯存儲系統(tǒng)。
- Rook 很好的簡化了生命周期管理。
缺點(diǎn)
- 復(fù)雜：更加重量級，也不太適合在公有云上運(yùn)行。在私有云上的運(yùn)行可能更加合適。
AKS 測試環(huán)境
我用 3 個虛擬機(jī)創(chuàng)建了基本的 Azure AKS 集群。為了連接到 Premium SSD 上，我只能使用 type E 以上級別的虛擬機(jī)。因此我選擇了 Standard_E2s_v3 ，其上配備了 2 vCPU 以及 16GB 的內(nèi)存。
在 AKS 集群所在的資源足中，可以看到所有的虛擬機(jī)、網(wǎng)絡(luò)接口等資源。在這里創(chuàng)建 3 個 1TB 的 Premium SSD 存儲，并手工掛載到每個虛擬機(jī)上。
這樣在每個實例上，我都有 1TB 的空磁盤。Azure 的頁面上，根據(jù)我們選擇的虛擬機(jī)和磁盤尺寸來看，性能應(yīng)該有 5000 IOPS 以及 200MB/s 的吞吐量。最后一節(jié)會顯示我們的真實結(jié)果。
性能結(jié)果
注意：每種存儲的結(jié)果并不能作為獨(dú)立的評估結(jié)果，但是其比較情況是可以參考的。有很多種對比測試的方法，這是最簡單的一種。
為了運(yùn)行測試，我決定使用現(xiàn)成的測試工具 Dbench ，它是一個 k8s 的 YAML 文件，會使用 FIO 運(yùn)行 8 個測試用例?？梢栽? Dockerfile 中 指定不同測試 ：
- 隨機(jī)讀寫帶寬。
- 隨機(jī)讀寫 IOPS。
- 讀寫延遲。
- 順序讀寫。
- 混合讀寫 IOPS。
所有測試的結(jié)果可以在 Github 上找到。
隨機(jī)讀寫帶寬
隨機(jī)讀寫測試表明，GlusterFS、Ceph 以及 Portworx 的讀取性能比 AWS 本地盤的 hostPath 快了幾倍。讀緩存是罪魁禍?zhǔn)住lusterFS 和 Portworx 的寫入更快，其效率直逼本地磁盤。
隨機(jī)讀寫 IOPS
隨機(jī) IOPS 測試中，Portworx 和 Ceph 表現(xiàn)較好。Portworx 在寫入方面獲得了接近 Azure 原生 PVC 的 IOPS。
讀寫延遲
延遲測試的結(jié)果比較有趣，Azure 原生 PVC 比多數(shù)其它存儲都差。Portworx 和 Ceph 表現(xiàn)較好。寫入方面，GlusterFS 要優(yōu)于 Ceph。OpenEBS 的延遲相對來說非常的高。
順序讀寫
順序讀寫的結(jié)果和前面的隨機(jī)測試差不多，然而 Cpeh 在讀取方面比 GlusterFS 快了一倍多。寫入結(jié)果基本一致，只有 OpenEBS 表現(xiàn)奇差。
混合讀寫 IOPS
最后一個測試用例檢查的是混合讀寫情況下的 IOPS，Portworx 和 Ceph 都給出了優(yōu)于 Azure 原生 PVC 的結(jié)果。
結(jié)論
本文展示了一個簡單的存儲對比，使用未經(jīng)性能優(yōu)化的多種存儲提供的存儲卷進(jìn)行測試和比較。建議關(guān)注本文所述方法，不建議直接采用結(jié)果進(jìn)行判斷。
忽略 Azure 的原生 PVC 或 hostPath ，我們可以得出如下測試結(jié)果：
- Portworx 是 AKS 上最快的容器存儲。
- Ceph 是私有云集群上最快的開源存儲后端。對公有云來說，其操作太過復(fù)雜，這些多余的復(fù)雜性并沒有能提供更好的測試表現(xiàn)。
- OpenEBS 的概念很棒，但是其后端需要更多優(yōu)化。
調(diào)整性能數(shù)據(jù)的測試規(guī)模應(yīng)該會很有意思。另外值得關(guān)注的對比就是 CPU 和內(nèi)存的消耗。我會持續(xù)關(guān)注，并分享更多。
