為什么Kubernetes的存儲(chǔ)如此艱難?

　　 隨著像Kubernetes這樣的容器編排工具的大火，應(yīng)用程序的開發(fā)與部署方式正經(jīng)歷著一場(chǎng)巨大的變革。微服務(wù)體系結(jié)構(gòu)的興起，以及從開發(fā)人員的角度，將基礎(chǔ)架構(gòu)與應(yīng)用程序邏輯間相互解耦，使得開發(fā)人員越來越關(guān)注于構(gòu)建軟件和交付價(jià)值。

　　Kubernetes能夠?qū)⑺芾淼奈锢頇C(jī)抽象出來，借此，開發(fā)人員可以通過描述所需的內(nèi)存數(shù)量和計(jì)算能力，獲取相應(yīng)的資源，而不必考慮底層基礎(chǔ)設(shè)施。

　　在管理Docker映像時(shí)，Kubernetes還能夠?yàn)閼?yīng)用程序提供可移植性。一旦使用Kubernetes的容器架構(gòu)開發(fā)應(yīng)用程序，它們就可以部署到任何地方——公共云、混合云、本地——而且不需要對(duì)底層代碼進(jìn)行任何更改。

　　雖然Kubernetes在許多方面非常有優(yōu)勢(shì)，比如可伸縮性、可移植性和管理能力，但它也存在一個(gè)問題，就是不支持狀態(tài)存儲(chǔ)。幾乎所有的生產(chǎn)應(yīng)用都是有狀態(tài)的，即需要某種外部存儲(chǔ)。

　　而Kubernetes的架構(gòu)是動(dòng)態(tài)的，容器的創(chuàng)建和銷毀取決于負(fù)載以及開發(fā)人員規(guī)范，Pod和容器可以自我修復(fù)和復(fù)制。本質(zhì)上來說，它們的生命是短暫的。

　　然而，持久存儲(chǔ)解決方案無法承受這種動(dòng)態(tài)行為，持久存儲(chǔ)不能被綁定到動(dòng)態(tài)創(chuàng)建和銷毀的規(guī)則上。

　　當(dāng)需要將有狀態(tài)的應(yīng)用程序部署到另一個(gè)基礎(chǔ)設(shè)施(可能是另一個(gè)云服務(wù)提供商、本地或混合云)上時(shí)，它們?cè)诳梢浦残陨厦媾R著挑戰(zhàn)。持久存儲(chǔ)解決方案會(huì)被捆綁到特定的云提供商上。

　　此外，云原生應(yīng)用程序的存儲(chǔ)環(huán)境并不容易理解。Kubernetes的存儲(chǔ)術(shù)語可能會(huì)令人綱到困惑，因?yàn)樵S多術(shù)語都有復(fù)雜的含義和微妙的變化。此外，在原生Kubernetes、開源框架和托管或付費(fèi)服務(wù)之間有許多選項(xiàng)，開發(fā)人員在做出決定之前必須考慮這些選項(xiàng)。

　　下面是 CNCF(云原生計(jì)算基金會(huì)) 公布的云原生存儲(chǔ)解決方案一覽圖(其中一部分，具體可點(diǎn)擊鏈接查看):

　　可能大家首先想到的是在Kubernetes中部署數(shù)據(jù)庫:選擇滿足你需要的數(shù)據(jù)庫解決方案，將其容器化以在本地磁盤上運(yùn)行，并將其作為另一個(gè)工作負(fù)載部署到集群中。然而，由于數(shù)據(jù)庫的固有屬性，這并不能很好地工作。

　　容器是基于無狀態(tài)原則構(gòu)建的，這使得容器的spin up和spin down更容易。由于沒有要保存和遷移的數(shù)據(jù)，所以集群不需要處理磁盤讀寫這種通常來說非常密集的工作。

　　對(duì)于數(shù)據(jù)庫，狀態(tài)往往需要被保存。如果以容器方式部署在集群上的數(shù)據(jù)庫沒有遷移，或者沒有頻繁地spin up，那么數(shù)據(jù)存儲(chǔ)的物理特性就會(huì)發(fā)揮作用。理想情況下，使用數(shù)據(jù)的容器應(yīng)該與數(shù)據(jù)庫位于同一個(gè)Pod中。

