1. 程式人生 > >探討容器中使用塊儲存_Kubernetes中文社群

探討容器中使用塊儲存_Kubernetes中文社群

塊儲存是將裸磁碟空間通過劃邏輯盤,做Raid,或者LVM(邏輯卷)等方式邏輯劃分出N個邏輯的硬碟,然後採用對映的方式將這些邏輯盤掛載到主機。主機的作業系統認為這些磁碟均為物理硬碟,跟直接拿一塊物理硬碟掛載到作業系統沒有區別。

塊儲存的優點不言而喻:

1. 使用了Raid與LVM等手段,可以多資料做冗餘保護;

2. 可以使用磁碟陣列,組成大容量的邏輯盤對外提供服務,提高容量;

3. 對邏輯盤寫資料可轉化為對幾塊物理磁碟的並行寫入,提升了讀寫效率。

需求

在IaaS中,塊儲存被廣泛應用於為虛擬機器提供持久卷。虛擬機器故障後依然能夠通過在其他虛擬機器上掛載舊資料卷的方式來訪問磁碟資料,因此被普遍認可。受此影響,一些客戶在設計PaaS時,自然而然的聯想到共享儲存的這一優勢,提出在PaaS中為容器掛載塊儲存的需求。

但是,憑藉在IaaS中的卓越表現,塊儲存也能夠躋身PaaS業務中嗎?

分析

假設已有一套可提供RBD塊儲存的Ceph叢集的前提下,我們先來分析幾個場景:

場景一

“我使用容器技術,但還不是深度使用者,只使用docker run之類的命令來手工啟動單個容器,這些容器中執行的服務都比較消耗磁碟空間。”

這類使用者侷限於將容器作為一個臨時工具,並沒有將其與業務緊密結合。
1. 如果對磁碟沒有持久化的需求,那麼在主機磁碟空間空餘足夠的情況下可以考慮直接對映宿主機檔案系統。

2. 若想讓磁碟獨佔共享磁碟,或希望在不同宿主機上啟用容器時,均能重複使用之前訪問過的資料卷;此時可以在啟動docker時,指定volume-driver為ceph-rbd的方式來使用由Ceph叢集提供的塊儲存。

塊儲存驅動框架圖如下所示:

20161130180314

場景二

“我使用容器編排工具來管理應用,比如docker-compose、Rancher或Kubernetes。但我在每一個service下只需要啟用一個container,且對service沒有擴容的需求;這些service都比較消耗磁碟,我希望在容器被重啟或重新排程後,仍可使用舊的資料盤。”

該場景比較特殊,每一個service只對應一個container。因此,不會有多個container同時讀寫一塊資料盤的需求,只需保障container之前所掛載的儲存卷在container故障恢復或正常遷移後依然能夠被container訪問即可;即儲存卷對容器的自動跟隨。

遷移場景如下圖所示:

20161130180338

但是,值得注意的是:

1. 假設之前的container執行在host-1上,對應的,塊儲存就掛載在host-1上。

2. 當原有container因故被排程到新的host-2上時,編排框架檢測到該變化,將host-1上的原有塊裝置解除安裝,然後掛載到host-2。

3. 按照該流程,塊儲存的每一次遷移都需要從一臺主機上解除安裝,再到另外一臺主機上掛載;新container的啟動依賴於volume,因此容器或者業務的恢復速度依賴於塊儲存的遷移速度。

4. 假設平臺未能及時檢測到host-1上的container故障、舊有的container卡死無法快速銷燬,或者host-1突然斷電時,Ceph Server必須等待超時後,才允許host-2重新掛載之前被使用的RBD塊。此時,container啟動時間就會變得難以忍受,顯然這是與容器的秒起秒停的優勢相互違背的。

場景三

我使用Rancher或者Kubernetes之類的容器編排軟體來管理應用,每一個應用有多個微服務;每一個微服務又對應多個容器來並行對外提供服務。

Rancher

在Rancher裡面,應用被稱之為Stack,每一個stack包含一到多個service; service即微服務,微服務之間按照單一職責劃分,只做一件事情。service屬於邏輯的概念,真正做事的是各service對應的containers。如果希望通過為service擴容,就增加service對應的container數量;這些container無狀態,可被排程到多臺宿主機上,它們必須使用共享儲存來保障業務的持續性。

Kubernetes

在Kubernetes中,業務也是由一到多個service來共同完成的,這裡的service與Rancher中service的概覽類似。Kubernetes的service是一個外部訪問點(endpoint),通過selector指定labels的方式可以選定一組pods,service為這組pods提供訪問代理和負載均衡。外部的客戶端只需知道service所暴露的埠和IP就能夠訪問到業務。由於pod是無狀態的,因此同Rancher一樣,也需要將業務資料儲存到共享儲存上,還必須保障同一個service對應的多個pods均能共享該業務資料。

20161130180346

限於塊儲存只能同時被一個客戶端(主機)所掛載,當service的多個containers或pods排程到多臺主機上時,塊儲存就難以應付了。此時,原始共享檔案系統的方法又體現出了它的優勢,NAS會是一個最好的選擇!