在Kubernetes中運行OpenEBS

什么是OpenEBS？

現在，OpenEBS是kubernetes下與容器原生和容器附加存儲類型相關通用的領先開源項目之一。 通過為每個工作負載指定專用的存儲控制器，OpenEBS遵循容器附加存儲或CAS的腳步。 為了向用戶提供更多功能，OpenEBS具有精細的存儲策略和隔離功能， 可幫助用戶根據工作負載選擇存儲。該項目不依賴Linux內核模塊，而是在用戶空間中運行。 它屬於Cloud Native Computing Foundation沙箱，在各種情況下都非常有用，例如在公共雲中運行的群集， 在隔離環境中運行的無間隙群集以及本地群集。

什么是CAS？

首先，CAS是Container Attached Storage的縮寫。通常，Kubernetes存儲在集群環境之外維護。 無論共享文件系統如何，存儲設施始終與外部資源相關，包括Amazon EBS，GCE PD，NFS，Gluster FS和Azure 磁盤等存儲巨頭。在大多數情況下，存儲通常以OS內核模塊的形式與節點相關。這也適用於永久卷，在永久卷中， 它們與模塊緊密耦合，因此顯示為舊版資源和整體式。CAS提供的是Kubernetes使用諸如微服務之類的存儲實體的便利。 總體而言，CAS分為兩個元素，即數據平面和控制平面。

另一方面，控制平面控制一組CRD或Custom Resource Definitions，並涉及低級別的存儲實體。 數據平面和控制平面之間的這種清晰的分離為用戶提供了與Kubernetes中的微服務相同的優勢。 這種獨特的架構通過使存儲實體與持久性脫鈎，從而有助於工作負載的可移植性。這種體系結構的另一個好處是， 它允許操作員和管理員根據工作量動態調整卷的大小。這也稱為橫向擴展功能。

這種結構將計算（Pod）和數據（P）置於超融合模式，在這種模式下，它們具有較高的容錯能力和良好的吞吐量。

是什么使OpenEBS與其他存儲解決方案不同？

使OpenEBS與傳統存儲引擎大不相同的一些品質是：

• 就像它所服務的應用程序一樣，OpenEBS具有構建的微服務架構。在部署OpenEBS時， 它們作為容器安裝到Kubernetes的工作程序節點。此外，該系統管理其組件並使用Kubernetes進行編排。
• 可移植性是OpenEBS作為開放源代碼存儲選項的優良品質，因為它是完全內置的用戶空間。 這使其容易出現跨平台問題。
• Kubernetes的使用使該系統非常有意圖驅動，因為它遵循有助於提高客戶可用性的原則。
• 談到可用性功能，使用OpenEBS的另一個好處是，它允許用戶從各種存儲引擎中進行選擇。 這意味着一個人可以使用與其應用程序的設計和目標兼容的存儲引擎。無論引擎的類型如何， OpenEBS都提供了一個強大的框架，該框架具有良好的可管理性，快照，可用性和克隆。例如， Cassandra是需要低延遲寫入的分布式應用程序。因此，它可以使用本地PV引擎。同樣， 建議將ZFS引擎用於需要彈性的整體式應用程序，例如PostgreSQL和MySQL。對於流應用程序 ，專業人士經常建議使用稱為MayaStor的NVMe引擎，該引擎可保證最佳性能。

部署OpenEBS之后，您可以獲得許多存儲服務，包括：

• 在連接到Kubernetes的工作節點上，使存儲管理自動化。這將使您可以使用該存儲來動態配置本地PV和OpenEBS PV。
• 跨節點的數據持久性得到了改善，這有助於用戶節省通常在重建時浪費的時間。例如，卡桑德拉響。
• 雲提供商和可用性區域之間的數據將正確同步。此類功能有助於提高所需數據的可用性，並減少連接和分離時間。
• 這有點像用戶的通用層，因此他們可以體驗到相同級別的存儲服務以及良好的開發人員和布線設施。是否使用裸機，AKS，AWS或GKE都沒有關系。
• 由於OpenEBS屬於Kubernetes原生解決方案，因此管理員與開發人員之間進行交互的機會更大， 這有助於管理OpenEBS。他們可以使用Helm，Prometheus，Kubectl，Grafana和Weave Scope等各種工具。
• 正確管理與S3和其他目標之間的來回分層過程。

