隨著像Kubernetes這樣的容器編排工具的大火，應用程序的開發與部署方式正經歷著一場巨大的變革。微服務體系結構的興起，以及從開發人員的角度，將基礎架構與應用程序邏輯間相互解耦，使得開發人員越來越關注于構建軟件和交付價值。

站在用戶的角度思考問題，與客戶深入溝通，找到卡若網站設計與卡若網站推廣的解決方案，憑借多年的經驗，讓設計與互聯網技術結合，創造個性化、用戶體驗好的作品，建站類型包括：做網站、成都網站設計、企業官網、英文網站、手機端網站、網站推廣、域名與空間、網絡空間、企業郵箱。業務覆蓋卡若地區。

　　Kubernetes能夠將它所管理的物理機抽象出來，借此，開發人員可以通過描述所需的內存數量和計算能力，獲取相應的資源，而不必考慮底層基礎設施。

　　在管理Docker映像時，Kubernetes還能夠為應用程序提供可移植性。一旦使用Kubernetes的容器架構開發應用程序，它們就可以部署到任何地方——公共云、混合云、本地——而且不需要對底層代碼進行任何更改。

　　雖然Kubernetes在許多方面非常有優勢，比如可伸縮性、可移植性和管理能力，但它也存在一個問題，就是不支持狀態存儲。幾乎所有的生產應用都是有狀態的，即需要某種外部存儲。

　　而Kubernetes的架構是動態的，容器的創建和銷毀取決于負載以及開發人員規范，Pod和容器可以自我修復和復制。本質上來說，它們的生命是短暫的。

　　然而，持久存儲解決方案無法承受這種動態行為，持久存儲不能被綁定到動態創建和銷毀的規則上。

　　當需要將有狀態的應用程序部署到另一個基礎設施(可能是另一個云服務提供商、本地或混合云)上時，它們在可移植性上面臨著挑戰。持久存儲解決方案會被捆綁到特定的云提供商上。

　　此外，云原生應用程序的存儲環境并不容易理解。Kubernetes的存儲術語可能會令人綱到困惑，因為許多術語都有復雜的含義和微妙的變化。此外，在原生Kubernetes、開源框架和托管或付費服務之間有許多選項，開發人員在做出決定之前必須考慮這些選項。

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

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

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

　　對于數據庫，狀態往往需要被保存。如果以容器方式部署在集群上的數據庫沒有遷移，或者沒有頻繁地spin up，那么數據存儲的物理特性就會發揮作用。理想情況下，使用數據的容器應該與數據庫位于同一個Pod中。

　　這并不是說在容器中部署數據庫是一個壞主意——在某些用例中，這種方法就足夠了。在測試環境中，或者對于那些不需要生產級別的數據量的任務，集群中的數據庫是有意義的，因為所保存的數據規模很小。

　　 在生產環境中，開發人員通常比較依賴外部存儲。

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

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

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

　　 原生Kubernetes及存儲

　　原生Kubernetes如何處理存儲?Kubernetes提供了一些管理存儲的解決方案:臨時選項、持久卷的持久存儲、持久卷聲明、存儲類或狀態集……等等。

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

　　另外，持久卷聲明(PVC)是對存儲的請求。使用PVC可以將存儲綁定到特定節點，使該節點能夠使用存儲。

　　處理存儲的方法有兩種:靜態或動態。

　　通過靜態配置，管理員提供了他們認為Pod在發出實際請求之前可能需要的PV，并且這些PV通過顯式PVC手動綁定到特定的Pod。

　　在實踐中，靜態定義的PV與Kubernetes的可移植結構不兼容，因為所使用的存儲可能與環境相關，比如AWS EBS或GCE持久磁盤。手動綁定需要更改YAML文件以指向特定于提供商的存儲解決方案。

　　在開發人員如何考慮資源方面，靜態配置也違背了Kubernetes的思想:CPU和內存不是預先分配的，而是綁定到Pod或容器中，它們是動態授予的。

　　動態配置是通過存儲類完成的。集群管理員不需要預先手動創建PV，而是創建多個存儲配置文件，就像模板一樣。當開發人員創建PVC時，根據請求的要求，其中一個模板在請求時創建，并附加到Pod。

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

　　 容器存儲接口

　　首先介紹一下容器存儲接口(Container Storage Interface，CSI)，CSI是由CNCF存儲工作組進行的統一工作，旨在定義一個標準的容器存儲接口，該接口可以使存儲驅動程序在任何容器編排器上工作。

　　CSI規范已經被應用到Kubernetes中，許多驅動程序插件可以部署在Kubernetes集群上。開發人員可以在Kubernetes上訪問CSI兼容的卷驅動程序與CSI卷類型公開的存儲。

　　隨著CSI的引入，存儲可以作為另一個工作負載進行容器化，并部署在Kubernetes集群上。

　　 開源項目

　　圍繞云原生技術的工具和項目正在大量涌現。作為生產中最突出的問題之一，有相當一部分開源項目致力于解決“在云原生架構上處理存儲”這個問題。

　　目前最受歡迎的存儲項目是 Ceph 和 Rook 。

　　Ceph是一個動態管理的、水平可伸縮的分布式存儲集群。Ceph提供了對存儲資源的邏輯抽象。它被設計成不存在單點故障、可自我管理和基于軟件的。Ceph同時為相同的存儲集群提供塊、對象或文件系統接口。

　　Ceph的架構非常復雜，有許多底層技術，如RADOS、librados、RADOSGW、RDB，它的CRUSH 算法和監視器、OSD和MDS等組件。這里不深入解讀其架構，關鍵在于，Ceph是一個分布式存儲集群，它可提供更高的可伸縮性，在不犧牲性能的情況下消除了單點故障，并提供了對對象、塊和文件的訪問的統一存儲。

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

Ceph架構

　　另一個有趣且非常受歡迎的項目是Rook，這是一個旨在聚合Kubernetes和Ceph的工具——將計算和存儲放在一個集群中。

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

　　Rook允許從YAML部署Ceph集群，像Kubernetes一樣。YAML文件用作集群管理員希望在集群中實現的高級聲明。Rook會啟動集群，并開始積極監視。Rook充當控制器，確保YAML文件中聲明的所需狀態是支持的。Rook運行在一個協調循環中，該循環會觀察狀態并根據檢測到的差異進行操作。

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

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

　　作為被CNCF接受的首個存儲項目，Rook近期已進入孵化階段。

　　最后，對于應用程序中的任何問題，重要的是確定需求，并相應地設計系統或選擇工具。云原生環境中的存儲也不例外。雖然問題相當復雜，但是有很多工具和方法。隨著云計算的發展，無疑也會不斷出現新的解決方案。

　　來源：Software Engineering Daily 作者：Gokhan Simsek

網站題目：為什么Kubernetes的存儲如此艱難?-創新互聯
網站URL：http://vcdvsql.cn/article42/ggghc.html

成都網站建設公司_創新互聯，為您提供虛擬主機、品牌網站建設、服務器托管、外貿建站、Google、面包屑導航

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