　　這并不是說在容器中部署數(shù)據(jù)庫是一個(gè)壞主意——在某些用例中，這種方法就足夠了。在測(cè)試環(huán)境中，或者對(duì)于那些不需要生產(chǎn)級(jí)別的數(shù)據(jù)量的任務(wù)，集群中的數(shù)據(jù)庫是有意義的，因?yàn)樗４娴臄?shù)據(jù)規(guī)模很小。

　　 在生產(chǎn)環(huán)境中，開發(fā)人員通常比較依賴外部存儲(chǔ)。

　　Kubernetes如何與存儲(chǔ)通信?使用控制平面接口。這些接口將Kubernetes與外部存儲(chǔ)連接起來。這些連接到Kubernetes的外部存儲(chǔ)解決方案稱為卷插件(Volume Plugin)，卷插件支持抽象存儲(chǔ)并賦予存儲(chǔ)可移植性。

　　以前，卷插件是與核心的Kubernetes代碼庫一起構(gòu)建、鏈接、編譯和發(fā)布的。這大大限制了開發(fā)人員的靈活性，并帶來了額外的維護(hù)成本。添加新的存儲(chǔ)選項(xiàng)需要更改Kubernetes代碼庫。

　　隨著CSI和Flexvolume的引入，卷插件可以部署在集群上，而無需更改代碼庫。

　　 原生Kubernetes及存儲(chǔ)

　　原生Kubernetes如何處理存儲(chǔ)?Kubernetes提供了一些管理存儲(chǔ)的解決方案:臨時(shí)選項(xiàng)、持久卷的持久存儲(chǔ)、持久卷聲明、存儲(chǔ)類或狀態(tài)集……等等。

　　持久卷(PV)是由管理員提供的存儲(chǔ)單元，它們獨(dú)立于任何單個(gè)Pod，這樣可以將它們從Pod短暫的生命周期中解放出來。

　　另外，持久卷聲明(PVC)是對(duì)存儲(chǔ)的請(qǐng)求。使用PVC可以將存儲(chǔ)綁定到特定節(jié)點(diǎn)，使該節(jié)點(diǎn)能夠使用存儲(chǔ)。

　　處理存儲(chǔ)的方法有兩種:靜態(tài)或動(dòng)態(tài)。

　　通過靜態(tài)配置，管理員提供了他們認(rèn)為Pod在發(fā)出實(shí)際請(qǐng)求之前可能需要的PV，并且這些PV通過顯式PVC手動(dòng)綁定到特定的Pod。

　　在實(shí)踐中，靜態(tài)定義的PV與Kubernetes的可移植結(jié)構(gòu)不兼容，因?yàn)樗褂玫拇鎯?chǔ)可能與環(huán)境相關(guān)，比如AWS EBS或GCE持久磁盤。手動(dòng)綁定需要更改YAML文件以指向特定于提供商的存儲(chǔ)解決方案。

　　在開發(fā)人員如何考慮資源方面，靜態(tài)配置也違背了Kubernetes的思想:CPU和內(nèi)存不是預(yù)先分配的，而是綁定到Pod或容器中，它們是動(dòng)態(tài)授予的。

　　動(dòng)態(tài)配置是通過存儲(chǔ)類完成的。集群管理員不需要預(yù)先手動(dòng)創(chuàng)建PV，而是創(chuàng)建多個(gè)存儲(chǔ)配置文件，就像模板一樣。當(dāng)開發(fā)人員創(chuàng)建PVC時(shí)，根據(jù)請(qǐng)求的要求，其中一個(gè)模板在請(qǐng)求時(shí)創(chuàng)建，并附加到Pod。

　　以上只是對(duì)外部存儲(chǔ)一般如何使用原生Kubernetes進(jìn)行處理的一個(gè)非常寬泛的概述，除此之外，還有許多其他選擇需要考慮。

　　 容器存儲(chǔ)接口

　　首先介紹一下容器存儲(chǔ)接口(Container Storage Interface，CSI)，CSI是由CNCF存儲(chǔ)工作組進(jìn)行的統(tǒng)一工作，旨在定義一個(gè)標(biāo)準(zhǔn)的容器存儲(chǔ)接口，該接口可以使存儲(chǔ)驅(qū)動(dòng)程序在任何容器編排器上工作。

　　CSI規(guī)范已經(jīng)被應(yīng)用到Kubernetes中，許多驅(qū)動(dòng)程序插件可以部署在Kubernetes集群上。開發(fā)人員可以在Kubernetes上訪問CSI兼容的卷驅(qū)動(dòng)程序與CSI卷類型公開的存儲(chǔ)。

