原文來自：
https://blog.fleeto.us/post/kubernetes-storage-performance-comparison/
摘要
本文展示了一個簡單的存儲對比，使用未經性能優化的多種存儲提供的存儲捲進行測試和比較。
忽略 Azure 的原生 PVC 或 hostPath ，我們可以得出如下測試結果：
- Portworx 是 AKS 上最快的容器存儲。
- Ceph 是私有云集群上最快的開源存儲後端。對公有云來說，其操作太過複雜，這些多餘的複雜性並沒有能提供更好的測試表現。
- OpenEBS 的概念很棒，但是其後端需要更多優化。
如果你正在運行 Kubernetes，你可能正在使用，或者準備使用動態供給的塊存卷 ，而首當其衝的問題就是為集群選擇合適的存儲技術。這個事情並不能用一個簡單的測試來做出簡單的回答，告訴你目前市面上最好的技術是什麼。存儲技術的選擇過程中，集群上運行的負載類型是一個重要的輸入。對於裸金屬集群來說，需要根據實際用例進行選擇，並集成到自己的硬件之中。公有云中的託管 K8s，例如 AKS、EKS 或者 GKE，都具有開箱可用的塊存儲能力，然而這也不見得就是最好的選擇。有很多因素需要考慮，比如說公有云的 StorageClass 的故障轉移時間太長。例如在 一個針對 AWS EBS 的故障測試中，加載了卷的 Pod 用了超過五分鐘才成功的在另一個節點上啟動。Portworx 或者 OpenEBS 這樣的雲原生存儲產品，正在嘗試解決這類問題。
本文的目標是使用最常見的 Kubernetes 存儲方案，進行基本的性能對比。我覺得在 Azure AKS 上使用下列後端：
- AKS 原生 Storageclass：Azure native premium
- 使用 cStor 後端的 OpenEBS
- Portworx
- Heketi 管理的 Gluster
- Rook 管理的 Ceph
現在我們來介紹每種存儲後端，並交代一下安裝過程，然後進入 AKS 測試環境進行測試，最後得出結果。
存儲
這一節中介紹測試中用到的存儲方案，包含安裝過程以及該方案的優缺點。
Azure 原生 StorageClass
我選擇這一方案的動機是以此作為所有測試的基線。這個方案 應該 提供最佳性能。Azure 動態的創建託管磁盤，並把它們映射到 K8s 的虛擬機中，最終成為 Pod 的存儲卷。
這個方案很方便，什麼多餘的步驟都不需要。創建一個新的 AKS 集群之後，就自動提供了兩個預定義的 StorageClass，分別是 default 和 managed-premium ，premium 使用的是基於 SSD 的高性能低延遲磁盤。
<code>$ kubectl get storageclasses
NAME PROVISIONER AGE
default(default) kubernetes.io/azure-disk 8m
managed-premium kubernetes.io/azure-disk 8m
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
dbench-pv-claim Bound pvc-e7bd34a4-1dbd-11e9-8726-ae508476e8ad 1000Gi RWO managed-premium 10s
$ kubectl get po
NAME READY STATUS RESTARTS AGE
dbench-w7nqf 0/1ContainerCreating029s/<code>
優點
AKS 開箱即用。
缺點
故障轉移非常緩慢，有時需要十分鐘以後，存儲卷才能重新掛載到不同節點上的 Pod 裡。
OpenEBS
對我來說 OpenEBS 是個全新事物，因此我很有興趣做他的測試。他提出了一個新的 Container Attached Storage（容器掛載存儲） 概念，這是一個基於微服務的存儲控制器，以及多個基於微服務的存儲副本。他和 Portworx 同樣，屬於雲原生存儲分類的成員。
它是一個完全開源的方案，目前提供兩種後端——Jiva 和 cStor。我最開始選擇的是 Jiva，後來切換到 cStor。cStor 有很多長處，例如他的控制器和副本被部署到單一的 OpenEBS 所在的命名空間之中，能夠管理原始磁盤等。每個 K8s 卷都有自己的存儲控制器，能在節點存儲容量的許可範圍內對存儲進行擴展。
在 AKS 上運行
在 AKS 上的安裝非常容易。
- 連接到所有 K8s 節點上，安裝 iSCSI，這是因為他需要使用 iSCSI 協議在 K8s 節點之間進行 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 控制器發現了節點中的所有磁盤。但是我必須手工標識出我附加的 AWS 託管磁盤。$ kubectl get disk NAME AGE disk-184d99015253054c48c4aa3f17d137b15m disk-2f6bced7ba9b2be230ca5138fd0b07f15m disk-806d3e77dd2e38f188fdaf9c46020bdc5m
- 然後把這些磁盤加入 StoragePoolClaim，這個對象會在 StorageClass 中進行引用：--- 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 來動態的創建存儲捲了。
優點
- 開源
- Maya 在資源使用的可視化方面做得非常好。可以在 K8s 中部署多個服務，方便的為集群的各方面數據設置監控和日誌。對於排錯工作來說，這十分重要。
- CAS 概念：我非常欣賞這一概念，我相信這是未來的趨勢。
- OpenEBS 社區：在社區中我的任何問題都能在幾分鐘內得到解決。Slack 上的團隊非常有幫助。
缺點
- 不成熟：OpenEBS 還很年輕，目前還沒有發佈穩定版。核心團隊還在進行後端的優化，未來幾個月裡會對性能做出很大提升。
- Kubelet 和存儲控制器之間的 iSCSI 連接是通過 K8s Service 進行的，這在 Tungsten Fabric 之類的 CNI 插件環境中可能會出問題。
- 需要在 K8s 節點上安裝額外的軟件（iSCSI），這對於託管集群來說非常不便。
注：OpenEBS 團隊對我的案例場景進行了調整：
https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench
Portworx
Portworx 是另一個面向 Kubernetes 的容器原生存儲方案，它專注於高度分佈式的環境。這是一個主機可尋址的存儲，每個卷都直接映射到掛在的主機上。他提供了基於應用 I/O 類型的自動微調能力。 官方網站 提供了更多信息。不幸的是，它也是本文中唯一的非開源產品。然而它提供了 3 節點的免費試用。
在 AKS 上運行
在 AKS 上的安裝同樣簡單，我用了他們 網站 提供的生成器。
<code>azure0/<code>
<code>$ kubectl get pods -o wide -n kube-system -l name=portworx
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
portworx-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>/<none>/<none>/<code>
為 PVC 創建一個 StorageClass，定義高優先級，以及三個副本：
<code>root@aks-agentpool-20273348-0:~# kubectl get storageclass -o yaml portworx-sc
apiVersion: storage.k8s.io/v1
kind:StorageClass
metadata:
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-a23b1ec87092
parameters:
priority_io: high
repl:"3"
provisioner: kubernetes.io/portworx-volume
reclaimPolicy:Delete
volumeBindingMode:Immediate/<code>
優點
- 部署方便：生成器包含配置細節。
- 不像 Ceph 和 Glusterfs 那樣需要進行額外配置。
- 雲原生存儲：公有云和裸金屬都可以運行。
- 存儲級別感知和應用感知的 I/O 微調。
缺點
- 閉源：商業解決方案
GlusterFS Heketi
GlusterFS 是知名的開源存儲方案，是由 Redhat 提供的開源存儲方案。 Heketi 是 GlusterFS 的 RESTful 卷管理界面。它提供了易用的方式為 GlusterFS 卷提供了動態供給的功能。如果沒有 Heketi 的輔助，就只能手工創建 GlusterFS 卷並映射到 K8s PV 了。關於 GlusterFS 的更多信息，請閱讀 官方文檔 。
在 AKS 上運行
根據 Heketi 的 快速入門 文檔進行部署。
- 參照 樣例 ，創建一個包含磁盤和主機名的拓撲文件。
- Heketi 主要的開發和測試都在基於 RHEL 的操作系統上，我在 AKS 上使用 Ubuntu 主機時，出現了內核模塊路徑錯誤的問題，我提交了一個 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 環境中遇到的另一個問題是一個非空磁盤，所以我用 wipefs 為 glusterfs 進行清理。這個磁盤並未用過。 $ wipefs -a /dev/sdc /dev/sdc: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31
- 最後運行 gk-deploy -g -t topology.json ，會在每個節點上運行 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 來創建存儲卷。
<code>$ 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 pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
glusterfs-efb3b155 10Gi RWX RetainAvailable/<code>
然後把現存 PV 映射為 PVC，加載給測試 工具 進行測試。
<code>kind:PersistentVolumeClaim
apiVersion: v1
metadata:
name: glusterfs-efb3b155
spec:
accessModes:
-ReadWriteMany
storageClassName:""
resources:
requests:
storage:10Gi
volumeName: glusterfs-efb3b155/<code>
<code>$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
glusterfs-efb3b155 Bound glusterfs-efb3b155 10Gi RWX 36m/<code>
Heketi 的更多輸出：
<code>$ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849
VolumeName: vol_efb3b15529aa9aba889d7900f0ce9849
Type:ReplicateVolume ID:96fde36b-e389-4dbe-887b-baae32789436
Status:StartedSnapshotCount:0Number of Bricks:1 x 3=3Transport-type: tcp
Bricks:Brick1:10.0.1.66:/var/lib/heketi/mounts/vg_5413895eade683e1ca035760c1e0ffd0/brick_cd7c419bc4f4ff38bbc100c6d7b93605/brick
Brick2:10.0.1.35:/var/lib/heketi/mounts/vg_3277c6764dbce56b5a01426088901f6d/brick_6cbd74e9bed4758110c67cfe4d4edb53/brick
Brick3:10.0.1.4:/var/lib/heketi/mounts/vg_29d6152eeafc57a707bef56f091afe44/brick_4856d63b721d794e7a4cbb4a6f048d96/brick
OptionsReconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
heketi ClusterIP192.168.101.75<none>8080/TCP 5h
heketi-storage-endpoints ClusterIP192.168.103.66<none>1/TCP 5h
$ kubectl get endpoints
NAME ENDPOINTS AGE
heketi 10.0.1.69:80805h
heketi-storage-endpoints 10.0.1.35:1,10.0.1.4:1,10.0.1.66:15h
kubernetes 172.31.22.152:4431d
root@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yaml
apiVersion: v1
kind:Endpoints
metadata:
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-a23b1ec87092
subsets:- addresses:
- ip:10.0.1.35
- ip:10.0.1.4
- ip:10.0.1.66
ports:
- port:1
protocol: TCP/<none>/<none>/<code>
優點
- 久經考驗的存儲方案。
- 比 Ceph 輕量。
缺點
- Heketi 在公有云上表現不佳。在私有云上表現良好，安裝會方便一些。
- 並非為結構化數據設計，例如 SQL 數據庫。然而可以使用 GlusterFS 為 數據庫 提供備份和恢復支持。
Ceph Rook
我在 OpenStack 私有云上嘗試過安裝和運行 Ceph。它需要為特定硬件定製參數，根據數據類型設計 pg 組、SSD 分區和 CRUSH 圖等。所以第一次聽說在 3 節點的 K8s 集群上運行 Ceph 的時候，我不太相信它能工作。結果 Rook 的編排工具讓我印象深刻，它把所有的步驟和 K8s 的編排能力結合在一起，讓安裝變得非常簡便。
在 AKS 上運行
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 中指定要使用的設備，這裡是 /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: ~~~
- 安裝之後，創建一個 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
- 最後使用部署 工具 進行檢查。
<code>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,3in
data:
pools:0 pools,0 pgs
objects:0 objects,0 B
usage:3.0GiB used,3.0TiB/3.0TiB 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 |+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+/<code>
優點
- 在大型生產環境上的健壯存儲系統。
- Rook 很好的簡化了生命週期管理。
缺點
- 複雜：更加重量級，也不太適合在公有云上運行。在私有云上的運行可能更加合適。
AKS 測試環境
我用 3 個虛擬機創建了基本的 Azure AKS 集群。為了連接到 Premium SSD 上，我只能使用 type E 以上級別的虛擬機。因此我選擇了 Standard_E2s_v3 ，其上配備了 2 vCPU 以及 16GB 的內存。
在 AKS 集群所在的資源足中，可以看到所有的虛擬機、網絡接口等資源。在這裡創建 3 個 1TB 的 Premium SSD 存儲，並手工掛載到每個虛擬機上。
這樣在每個實例上，我都有 1TB 的空磁盤。Azure 的頁面上，根據我們選擇的虛擬機和磁盤尺寸來看，性能應該有 5000 IOPS 以及 200MB/s 的吞吐量。最後一節會顯示我們的真實結果。
性能結果
注意：每種存儲的結果並不能作為獨立的評估結果，但是其比較情況是可以參考的。有很多種對比測試的方法，這是最簡單的一種。
為了運行測試，我決定使用現成的測試工具 Dbench ，它是一個 k8s 的 YAML 文件，會使用 FIO 運行 8 個測試用例。可以在 Dockerfile 中 指定不同測試 ：
- 隨機讀寫帶寬。
- 隨機讀寫 IOPS。
- 讀寫延遲。
- 順序讀寫。
- 混合讀寫 IOPS。
所有測試的結果可以在 Github 上找到。
隨機讀寫帶寬
隨機讀寫測試表明，GlusterFS、Ceph 以及 Portworx 的讀取性能比 AWS 本地盤的 hostPath 快了幾倍。讀緩存是罪魁禍首。GlusterFS 和 Portworx 的寫入更快，其效率直逼本地磁盤。
隨機讀寫 IOPS
隨機 IOPS 測試中，Portworx 和 Ceph 表現最好。Portworx 在寫入方面獲得了接近 Azure 原生 PVC 的 IOPS。
讀寫延遲
延遲測試的結果比較有趣，Azure 原生 PVC 比多數其它存儲都差。Portworx 和 Ceph 表現最好。寫入方面，GlusterFS 要優於 Ceph。OpenEBS 的延遲相對來說非常的高。
順序讀寫
順序讀寫的結果和前面的隨機測試差不多，然而 Cpeh 在讀取方面比 GlusterFS 快了一倍多。寫入結果基本一致，只有 OpenEBS 表現奇差。
混合讀寫 IOPS
最後一個測試用例檢查的是混合讀寫情況下的 IOPS，Portworx 和 Ceph 都給出了優於 Azure 原生 PVC 的結果。
結論
本文展示了一個簡單的存儲對比，使用未經性能優化的多種存儲提供的存儲捲進行測試和比較。建議關注本文所述方法，不建議直接採用結果進行判斷。
忽略 Azure 的原生 PVC 或 hostPath ，我們可以得出如下測試結果：
- Portworx 是 AKS 上最快的容器存儲。
- Ceph 是私有云集群上最快的開源存儲後端。對公有云來說，其操作太過複雜，這些多餘的複雜性並沒有能提供更好的測試表現。
- OpenEBS 的概念很棒，但是其後端需要更多優化。
調整性能數據的測試規模應該會很有意思。另外值得關注的對比就是 CPU 和內存的消耗。我會持續關注，並分享更多。
原文鏈接：https://blog.fleeto.us/post/kubernetes-storage-performance-comparison/
閱讀更多 啟迪雲Tuscloud 的文章
