① K8s怎麼對象分布式存儲
K8s對象分布式存儲的方式很多，我們用的元核雲分布式塊存儲，用的就是ceph-csi對接的他們的rbd塊存儲。
② 深挖Kubernetes存儲為何如此難及其解決方案
以Kubernetes為代表的容器編排工具在應用開發部署領域起正發揮著顛覆性的變革作用。隨著微服務架構的發展，從開發人員的角度來看，應用邏輯架構與基礎設施架構之間開始解耦，這意味著開發者能夠將精力更多集中在軟體構建以及價值交付身上。
當管理Docker鏡像的時候，Kubernetes也讓實際應用變的十分便捷靈活。在利用Kubernetes進行容器架構的應用部署時，管理員們將在無需修改底層代碼的前提下將其部署在任何位置——包括公有雲、混合雲乃至私有雲。
雖然Kubernetes在擴展性、便攜性與管理性等方面的表現都相當給力，但截至目前，它仍然不支持存儲狀態。與之對應的是，如今的大多數應用都是有狀態的——換言之，要求在一定程度上配合外部存儲資源。
Kubernetes架構本身非常靈活的，能夠根據開發者的需求、規范以及實際負載情況，對容器進行隨意創建與撤銷。此外，Pod和容器還具有自我修復與復制能力。因此從本質上講，它們的生命周期普遍非常短暫。
但是，現有持久存儲解決方法無法支持動態的應用場景，而持久化存儲也無法滿足動態創建與撤銷的需求。
當我們需要將有狀態應用部署到其它基礎架構平台，或者另一家內部或混合雲供應商的環境中時，可移植性低下無疑將成為我們面臨的巨大挑戰。更具體地講，持久化存儲解決方案往往會鎖定於特定雲服務供應商，而無法靈活完成轉移。
另外，雲原生應用中的存儲機制也相當復雜、難於理解。Kubernetes中的不少存儲術語極易混淆，其中包含著復雜的含義與微妙的變化。再有，在原生Kubernetes、開源框架以及託管與付費服務之間還存在著諸多選項，這極大增加了開發人員在做出決定之前的考量與試驗成本。
以下是CNCF列出的雲原生存儲可選方案：
我們首先從最簡單的場景出發，即在Kubernetes當中部署一套資料庫。具體流程包括：選擇一套符合需求的資料庫，讓它在本地磁碟上運行，然後將其作為新的工作負載部署到集群當中。但是，由於資料庫中存在的一些固有屬性，這種方式往往無法帶來符合預期的效果。
容器本身是基於無狀態原則進行構建的，憑借這一天然屬性，我們才能如此輕松地啟動或撤銷容器環境。由於不存在需要保存及遷移的數據，集群也就不需要同磁碟讀寫這類密集型操作綁定在一起了。
但對於資料庫，其狀態必須隨時保存。如果以容器方式部署在集群當中的資料庫不需要進行遷移，或者不需要頻繁開關，那麼其基本屬性就相當於一種物理存儲設備。在理想情況下，使用數據的容器應該與該資料庫處於同一Pod當中。
當然，這並不是說將資料庫部署在容器中的作法不可取。在某些應用場景下，這樣的設計完全能夠滿足需求。舉例來說，在測試環境或者處理非生產級數據時，由於總體數據量很小，將資料庫納入集群完全沒有問題。但在實際生產中，開發人員往往需要仰仗於外部存儲機制。
Kubernetes到底是如何與存儲資源彼此通信的？其利用的是控制層介面。這些介面負責將Kubernetes與外部存儲相對接。接入Kubernetes的外部存儲解決方案被稱為「卷插件（Volume Plugins）」。正是有了卷插件的存在，存儲資源才得以抽象化並實現可移植性。
以前，卷插件一般由核心Kubernetes代碼庫進行構建、鏈接、編譯以及裝載。這樣就極大的限制了開發人員的發揮空間，同時也帶來了額外的維護開銷。因此，項目維護人員們決定在Kubernete的代碼庫上增加一些新的存儲功能。
隨著CSI以及Flexvolume的引入，卷插件如今可以在集群中直接部署，而完全無需更改代碼庫。
原生Kubernetes與存儲
持久卷是由管理員負責配置的存儲單元，它們獨立於任何單一Pod之外，因此不受Pod生命周期的影響。
存儲資源有兩種使用方式：靜態存儲與動態存儲。
實際上，靜態定義的持久卷並不能適應Kubernetes的可移植特性，因為存儲資源具有對環境的依賴性——例如AWS EBS或者GCE Persistent Disk。另外，手動綁定還需要根據不同供應商的存儲方案修改YAML文件。
在資源分配方面，靜態配置實際上也違背了Kubernetes的設計原則。後者的CPU與內存並非事先被分配好綁定在Pod或者容器上，而是以被動態形式進行分配。
通過簡單的說明，相信大家已經了解了原生Kubernetes對外部存儲資源的使用方式。當然，這里僅僅做出概括，實際使用場景中還有更多其它因素需要考量。
CSI——容器存儲介面
下面來看容器存儲介面（簡稱CSI）。CSI是由CNCF存儲工作組創建的統一標准，旨在定義一個標準的容器存儲介面，從而使存儲驅動程序能夠在任意容器架構下正常起效。
CSI規范目前已經在Kubernetes中得到普及，大量驅動插件被預先部署在Kubernetes集群內供開發人員使用。如此一來，我們就可以利用Kubernetes上的CSI卷來訪問與CSI兼容的開放存儲卷。
CSI的引入，意味著存儲資源能夠作為Kubernetes集群上的另一種工作負載實現容器化以及部署。
相關開源項目
目前，圍繞雲原生技術涌現出大量工具與項目。但作為生產場景中的一大突出問題，我們往往很難在雲原生架構中選擇最合適的開源項目。換言之，解決方案選項太多，反而令存儲需求變得更難解決。
我們再看一次CNCF列出的雲原生存儲的可選方案：
下面我會分享一下當下流行的存儲方案Ceph與Rook，還有Rancher開源的容器化分布式存儲Longhorn。
Ceph
Ceph是一種動態託管、橫向擴展的分布式存儲集群。Ceph面向存儲資源提供一種邏輯抽象機制，其設計理念包括無單點故障、自管理以及軟體定義等特性。Ceph可以面向同一套存儲集群分別提供塊存儲、對象存儲以及文件存儲的對應介面。
Ceph架構相當復雜的，其中使用到大量的底層技術，例如RADOS、librados、RADOSGW、RDB、CRUSH演算法，外加monitor、OSD以及MDS等功能性組件。這里我們先不談它的底層架構，關鍵在於Ceph屬於一種分布式存儲集群，這使得擴展更便利、能夠在不犧牲性能的前提下消除單點故障，且提供涵蓋對象存儲、塊存儲以及文件存儲的統一存儲體系。
Ceph架構圖
Rook
另一個有趣且頗具人氣的項目是Rook，這是一項旨在將Kubernetes與Ceph融合起來的技術方案。從本質上講，它將計算節點和存儲節點放進了同一個集群當中。
Rook是一種雲原生編排器，並對Kubernetes做出擴展。Rook允許用戶將Ceph放置在容器內，同時提供卷管理邏輯以立足Kubernetes之上實現Ceph的可靠運行。Rook還使本應由集群管理員操作的多種任務完成了自動化實現，其中包括部署、引導、配置、擴展以及負載均衡等等。
Rook自身不具備持久狀態，也不需要單獨管理。這，才是真正與Kubernetes設計原則相符的存儲資源管理方案。
Rook憑借著將Ceph與Kubernetes協同起來的強大能力而頗受歡迎，在GitHub上獲得近4000顆星，1600多萬次的下載，並吸引到100多名貢獻者，現已進入CNCF孵化階段。
Longhorn
Longhorn項目是Rancher Labs推出的開源的基於雲和容器部署的分布式塊存儲新方式。Longhorn遵循微服務的原則，利用容器將小型獨立組件構建為分布式塊存儲，並使用容器編排來協調這些組件，形成彈性分布式系統。
如今，基於雲和容器的部署規模日益擴大，分布式塊存儲系統也正變得越來越復雜，單個存儲控制器上的volume數量在不斷增加。2000年代初，存儲控制器上的volume數量只有幾十個，但現代雲環境卻需要數萬到數百萬的分布式塊存儲卷。存儲控制器變成了高度復雜的分布式系統。
Longhorn充分利用了近年來關於 如何編排大量的容器和虛擬機的核心技術 。例如，Longhorn並沒有構建一個可以擴展到100,000個volume的高度復雜的控制器，而是出於讓存儲控制器簡單輕便的考慮，創建了100,000個單獨的控制器。然後，我們可以利用像Kubernetes這樣的最先進的編排系統來調度這些獨立的控制器，共享一組磁碟中的資源，協同工作，形成一個彈性的分布式塊存儲系統。
Longhorn基於微服務的設計還有很多其他優勢。因為每個volume都有自己的控制器，在升級每個volume的控制器和replica容器時，是不會導致IO操作明顯的中斷的。Longhorn可以創建一個長期運行的工作來編排所有live volume的升級，同時確保不會中斷系統正在進行的操作。為確保升級不會導致意外的問題，Longhorn可以選擇升級一小部分volume，並在升級過程中出現問題時回滾到舊版本。這些做法在現代微服務應用中已得到廣泛應用，但在存儲系統中並不常見。希望Longhorn可以 助力於微服務在存儲領域的更多應用。
結 語
對於實際應用層面出現的任何問題，最重要的自然是判斷需求、設計系統或者選擇適當的工具。同樣的道理也適用於雲原生環境。雖然具體問題非常復雜，但也必然會出現大量工具方案嘗試解決。隨著雲原生世界的持續發展，我們可以肯定，新的解決方案將不斷涌現。未來，一切都會更加美好！
③ 什麼是K8S
k8s全稱kubernetes，這個名字大家應該都不陌生，k8s是為容器服務而生的一個可移植容器的編排管理工具，越來越多的公司正在擁抱k8s，並且當前k8s已經主導了雲業務流程，推動了微服務架構等熱門技術的普及和落地，正在如火如荼的發展。想要了解更多，我推薦你去看看時速雲，他們是一家全棧雲原生技術服務提供商，提供雲原生應用及數據平台產品，其中涵蓋容器雲PaaS、DevOps、微服務治理、服務網格、API網關等。大家可以去體驗一下。
希望能給您提供幫助，可以給個大大的贊不。
④ 如何入門k8s
Kubernetes（簡稱K8S） 是Google開源的分布式的容器管理平台，方便我們在伺服器集群中管理我們容器化應用。
節點（Master node and Worker node）
節點通常指的就是伺服器，在k8s中有兩種節點：管理節點（Master Node）和工作節點（Worker Node）
管理節點（Master Node）：負責管理整個k8s集群，一般由3個管理節點組成HA的架構。
工作節點（Worker Node）：主要負責運行容器。命名空間(Namespace)
k8s命名空間主要用於隔離集群資源、隔離容器等，為集群提供了一種虛擬隔離的策略；默認存在3個名字空間，分別是默認命名空間 default、系統命名空間 kube-system 和 kube-public。Object
k8s 對象(Object)是一種持久化存儲並且用於表示集群狀態的實體。k8s 對象其實就是k8s自己的配置協議，總之我們可以通過定義一個object讓k8s根據object定義執行一些部署任務、監控任務等等。POD
Pod是 Kubernetes 部署應用或服務的最小的基本單位。一個Pod 封裝多個應用容器（也可以只有一個容器）、存儲資源、一個獨立的網路 IP 以及管理控制容器運行方式的策略選項。副本集(Replica Set，RS)
是一種控制器，負責監控和維護集群中pod的副本(replicas)數，確保pod的副本數是我們期望的樣子。部署(Deployment)
表示對k8s集群的一次更新操作，是k8s集群中最常用的Object，主要用於部署應用。支持滾動升級。服務(service)
是對應用的抽象，也是k8s中的基本操作單元，一個服務背後由多個pod支持，服務通過負載均衡策略將請求轉發到容器中。Ingress
是一種網關服務，可以將k8s服務通過http協議暴露到外部。無狀態應用 & 有狀態應用
無狀態應用指的是應用在容器中運行時候不會在容器中持久化存儲數據，應用容器可以隨意創建、銷毀；如果一個應用有多個容器實例，對於無狀態應用，請求轉發給任何一個容器實例都可以正確運行。例如：web應用
有狀態應用指的是應用在容器中運行時候需要穩定的持久化存儲、穩定的網路標識、固定的pod啟動和停止次序。例如：mysql資料庫