　　隨著CSI的引入，存儲(chǔ)可以作為另一個(gè)工作負(fù)載進(jìn)行容器化，并部署在Kubernetes集群上。

　　 開源項(xiàng)目

　　圍繞云原生技術(shù)的工具和項(xiàng)目正在大量涌現(xiàn)。作為生產(chǎn)中最突出的問題之一，有相當(dāng)一部分開源項(xiàng)目致力于解決“在云原生架構(gòu)上處理存儲(chǔ)”這個(gè)問題。

　　目前最受歡迎的存儲(chǔ)項(xiàng)目是 Ceph 和 Rook 。

　　Ceph是一個(gè)動(dòng)態(tài)管理的、水平可伸縮的分布式存儲(chǔ)集群。Ceph提供了對(duì)存儲(chǔ)資源的邏輯抽象。它被設(shè)計(jì)成不存在單點(diǎn)故障、可自我管理和基于軟件的。Ceph同時(shí)為相同的存儲(chǔ)集群提供塊、對(duì)象或文件系統(tǒng)接口。

　　Ceph的架構(gòu)非常復(fù)雜，有許多底層技術(shù)，如RADOS、librados、RADOSGW、RDB，它的CRUSH 算法和監(jiān)視器、OSD和MDS等組件。這里不深入解讀其架構(gòu)，關(guān)鍵在于，Ceph是一個(gè)分布式存儲(chǔ)集群，它可提供更高的可伸縮性，在不犧牲性能的情況下消除了單點(diǎn)故障，并提供了對(duì)對(duì)象、塊和文件的訪問的統(tǒng)一存儲(chǔ)。

　　很自然地，Ceph已經(jīng)適應(yīng)了云原生環(huán)境。有許多方法可以部署Ceph集群，例如使用Ansible。你可以使用CSI和PVC部署Ceph集群，并在Kubernetes集群中獲得一個(gè)接口。

Ceph架構(gòu)

　　另一個(gè)有趣且非常受歡迎的項(xiàng)目是Rook，這是一個(gè)旨在聚合Kubernetes和Ceph的工具——將計(jì)算和存儲(chǔ)放在一個(gè)集群中。

　　Rook是一個(gè)云原生存儲(chǔ)編排器，它擴(kuò)展了Kubernetes的功能。Rook本質(zhì)上允許將Ceph放入容器中，并提供集群管理邏輯，使得在Kubernetes上能夠可靠地運(yùn)行Ceph。Rook能夠自動(dòng)化部署、引導(dǎo)、配置、伸縮、再平衡，即集群管理員會(huì)做的一系列工作。

　　Rook允許從YAML部署Ceph集群，像Kubernetes一樣。YAML文件用作集群管理員希望在集群中實(shí)現(xiàn)的高級(jí)聲明。Rook會(huì)啟動(dòng)集群，并開始積極監(jiān)視。Rook充當(dāng)控制器，確保YAML文件中聲明的所需狀態(tài)是支持的。Rook運(yùn)行在一個(gè)協(xié)調(diào)循環(huán)中，該循環(huán)會(huì)觀察狀態(tài)并根據(jù)檢測(cè)到的差異進(jìn)行操作。

　　Rook沒有自己的持久狀態(tài)，無需管理，可見它確實(shí)是按照Kubernetes的原則建立的。

　　Rook將Ceph和Kubernetes結(jié)合在一起，是最受歡迎的云原生存儲(chǔ)解決方案之一，在Github上擁有近4000顆星，1630萬次下載，以及100多名貢獻(xiàn)者。

　　作為被CNCF接受的首個(gè)存儲(chǔ)項(xiàng)目，Rook近期已進(jìn)入孵化階段。

　　最后，對(duì)于應(yīng)用程序中的任何問題，重要的是確定需求，并相應(yīng)地設(shè)計(jì)系統(tǒng)或選擇工具。云原生環(huán)境中的存儲(chǔ)也不例外。雖然問題相當(dāng)復(fù)雜，但是有很多工具和方法。隨著云計(jì)算的發(fā)展，無疑也會(huì)不斷出現(xiàn)新的解決方案。

　　來源：Software Engineering Daily 作者：Gokhan Simsek