Rook v0.8釋出：存儲編排器的架構！

我們很高興地宣布Rook的v0.8版本！這是該項目的一個重要裡程碑，引入了一個內建多個存儲提供程式的架構。這将使這些存儲團隊在将解決方案內建到雲原生環境中時更容易建立可靠且使用者友好的體驗。為CockroachDB和Minio添加了兩個新的存儲提供程式，社群正在努力添加其他，包括NFS、Cassandra、Nexenta和Alluxio。

Rook的第一個存儲提供程式已經成熟：我們很高興地宣布Ceph Custom Resource Definition（CRD）已經更新到Beta——這顯示出我們對穩定版本的可靠性和更新的承諾。

我們為不斷增長的社群和許多依賴Kubernetes存儲解決方案的人提供支援，特别是自1月份加入CNCF以來。基于v0.8所取得的令人興奮的進步，我們目前正在提議将CNCF中的Rook項目從沙箱階段更新到孵化階段。請與我們聯系，分享你使用Rook的體驗，以幫助加強提案！

我們要感謝社群的支援！在所有不斷增長的名額中，這裡隻是一些亮點：10M + Docker pull、3100+ Github star、83個Github貢獻者。

存儲提供程式架構

為了繼續Rook作為Kubernetes存儲提供程式編排器的願景，我們已經擴充到編排Ceph之外。其他存儲提供程式也需要與Kubernetes CRD深度內建才能被視為“一等公民”。Rook的存儲提供程式架構以多種方式提供幫助：

存儲資源規範化：原始磁盤和目錄的本地存儲資源管理為所有存儲提供程式提供了一緻的體驗。

operator模式和管道：Rook使用operator模式使存儲資源成為Kubernetes中的一等公民，這意味着它們可以從ubectl進行本地管理，就像任何其他内置的Kubernetes資源一樣。

通用規範、政策和邏輯：架構既可以代表存儲提供程式處理實作，也可以為使用者建立一緻的體驗。

測試工作：所有能使存儲提供程式與雲原生環境更容易內建的通用模式、規範和邏輯也将通過自動化內建測試進行良好的測試和審查。

現在讓我們更多地了解與Rook內建的存儲提供程式。

CockroachDB

CockroachDB是一個雲原生SQL資料庫，用于建構可在災難中幸存的全球可擴充雲服務。通過建立資料庫所需的服務，Rook将幫助你開始使用CockroachDB。你所要做的就是按照此簡單指南建立叢集以建立Cluster CRD，然後Rook operator将啟動叢集。

Minio

Minio是與Amazon S3雲存儲服務相容的對象存儲伺服器。建立Minio對象服務所需要做的就是按照本指南建立Object Store CRD。Rook operator将啟動服務讓你進入對象商店！

正在開發的提供程式

其他提供程式處于不同的發展階段。

NFS正在被加緊開發，以便使用NFS伺服器暴露存儲。

Nextenta、Alluxio和Cassandra已被社群提議與Rook整合。設計正在進行中。

我們期待聽到社群成員對更多存儲提供程式的意見，我們可以共同合作！

版本控制

為了支援Ceph CRD的Beta聲明以及多個存儲提供程式，CRD已被分解為獨立的API組：rook.io、ceph.rook.io、cockroachdb、rook.io和minio.rook.io。每個組都将使用相應的CRD進行版本控制。是以，Ceph CRD在此版本中已被宣布為Beta，而其他CRD仍為alpha。

改進的安全模型

在此版本中，Rook的安全模型得到了顯著改善。在這些更改之前，Rook operator基本上必須為你的Kubernetes叢集提供完全管理者特權。使用新的安全模型，運作Rook operator所需的特權受到更多限制。Rook不再需要特權來建立叢集角色、角色或角色綁定。不是由operator建立角色和綁定，而是被分解到清單中，以使叢集管理者完全可見并控制Rook可以做什麼。這些變化具有以下優點：

所需的角色和綁定在叢集管理者建立的清單中是聲明性的。管理者可以控制在必要時建立或删除角色和綁定。

Rook operator隻能控制管理者授予的命名空間中的叢集。operator不需要通路所有命名空間來管理秘密、pod和其他資源。

管理附加和安裝存儲的叢集範圍内的特權盡可能最小。管理者甚至可以确定在不需要安裝存儲的某些情況下特權不是必需的。例如，對象存儲不需要這些特權。

即使安全模型有所改進，請記住，Rook仍然需要比普通應用程式更多的特權。運作存儲平台需要使用特權模式、主機PID和主機網絡通路硬體。随着時間的推移，當我們離開flex驅動程式，轉向CSI并使用本地存儲PVC而不是主機路徑時，我們将削減這些特權。

Ceph CRD beta版

Rook通過Custom Resource Definition（CRD）和operator将Ceph帶入Kubernetes的容器化和編排的世界，讓存儲成了Kubernetes的一等公民。 Rook的Ceph編排已經得到改進，我們很高興宣布它處于beta。這證明了社群對幫助我們驗證系統品質的支援。

這究竟意味着什麼？ 對我們來說，beta意味着：

對Ceph CRD的支援将從v0.8開始。不允許對CRD進行重大更改。從一個版本到下一個版本的更新将完全得到支援。

Ceph的Rook部署的品質已經提高到我們确信它們可以在生産場景中被信任的程度。

更新自動化将成為下一個裡程碑的功能。将不再需要以前版本的繁瑣手動更新指南。

這是讓Rook的Ceph編排穩定的一個重要步驟。我們期待你的支援和回報！

此版本中的Ceph operator還有許多其他改進，我們也會進行讨論。

提高OSD的可靠性

v0.8中最大的架構變化之一是Rook如何處理存儲以建立存儲網絡。Rook在每個節點上編排存儲的方式現在更可靠。

現在，operator可以完全控制你希望使用的儲存設備并單獨進行配置。這意味着許多不同的pod允許operator編排存儲。每個OSD将獨立運作，不受可能需要配置或重新啟動的其他OSD的影響。OSD pod也被命名為與其OSD ID相對應，以便使用Ceph工具進行更輕松的故障排除。有關更改的更多詳細資訊，請參閱設計文檔。

支援OpenShift

改進的聲明性安全模型的一個好處是我們現在支援OpenShift。在聲明所需的安全上下文限制以授予對運作有特權的通路主機PID和主機網絡的通路權限之後，可以在OpenShift中運作。有了這些限制，Rook将像任何其他Kubernetes部署一樣提供你的存儲平台。

其他改進

除了上面描述的大功能之外，v0.8裡程碑還有很多改進。總結一些顯性的改進：

Ceph Dashboard預設啟用，提供管理UI來檢視Ceph存儲叢集的基本狀态。

Ceph工具可用以便從Ceph pod運作，包括operator和mons。Ceph工具是管理底層存儲叢集的首選，而不是現在已被删除的rookctl工具和Rook API。

Ceph容器鏡像現在基于CentOS 7而不是Ubuntu。

如果你想了解有關更改的更多詳細資訊，請浏覽Github上v0.8裡程碑頁面上的完整清單。

下一步是什麼？

随着Rook社群的蓬勃發展，前途充滿希望。我們鼓勵并歡迎大家與我們互動，共同指導社群的發展方向。你可以通過以下方式去我們取得聯系：Rook網站、Github、推特、Slack、Youtube、電子郵件。