開放式EBS架構

我們已經知道OpenEBS屬於CAS或容器附加存儲模型。用此模型維護其結構，OpenEBS系統的每個卷都有一個指定 的控制器POD和一組重復的POD。我們已經討論了CAS系統背后的思想，因此我們可以說CAS系統的整體體系結構有助於 使OpenEBS成為用戶友好的系統。人們認為OpenEBS在操作過程中非常簡單，就像來自Kubernetes的其他任何雲原 生項目一樣。

這是OpenEBS架構圖。相應地繪制了所有重要功能，我們將對其進行簡要討論。

 

 

OpenEBS系統包含許多組件。總體而言，它們可以分為以下幾類。

• 控制平面：包括API服務器，預配器，卷小車和卷導出之類的細分。
• 數據平面：Jiva，cStor和LocalPV
• 節點磁盤管理器：監視，發現和管理連接到Kubernetes節點的媒體。
• 雲原生工具集成：集成通過Grafana，Jaeger，Prometheus和Fluentd完成。

OpenEBS的控制平面

OpenEBS集群的另一個術語是"Maya"。控制平面有多種功能。其中一些功能包括配置卷， 與卷關聯的操作（如克隆制作，快照快照，存儲策略實施，存儲策略創建，卷指標的導出）， 以便Prometheus/Grafana可以使用它們以及許多其他功能。

 

 

標准的Kubernetes存儲插件是動態預配器，OpenEBS PV預配器的主要任務是根據Kubernetes用於PV實施 規范並啟動卷預配。當涉及批量策略管理和批量處理任務時，m-apiserver有助於公開存儲REST API。 當我們查看數據平面和控制平面之間的連接時，我們可以看到一個sidecar模式。我們有一些數據平面必 須與控制平面通信時的條件示例。

• 對於吞吐量，延遲和IOPS等卷統計信息。在此，使用了volume-exporter 邊車。
• 在卷副本容器的幫助下進行磁盤或池管理，在卷控制器容器的幫助下執行卷策略。在這里，使用了音量管理小車。

讓我們談談控制平面的上述組件：

 

 

該組件的主要功能是在作為POD運行時做出供應決策。工作機制也非常簡單。首先，開發人員提出具有必要體積參數的 聲明，然后選擇正確的存儲類別。最后，他或她在YAML規范上調用Kubelet。在這里，maya-apiserver和 OpenEBS PV供應商相互交互，並創建節點上的卷副本容器和卷控制器容器所需的部署規范。 使用PVC規范中的注釋來控制體積容器的調度。根據當前統計，OpenEBS僅支持iSCSI綁定。

 

 

m-apiserver的主要任務是公開OpenEBS REST API，並且它以POD的形式運行。如果需要創建卷容器， 則m-apiserver會生成部署規范所需的文件。然后，根據情況調度pod並調用kube-apiserver。 該過程完成后，將創建對象PV，然后將其安裝在應用程序容器上。然后，控制器盒與副本盒的幫助一起托管PV。 副本容器和控制器容器都是數據平面的重要部分。

m-apiserver的另一項主要任務是卷策略的管理。在提供策略時，OpenEBS通常使用精細的規范。 然后，m-apiserver使用YAML規范的這些解釋將它們轉換為可執行的組件。在那之后，它們通過音量管理側邊欄得 到了強制執行。

Maya Volume Exporter

每個存儲控制器pod，即cStor和Jiva，都有一個稱為Maya卷導出器的sidecar。這些邊車的功能是通過將數 據平面與控制平面相連來幫助檢索信息。如果我們查看統計信息的粒度，則它始終處於卷級別。統計信息的一些示例是：

• Volume write latency
• Volume read latency
• Write IOPS
• Read IOPS
• Write block size
• Read block size
• Capacity status

 

 

volume manauagement sidecar

邊車的主要功能有兩個：一是將卷策略和控制器配置參數傳遞到卷控制器容器或數據平面。 另一個是傳遞副本配置參數以及卷副本容器的數據保護參數的副本。

 

 

OpenEBS的數據平面

OpenEBS架構最喜歡的一件事是它向用戶提供的與存儲引擎相關的功能。它為用戶提供了根據工作負載的配置 和特征來配置其存儲引擎的選擇。例如，如果您具有基於IOPS的高數據庫，則可以從讀取繁重的共享CM S工作負載中選擇其他存儲引擎。因此，數據平面為用戶提供了三種存儲引擎選擇：Jiva，cStor和Local PV。

cStor是OpenEBS提供的最受歡迎的存儲引擎選項，其中包括豐富的存儲引擎和輕量級的功能。這些功能 對於類似HA工作負載的數據庫特別有用。您通過此選項獲得的功能是企業級的。其中一些是按需容量和性能提升， 高數據彈性，數據一致性，同步數據復制，克隆，快照和精簡數據提供。cStor同步復制的單個副本可提供高可用性的 有狀態Kubernetes部署。當從應用程序請求數據的高可用性時，cStor會生成3個副本，其中數據以同步順序寫入。 此類復制有助於保護數據丟失。

Jiva是OpenEBS最早的存儲引擎，使用非常簡單。之所以如此方便，部分原因在於該引擎完全根據用戶空間的標准運行， 並具有標准的塊存儲容量，例如同步復制。如果您的小型應用程序沒有添加塊存儲設備的選項，那么Jiva可能是您的 正確選擇。考慮到這一點，事實也恰恰相反，這意味着該引擎對於需要高級存儲和高性能功能的工作負載效率不高。

繼續使用OpenEBS的最簡單的存儲引擎是Local PV或Local Persistent Volume。它只是一個直接連接到單個 Kubernetes節點的磁盤。對熟悉的API的這種使用意味着Kubernetes可以在此過程中提取高性能的本地存儲。 概括整個概念，OPenEBS的Local PV將幫助用戶在節點上創建持久的本地磁盤或路徑卷。這對於不需要高級存儲 功能（例如克隆，復制和快照）的應用程序（例如雲原生應用程序）非常有用。例如，對於基於OpenEBS的本地PV的配置， 可以使用同時處理HA和復制的StatefulSet。

| 快照和克隆支持 | 基本的 | 高級 | 沒有 | | ------------- | ----- |----- | --- | | 資料一致性 | 是 | 是 | 不適用 | 使用Velero備份和還原 | 是 | 是 | 是 | 適合大容量工作負載 | 是 | 是 | 精簡配置 | 是 | 沒有 | 磁盤池或聚合支持 | 是 | 沒有 | 按需擴容 | 是 | 是 | 數據彈性（RAID支持） | 是 | 是* | 近磁盤性能 | 沒有 | 沒有 | 是

我們有三個當前可用的存儲引擎，但這並不意味着它們是唯一的選擇。實際上，OpenEBS社區目前正在開發新引擎。 它們仍然是原型，需要在進入市場之前進行適當的測試。例如，MayaStor是一種數據引擎，可能很快就會投放市場。 它是用Rust編寫的，具有低延遲引擎，對於需要API訪問以訪問塊存儲和接近磁盤性能的應用程序非常有幫助。此外， 與本地PV相關的問題已經過測試，以ZFS本地PV為名稱的變體因克服了這些缺點而獲得了一些認可。

節點設備管理器

在Kubernetes中工作時，在有狀態應用程序的情況下管理持久性存儲的任務由各種工具完成。NDM或節點設備管理器 就是一種可以填補這一空白的工具。DevOps架構師必須以保持一致性和彈性的方式提供應用程序開發人員和應用程序本身的基礎設施需求。為了做到這一點，存儲堆棧的靈活性必須很高，以便雲原生生態系統可以輕松使用堆棧。在這種情況下，NDM的功能非常方便，它可以將單獨的磁盤組合在一起，並賦予它們將它們分段存儲的能力。NDM通過將磁盤標識為Kubernetes對象來實現此目的。它還有助於管理Kubernetes PV供應商（如OpenEBS，Prometheus和其他系統）的磁盤子系統。

 

 

與雲原生工具的集成

Grafana和Prometheus： Prometheus的安裝是在OpenEBS運營商作為微服務的一部分進行的初始設置期間進行的。音量策略負責根據給定的音量控制Prometheus監視。總體而言，Prometheus和Grafana工具共同幫助OpenEBS社區監視持久性數據。

WeaveScope：如果需要查看與容器，進程，主機或服務相關的標簽，元數據和度量，則使用WeaveScope。因此，在Kubernetes中將它作為雲原生可視化解決方案的重要組成部分。對於WeaveScope集成，將啟用諸如卷Pod，節點磁盤管理器組件以及與Kubernetes相關的其他類型的存儲結構之類的東西。所有這些增強功能都有助於遍歷和探索這些組件。

數據如何受到保護？

Kubernetes有許多方法可以保護數據。例如，如果IO容器與iSCSI目標一起發生故障，則它會被Kubernetes旋轉回去。將相同的原理應用於存儲數據的副本容器。OpenEBS可以借助可配置的仲裁或副本的最低要求來保護多個副本。cStor具有其他功能，可以檢查靜默數據的損壞，並可以在將其隱藏在后台的同時對其進行修復。

如何安裝和入門

首先要做的是確認iSCSI客戶端設置。通過使用必要的iSCSI協議，OpenEBS為用戶提供了塊卷支持。因此，必須在安裝期間所有Kubernetes節點都具有iSCSI啟動器。根據您的操作系統，有多種方法可以驗證iSCSI客戶端安裝。如果尚未安裝，我們以Ubuntu用戶的整個過程為例：

正如我們已經討論的那樣，為使OpenEBS系統正常運行，需要確保iSCSI服務在所有輔助節點上運行。請按照以下步驟在Linux平台（Ubuntu）中啟動該過程。

配置：

如果您的系統中已經安裝了iSCSI啟動器，請使用以下給定命令檢查啟動器名稱的配置和iSCSI服務的狀態：

sudo cat /etc/iscsi/initiatorname.iscsi
systemctl status iscsid

成功運行命令后，系統將顯示服務是否正在運行。如果狀態顯示為“非活動”，則鍵入以下命令以重新啟動iscsid服務：

sudo systemctl enable iscsid 
sudo systemctl start iscsid

如果提供正確的命令，那么系統將為您提供以下輸出：

systemctl status iscsid
● iscsid.service - iSCSI initiator daemon (iscsid)
   Loaded: loaded (/lib/systemd/system/iscsid.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-02-18 11:00:07 UTC; 1min 51s ago
     Docs: man:iscsid(8)
  Process: 11185 ExecStart=/sbin/iscsid (code=exited, status=0/SUCCESS)
  Process: 11170 ExecStartPre=/lib/open-iscsi/startup-checks.sh (code=exited, status=0/SUCCESS)
 Main PID: 11187 (iscsid)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/iscsid.service
           ├─11186 /sbin/iscsid
           └─11187 /sbin/iscsid

如果您未在節點上安裝iSCSI啟動器，請在以下命令的幫助下轉到“ open-iscsi”軟件包：

sudo apt-get update
sudo apt-get install open-iscsi
sudo systemctl enable iscsid 
sudo systemctl start iscsid

如果在他們的系統上預先安裝了Kubernetes環境，則他或她可以借助以下命令輕松地部署

OpenEBS：

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

之后，您可以開始針對OpenEBS運行工作負載。實際上，有許多工作負載使用OpenEBS的存儲類。不，您不必非常特定於存儲類。這是簡單的方法，但是，花一些時間選擇特定的存儲類將幫助您節省時間，從長遠來看還有助於自定義工作負載。默認的OpenEBS回收策略與K8所使用的相同。“刪除”是動態配置的PersistentVolume的默認回收策略。它們在某種意義上是相關的，如果一個人刪除了相應的PersistentVolumeClaim，則動態配置的卷將被自動刪除。對於cStor卷，則數據隨之刪除。對於jiva（0.8.0版及更高版本），清理作業將執行數據刪除工作。

kubectl delete job <job_name> -n <namespace>

在配置Jiva和cStor卷之前，您應該做的第一件事是驗證iSCSI客戶端。話雖這么說，始終建議用戶完成iSCSI客戶端的設置，並確保iscsid服務運行良好並在每個工作節點上運行。這是正確正確地安裝OpenEBS安裝程序所必需的。

另外，請記住，如果要安裝OpenEBS，則必須具有集群管理員用戶上下文。如果您沒有集群管理員用戶上下文，則創建一個上下文並在該過程中使用它。對於創建，可以使用以下命令。

kubectl config set-context NAME [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]

這是上述命令的示例：

kubectl config set-context admin-ctx --cluster=gke_strong-eon-153112_us-central1-a_rocket-test2 --user=cluster-admin

之后，鍵入以下命令來設置新創建的上下文或現有的上下文。請參閱以下示例

kubectl config use-context admin-ctx

通過helm安裝過程

在啟動該過程之前，請檢查您的系統中是否安裝了helm，並且helm存儲庫需要任何更新。

對於Helm的v2版本：

首先，運行命令helm init，將分till pod安裝在“ kube-system”命名空間下，然后按照下面給出的說明為分till設置RBAC。要獲取helm已安裝版本，用戶可以鍵入以下命令：

helm version

這是輸出示例：

Client: &version.Version{SemVer:"v2.16.1", GitCommit:"bbdfe5e7803a12bbdf97e94cd847859890cf4050", GitTreeState:"clean"}

如果使用默認模式進行安裝，請使用下面給出的命令在“ openebs”命名空間中安裝OpenEBS：

helm install --namespace openebs --name openebs stable/openebs --version 1.10.0

對於Helm v3版本：

您可以在以下命令的幫助下獲取helm v3版本的預安裝版本：

helm version

這是輸出示例：

version.BuildInfo{Version:"v3.0.2", GitCommit:"19e47ee3283ae98139d98460de796c1be1e3975f", GitTreeState:"clean", GoVersion:"go1.13.5"}

在helm v3的幫助下，可以通過兩種方式安裝OpenEBS。讓我們一一討論。

第一種選擇：在這種方法中，helm從本地kube配置獲取當前的名稱空間，並在用戶決定運行helm命令時稍后使用它。如果不存在，則掌舵將使用默認名稱空間。首先，借助以下命令將openebs與openebs命名空間一起安裝：

您可以使用以下代碼行查看當前上下文：

kubectl config current-context

為當前上下文分配名稱openebs並鍵入以下內容：

kubectl config set-context <current_context_name> --namespace=openebs

要創建OpenEBS名稱空間：

kubectl create ns openebs

然后以openebs作為圖表名稱安裝OpenEBS。使用以下命令：

helm install openebs stable/openebs --version 1.10.0

最后，寫下以下代碼以查看chart：

helm ls

通過執行上述步驟，您將安裝帶有openebs名稱空間的OpenEBS，該名稱空間的圖表名稱為openebs。

第二個選項：第二個選項是關於直接在helm命令中提及名稱空間。定期執行以下步驟進行安裝。

為OpenEBS創建名稱空間

kubectl create ns openebs

使用圖表名稱openebs，安裝openebs系統。命令如下：

helm install --namespace openebs openebs stable/openebs --version 1.10.0

helm install –namespace openebs openebs stable/openebs –version 1.10.0

要查看chart，請使用以下代碼：

helm ls -n openebs

之后，您將獲得帶有chart名稱和名稱空間openebs的OpenEBS安裝版本。

您需要注意一些事項：

• 從Kubernetes的1.12版本開始，容器必須設置其極限值和資源請求，否則容器將被逐出。在安裝之前，我們建議讀者首先在YAML運算符中將值設置為OpenEBS pod spec。
• 在安裝OpenEBS操作員之前，請檢查節點上塊設備的安裝狀態。

如果繼續使用自定義安裝模式，則會遇到以下高級配置：

• 您可以為OpenEBS控制平面pod選擇節點。
• 節點選擇也可用於OpenEBS存儲池。
• 如果不需要磁盤過濾器，則可以簡單地排除它們。
• 在OpenEBS運營商YAML中，有一個配置環境變量是可選的。
• 如果您想采用自定義安裝方式，則需要下載openebs-operator-1.10.0，更新配置，然后使用“ kubectl”命令。

設置控制平面的節點選擇器

如果您有一個很大的Kubernetes集群，則可以故意將OpenEBS控制平面的調度過程限制為僅幾個特定節點。對於此過程，應該指定鍵值對的映射，然后找到所需的群集節點以標簽的形式附加相同的鍵值對。

為准入控制設置節點選擇器

准入控制器的作用是在對象持久化之前截取已提交給Kubernetes的API服務器的請求。僅在授權或驗證請求后才能執行此操作。為了驗證傳入請求，openebs准入控制器制定其他自定義准入策略。例如，這是最新版本的兩種准入策略。

• 如果存在PersistentVolumeClaim的克隆，則通過刪除PersistentVolumeClaim來完成驗證。
• 為了驗證請求的聲明容量，該大小必須變為快照大小，並由Clone PersistentVolumeClaim創建。

我們可以使用節點選擇器方法來調度特定節點上的准入控制器容器。

對於節點磁盤管理器節點選擇器設置

對於OpenEBS cStorPool的構建，可以使用塊設備自定義資源，也可以使用節點磁盤管理器創建塊設備。如果您想過濾掉Kubernetes中的集群並且僅將某些節點用於OpenEBS存儲，則指定鍵值對並將相同的鍵值以標簽的形式附加到必要的節點即可。

節點磁盤管理器磁盤篩選器設置

NDM的默認功能是分離出下面給出的磁盤模式，然后將在特定節點上發現的其余磁盤模式轉換為DISK CR。問題是，不應安裝它們。

如果群集中還有其他類型的磁盤尚未過濾掉，您要做的就是將其他磁盤模式包括到排除列表中。該列表位於YAML文件中。

"exclude":"loop,/dev/fd0,/dev/sr0,/dev/ram,/dev/dm-"

配置環境變量

在環境變量主題下，提供了與默認cStor稀疏池，本地PV基本路徑，默認存儲配置和cStor Target相關的配置。

啟用核心轉儲：

對於NDM守護程序集和cStor池容器，轉儲核心被禁用為默認設置的一部分。要啟用此功能，您需要將ENV變量“ ENABLE_COREDUMP”設置為1。然后您要做的就是在cStor池中部署ENV設置以在cStor池pod中啟用轉儲核心，並將ENV設置放入ndm守護程序規范中daemonset pod核心轉儲。

- name: ENABLE_COREDUMP
value: "1"

稀疏目錄：

SparseDir只是用於查找稀疏文件的hostPath目錄。默認情況下，該值設置為“ / var / openebs / sparse”。在應用OpenEBS運算符YAML文件之前，應將某些配置添加為maya-apiserver規范中環境變量的一部分。

# environment variable
 - name: SparseDir
   value: "/var/lib/"

cStorSparsePool默認

根據配置值，OpenEBS安裝過程將創建一個默認的cStor稀疏池。該配置完全取決於true和false的值。如果為true，則將配置cStor稀疏池，否則將不會進行配置。配置的默認值始終為false，此稀疏池僅用於測試目的。如果要使用稀疏磁盤安裝cStor，則應在Maya-apiserver規范中以環境變量的形式添加此特定配置。這是一個例子：

# environment variable
- name: OPENEBS_IO_INSTALL_DEFAULT_CSTOR_SPARSE_POOL
  value: "false"

TargetDir

目標目錄用作目標容器的hostPath，其默認值設置為“ / var / openebs”。該預值將覆蓋主機路徑，並在maya-apiserver部署中引入OPENEBS_IO_CSTOR_TARGET_DIR ENV。當主機操作系統無法在默認的OpenEBS路徑（即（/ var / openebs /））上寫入時，通常需要這種類型的配置。與cStor SparsePool一樣，應在應用操作員YAML文件之前將某些配置作為環境變量添加到maya-apiserver規范中。這是一個例子：

# environment variable
- name: OPENEBS_IO_CSTOR_TARGET_DIR
  value: "/var/lib/overlay/openebs"

OpenEBS本地PV基本路徑

對於基於主機路徑的localPV，默認的hospath為/ var / openebs / local。以后可以在OpenEBS operator的安裝過程中對此進行更改。您要做的就是傳遞OPENEBS_IO_BASE_PATH ENV參數。

# environment variable
 - name: OPENEBS_IO_BASE_PATH
   value: "/mnt/"

默認存儲配置：

Jiva和本地PV存儲類是OpenEBS隨附的一些默認存儲配置。可以根據需要配置和定制OpenEBS中的存儲引擎，並通過關聯的自定義資源和存儲類來完成。在安裝過程之后，您始終可以更改存儲的默認配置，但是它會被API服務器覆蓋。因此，我們通常建議用戶在默認選項的幫助下創建自己的存儲配置。如果在安裝過程中禁用默認配置，則可以進行自己的存儲配置類型。若要正確禁用默認配置，請在Maya-apiserver中將以下代碼行添加為環境變量。

# environment variable
- name: OPENEBS_IO_CREATE_DEFAULT_STORAGE_CONFIG
  value: "false"

驗證安裝過程

要使用命名空間獲取Pod列表，請使用以下代碼：

kubectl get pods -n openebs

如果成功安裝了OpenEBS，則很可能會看到以下示例所示的輸出：

 

 

openebs-ndm引用守護程序集，該守護程序集應在集群的所有節點上運行，或者至少在nodeSelector配置期間選擇的節點上運行。同樣，maya-apiserver，openebs-snapshot-operator和openebs-provisioner控制平面容器也應該正在運行。如果已經配置了nodeSelector，請確保將它們安排在正確的節點上。為此，請使用“ Kubectly get pods -n openebs -o wide”列出容器。

驗證存儲類：

首先，通過列出以下內容檢查OpenEBS是否已安裝默認存儲類：

kubectl get sc

供您參考，以下是成功安裝后將看到的輸出示例。您將找到創建的給定StorageClasses：

 

 

驗證塊設備CR

對於NDM守護程序集創建的每個塊設備CR，發現的節點具有以下兩個例外：

• 與排除供應商過濾器和“路徑過濾器”匹配的磁盤。
• 節點上已經掛載的磁盤。

要檢查CR是否如預期的那樣來臨，請使用以下命令列出塊設備CR。

kubectl get blockdevice -n openebs

如果以正確的方式進行操作，屏幕上將顯示類似的輸出：

 

 

之后，使用以下命令檢查節點上的標簽集，以找到節點的相應塊設備CR。

kubectl describe blockdevice <blockdevice-cr> -n openebs

驗證Jiva默認池

kubectl get sp

達到上述要求后，您可能會看到以下輸出：

 

 

安裝后要考慮的事項

安裝后，可以使用以下存儲類來簡單地測試OpenEBS：

• 要配置Jiva卷，請使用openebs-jiva-default。在這里，使用默認池，並在mnt/openebs_disk目錄下創建數據的副本。該目錄位於Jiva副本窗格中。
• 要在主機路徑上配置本地PV，請使用openebs-host路徑。
• 要在設備上配置本地PV，請使用openebs-device。

要使用實際磁盤，必須首先根據要求創建Jiva池，cStorPools或OpenEBS Local PV。之后，創建所需的StorageClasses或使用默認的StorageClasses進行使用。

原文地址： https://goglides.io/running-openebs-in-kubernetes/371/