Ⅰ k8s分布式存儲-Ceph
RADOS
Librados
Crush
Pool
PG
Object
Pool、PG和OSD的關系
OSD
塊存儲（ RBD )
文件存儲（ CephFS )
對象存儲（ Object )
關閉防火牆
關閉selinux
關閉 swap
根據規劃設置主機名
添加 hosts
設置文件描述符
時間同步
配置 SSH 免交互認證
1、創建rbd使用的pool
2、指定存儲池使用存儲類型
3、創建一個塊設備
3、查看塊設備
1、禁用當前系統內核不支持的feature
2、映射（任意節點操作）
3、格式化塊設備
4、mount到本地
5、取消塊設備和內核映射
6、刪除RBD塊設備
1、拷貝配置文件和秘鑰
2、安裝 Ceph 客戶端
3、剩餘操作就與本地掛載操作一樣了
1、創建快照
2、列出創建的快照
3、還原快照
4、重新映射並掛載驗證
5、刪除快照
1、創建一個塊設備
2、創建快照
3、設置快照處於被保護狀態
4、通過快照克隆一個新塊設備
5、將克隆的快照獨立於父設備
掛載本地目錄
fuse方式掛載
**全部統一命名空間到 ceph-csi **
k8s節點安裝 Ceph 客戶端
csi-config-map.yaml
storageclass
secret
啟動驗證
rbd-pod-test.yaml
測試
**全部統一命名空間到 ceph-csi **
k8s節點安裝 Ceph 客戶端
csi-config-map
storageclass
secret
啟動驗證
ceph-cephfs-test
測試
Ⅱ k8s之存儲
k8s的存儲常用的就是上面幾種模式，分為臨時存儲，半持久化存儲，與持久化存儲這三類，本章我們著重講解emptydir與hostpath與pvc跟pv等
當pod的存儲方案設定為emptydir的時候，pod啟動時，就會在pod所在節點的磁碟空間開辟出一塊空卷，最開始裡面是什麼都沒有的，pod啟動後容器產生的數據會存放到那個空卷中。空卷變成了一個臨時卷
供pod內的容器讀取和寫入數據，一旦pod容器消失，節點上開辟出的這個臨時卷就會隨著pod的銷毀而銷毀
一般來說emptydir的用途都是用來充當臨時存儲空間，例如一些不需要數據持久化的微服務，我們都可以用emptydir來當做微服務pod的存儲方案
k8s存儲emptdir實戰例子：以之前的myapp應用為例
創建應用
觀察是否生產data目錄，並在/data目錄創建文件test.txt
手動刪除容器模擬容器銷毀，用於是pod是被控制器管理的，刪除後會被重建新的pod
這時候在看我們之前創建的data.txt已經不見了
hostPath類型則是映射node文件系統中的文件或者目錄到pod里。在使用hostPath類型的存儲卷時，也可以設置type欄位，支持的類型有文件、目錄、File、Socket、CharDevice和BlockDevice（我只映射過文件與目錄）。
其實這個功能就相當於docker中的-v 目錄映射，只不過在k8s中的時候，pod會漂移，當pod漂移到其他node節點的時候，pod不會跨節點的去讀取目錄。所以說hostpath只能算一種半持久化的存儲方式
實戰例子
創建應用
在node節點可以看到生成了/data/volume目錄，在裡面創建測試文件
檢驗pod裡面的/data是否存在這個映射目錄的文件
可以看到剛才創建的文件已經映射到我們的目錄里邊了
為了驗證是否映射到容器裡面的目錄也會隨著pod生命周期的消失而消失，我們手動刪除pod模擬容器終止
可以看到容器被刪除後，新建的pod也可以看到我們映射的目錄，而且裡面數據test.txt還在。
這有個缺點就是不能夠跨容器去讀取數據，如果刪除後的pod被調度到其他節點的話，原來的數據也就沒有了，如果能不受節點的影響，並且掛載的數據不會隨生命周期的結束而結束，我們應該怎麼解決呢？就是我們後面講到的持久化存儲了
上面介紹了倆種臨時存儲於半持久化存儲的方案。在k8s實際生產環境中，一般會選用私有雲持久化存儲方案還有公有雲持久化存儲方案，私有雲存儲方案包括nfs，ceph，glusterfs等方案。公有雲存儲會用到AWS等方案
存儲方案各有各的優缺點，可參考 https://www.cnblogs.com/yswenli/p/7234579.html 這篇文章。今天我們主要講解pvc，pv，nfs之間的關系。
簡單來說，要使用持久化存儲，就需要使用pvc去跟pv去申請，然後pv查看自己有沒有合適的存儲空間卷，有合適的就與pvc進行綁定。pv與pvc是一一對應綁定的。現在我們用一幅圖來說明pvc，pv，nfs的關系
實戰例子
准備存儲服務安裝nfs
接下來創建pv與nfs綁定
創建pvc與pv關聯
創建並查看結果
注意：STATUS為Bound說明該pvc已經與pv綁定了
接下來創建pod來引用pvc
創建pod
接下來驗證一下在nfs創建一個測試文件，看是否被映射到容器中
可以看到容器裡面也可以看到創建的文件
手動刪除容器，或者調度到其他節點原來的文件還是不會被刪除的，這里就省略驗證了，這就是nfs的好處，不過企業一般不會選用nfs，磁碟IO,性能讀取方面不太理想，畢竟是本地存儲，還是有一定的風險。推薦用用雲存儲。
文件存儲提供無限擴展的文件系統來給雲伺服器存取數據實際上相當於nfs
1、已注冊阿里雲賬號，並完成實名認證。
如果沒有，請先注冊阿里雲賬號，詳情請參見阿里雲賬號注冊流程。
2、已開通NAS服務。
首次登錄NAS控制台時，根據頁面提示開通NAS服務。
3、在需要創建文件系統的地域，已有可用的雲伺服器ECS。
k8s應用NAS實戰例子
1、打開阿里雲NAS控制台確認已創建好文件系統
2、把復制掛載參數把它掛載到伺服器中創建測試目錄，前提是伺服器需要安裝nfs客戶端。
安裝完成掛載到本地目錄並創建test目錄作為測試目錄
並在裡面創建一個測試文件1.txt
接下來可以創建pvc和pv了
創建並查看
接下來創建pod去引用pvc
創建pod
檢驗剛才的1.txt是否掛到容器的/data/nas下
雲存儲適合於生產環境k8s的存儲解決方案
Ⅲ Kubernetes應用程序的保護和移動性策略
隨著Kubernetes（K8s）和容器成為開發、部署、運行和擴展雲原生和下一代IT應用程序的事實選擇，企業正在K8s集群上運行越來越多的業務關鍵型應用程序。業務關鍵型應用程序通常是有狀態的。有狀態應用程序具有關聯的狀態、數據和配置信息，並依賴以前的數據事務來執行其業務邏輯。
Kubernetes上提供服務的業務關鍵型應用程序通常與傳統應用程序一樣具有可用性和業務連續性要求，這意味著服務中斷（違反SLA）會嚴重影響提供商的收入和聲譽。企業通常意識到，他們需要使用數據管理工具使其Kubernetes部署能夠在影響服務的災難之後或面臨到新集群或環境的硬應用程序遷移任務時對服務故障具有恢復能力。
企業認識到這一需求，但使用內部開發的定製工具，這些工具很難在企業和應用程序團隊之間進行擴展、應用和規范化。換句話說，這種工具是特定於應用程序的，需要為每個應用程序定製開發。因此，企業需要為其Kubernetes資產制定一個連貫一致的持久性和數據管理戰略。
K8s應用程序數據持久性和管理的現狀
更大的Kubernetes社區和生態系統在定義容器存儲介面（CSI）方面做得非常出色，它解決了用戶在有狀態Kubernetes應用程序的持久存儲資源調配和消耗方面的一階問題。CSI介面還定義了數據管理原語，如對持久卷（PV）快照和克隆的支持。這些介面為存儲和數據管理供應商建立綜合應用數據保護和移動性解決方案奠定了基礎。
Kubernetes數據管理（應用程序感知是關鍵），並不總是關於集群中的內容
目前還沒有關於Kubernetes應用程序組成的具體定義。但是，對於大多數Kubernetes從業者和用戶來說，K8s應用程序是通過包含有關應用程序的數據和元數據形成的，這些數據和元數據結合了標准K8s對象和資源（如ConfigMap、Secrets、Deployment、ReplicaSet）、Persistent Volumes（PV）和跨命名空間（在某些情況下，跨集群）的自定義資源（CRD和CRs）。因此，任何與應用程序無關的Kubernetes數據管理工具都需要考慮構成應用程序的所有這些組件。
如果不這樣做，也不復制和/或備份與K8s應用程序關聯的持久卷，則在災難發生後恢復應用程序時，可能會導致一些嚴重的故障。將應用程序視為保護和遷移的整體單元是實現Kubernetes應用程序數據管理的關鍵。
使這種情況更加復雜的是主要用於公共雲的雲原生K8s應用程序設計模式，在公共雲中，應用程序團隊利用了使用完全託管的雲服務（如資料庫、消息隊列和對象存儲）的便利性、穩定性和性能。在這種情況下，根據定義，K8s應用程序不再局限於集群，而是跨集群之外的完全託管的服務。在Kubernetes集群中運行的應用程序中使用外部完全託管或自我管理的資料庫是非常常見的。
在這種雲原生開發設計模式的基礎上，AWS和Azure等公共雲使得通過Kubernetes原生API使用Kubernetes集群的完全託管服務變得更加容易。AWS Controllers for Kubernetes（ACK）和Azure Service Operator（for Kubernetes）就是例子。
Kubernetes原生持久性的替代方案——常見設計模式及其原因
如上所述，構建基於Kubernetes的現代服務的應用程序團隊除了使用不限於K8s集群中使用持久卷的原生雲服務外，還經常使用多種持久性技術。出現這種模式的原因有很多，包括但不限於：
——堅信Kubernetes是只運行無狀態應用程序的優秀平台。
——在K8s集群上運行資料庫的早期經驗，或了解嘗試這樣做的失敗項目。
——採用雲原生和微服務方法，使用原生公共雲DBaaS（例如AWS RDS、Google cloud sql、Azure Cosmos DB）、第三方供應商管理的數據存儲（作為SaaS提供）或自我管理的外部資料庫集群構建Kubernetes應用程序，感覺很正常。這種設計範式遵守雲原生設計方法，它利用這些數據服務的可伸縮性、可恢復性、彈性和靈活性，在微服務之間使用基於API的契約。
——使用對象存儲滿足K8s持久性需要，因為它在公共雲中無處不在，並且廣泛用於持久化現代應用程序。
與其他選擇一樣，這些持久性選擇也有缺點。使用完全託管的原生公共雲資料庫和NoSQL數據存儲可能成本高昂，並導致對一個公共雲的隱式鎖定。但對於那些選擇單一或主要雲提供商滿足其IT需求的企業來說，這可能是一個不錯的設計選擇。為了避免雲提供商鎖定，採用多雲戰略的企業通常使用第三方ISV提供的雲不可知DBaaS產品。
在其他情況下，他們在雲提供商的保留實例上運行外部資料庫集群（利用折扣保留實例定價），以節省成本。這樣做，他們最終會自我管理資料庫集群，這可能會很乏味。
使用對象存儲實現Kubernetes持久性非常流行。但是，使用對象存儲也會使應用程序本身的可移植性降低，因為用於訪問公共雲中原生對象存儲服務的API不兼容，因為不支持相同的API。K8s社區正在開發一個新的標准容器對象存儲介面（COSI），為使用K8s應用程序的對象存儲提供公共抽象層，這將讓使用對象存儲的K8s應用程序的可移植性更容易。此外，對象存儲不適用於許多現有應用程序，即使它們正在重構。
這對企業意味著什麼？
很明顯，Kubernetes應用程序的組成及其持久性需求的定義並不總是精確地映射到集群內的Kubernetes資源和連接到集群內運行的pod的持久卷。K8s數據持久性的選擇非常豐富，每種選擇都有其優缺點。這意味著流行的K8s應用程序數據管理功能（如備份、恢復、遷移和合規性）必須包括K8s集群內部的內容，以及可能位於集群外部且是應用程序不可分割的一部分的對象和資源。
例如，對K8s應用程序進行一致備份還意味著觸發對完全管理的公共雲資料庫的備份，該資料庫除了K8s資源、元數據和Kubernetes集群中存在的對象之外，還向該應用程序提供數據服務。除集群內K8s資源外，後續恢復過程還必須恢復外部資料庫。
因此，企業必須仔細審查其K8s應用程序保護、移動性和合規性戰略，並為其K8s存儲和數據管理解決方案使用選擇標准，以保證其應用程序團隊和開發人員採用的最常見的雲原生持久性設計模式。
原文鏈接：
https://thenewstack.io/kubernetes-application-protection-and-mobility-strategies/
Ⅳ 如何入門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資料庫
Ⅳ K8s持久化存儲
Volume 提供了非常好的數據持久化方案，不過在可管理性上還有不足。
要使用 Volume，Pod 必須事先知道如下信息：
Pod 通常是由應用的開發人員維護，而 Volume 則通常是由存儲系統的管理員維護。開發人員要獲得上面的信息：
要麼詢問管理員。
要麼自己就是管理員。
這樣就帶來一個管理上的問題：應用開發人員和系統管理員的職責耦合在一起了。如果系統規模較小或者對於開發環境這樣的情況還可以接受。但當集群規模變大，特別是對於生成環境，考慮到效率和安全性，這就成了必須要解決的問題。
Kubernetes 給出的解決方案是什麼 PersistentVolume （PV）和 PersistentVolumeClaim（PVC）。
PersistentVolume (PV) 是外部存儲系統中的一塊存儲空間，由管理員創建和維護。與 Volume 一樣，PV 具有持久性，生命周期獨立於 Pod。
PersistentVolumeClaim (PVC) 是對 PV 的申請 (Claim)。PVC 通常由普通用戶創建和維護。需要為 Pod 分配存儲資源時，用戶可以創建一個 PVC，指明存儲資源的容量大小和訪問模式（比如只讀）等信息，Kubernetes 查找並提供滿足條件的 PV。
有了 PersistentVolumeClaim，用戶只需要告訴 Kubernetes 需要什麼樣的存儲資源，而不必關心真正的空間從哪裡分配，如何訪問等底層細節信息。這些 Storage Provider 的底層信息交給管理員來處理，只有管理員才應該關心創建 PersistentVolume 的細節信息。
1、配置nfs
需要安裝
k8s-master：nfs-server
k8s-node1：nfs-client
k8s-node2：nfs-client
所有節點安裝nfs
在master節點創建共享目錄
編輯exports文件
啟動rpc和nfs（注意順序）
作為准備工作，我們已經在 k8s-master 節點上搭建了一個 NFS 伺服器，目錄為 /nfsdata：
2、創建PV
下面創建一個 PV mypv，配置文件 nfs-pv.yml 如下：
① capacity 指定 PV 的容量為 1G。
② accessModes 指定訪問模式為 ReadWriteOnce，支持的訪問模式有：
ReadWriteOnce：PV 能以 read-write 模式 mount 到單個節點。
ReadOnlyMany：PV 能以 read-only 模式 mount 到多個節點。
ReadWriteMany ：PV 能以 read-write 模式 mount 到多個節點。
③ persistentVolumeReclaimPolicy 指定當 PV 的回收策略為 Recycle，支持的策略有：
Retain： 需要管理員手工回收。
Recycle：清除 PV 中的數據，效果相當於執行 rm -rf /thevolume/*。
Delete： 刪除 Storage Provider 上面的對應存儲資源，例如 AWS EBS、GCE PD、Azure Disk、- OpenStack Cinder Volume 等。
④ storageClassName 指定 PV 的 class 為 nfs。相當於為 PV 設置了一個分類，PVC 可以指定 class 申請相應 class 的 PV。
⑤ 指定 PV 在 NFS 伺服器上對應的目錄。
創建 mypv：
STATUS 為 Available，表示 mypv 就緒，可以被 PVC 申請。
3、創建PVC
接下來創建 PVC mypvc，配置文件 nfs-pvc.yml 如下：
部署pvc
4、創建pod
上面已經創建好了pv和pvc，pod中直接使用這個pvc即可
與使用普通 Volume 的格式類似，在 volumes 中通過 persistentVolumeClaim 指定使用 mypvc 申請的 Volume。
通過命令創建mypod：
在這里，可以嘗試在任何一方刪除文件，文件在兩端都會消失；
當 PV 不再需要時，可通過刪除 PVC 回收。未刪除pvc之前 pv的狀態是Bound
刪除pod
刪除pvc
再次查看pv的狀態
刪除pvc之後pv的狀態變為Available，，此時解除綁定後則可以被新的 PVC 申請。
/nfsdata文件中的文件被刪除了
因為 PV 的回收策略設置為 Recycle，所以數據會被清除，
但這可能不是我們想要的結果。如果我們希望保留數據，可以將策略設置為 Retain
雖然 mypv 中的數據得到了保留，但其 PV 狀態會一直處於 Released，不能被其他 PVC 申請。為了重新使用存儲資源，可以刪除並重新創建 mypv。刪除操作只是刪除了 PV 對象，存儲空間中的數據並不會被刪除。
PV 還支持 Delete 的回收策略，會刪除 PV 在 Storage Provider 上對應存儲空間。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。
前面的例子中，我們提前創建了 PV，然後通過 PVC 申請 PV 並在 Pod 中使用，這種方式叫做靜態供給（Static Provision）。
與之對應的是動態供給（Dynamical Provision），即如果沒有滿足 PVC 條件的 PV，會動態創建 PV。相比靜態供給，動態供給有明顯的優勢：不需要提前創建 PV，減少了管理員的工作量，效率高。
基於NFS的PV動態供給(StorageClass)
靜態：pod-->pvc-->pv
動態：pod -->pvc-->storageclass
去官網下載三個文件
這三個文件去網上下載 https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy
使用腳本批量下載：
其中deployment.yaml需要修改一下掛載的地址,目錄,鏡像版本
然後分別去應用這三個文件
創建pod進行測試
查看pv和pvc
在部署 statefulset 類型的工作負載時，動態創建 PV/PVC 是一種比較常用的配置方式，動態創建 PV/PVC 的方法基本如下：
一直啟動不起來，查看 pvc 和 pods 信息如下：
從上邊的現象來看，是 PVC 沒有創建成功，動態 PVC 中，是 provisioner 中來負責創建，查看其日誌，看到如下錯誤信息：
Google 之後，找到主要原因是，官方在 k8s 1.20 中基於對性能和統一 apiserver 調用方式的初衷，移除了對 SelfLink 的支持，而 nfs-provisioner 需要 SelfLink 該項功能。具體計劃和原因可查看這個 issue[2] 和 KEP[3] 。
K3S 為兼容 K8S 應該也繼承了該項修改，按 K8S 的方式修改測試了下，完美解決。
解決問題主要有下邊兩種方式：
1、修改 apiserver 的配置文件，重新啟用 SelfLink 功能。針對 K8S，可添加如下配置：
K3S 中沒有 apiserver 的配置文件，可通過 systemd 的啟動文件添加該參數，如下：
若為新安裝，可如下啟用：
2、使用新的不基於 SelfLink 功能的 provisioner 鏡像，重新創建 provisioner 容器。
若你能科學上網，可使用這個鏡像：
國內可使用這個鏡像【若不可用自己查找】：
Ⅵ K8s怎麼對象分布式存儲
K8s對象分布式存儲的方式很多，我們用的元核雲分布式塊存儲，用的就是ceph-csi對接的他們的rbd塊存儲。
Ⅶ [K8S系列七]存儲-PV、PVC與Storage Class
本質上說，一個volume(卷)就是一個目錄，從容器內部可以訪問這個目錄中的內容，而這個目錄是怎麼來的，它背後的媒介是什麼以及它裡面的內容，都是由volume的類型來決定的；而使用volume，只需要在pod上指定使用哪種類型的volume，以及mount到容器中的什麼位置即可。K8S支持的存儲類型如下所示，這里主要介紹HostPath和Persistent Volume。
hostPath 類型的volume是映射Pod所在的節點的文件或者目錄到 pod 里。在使用 hostPath 類型的存儲卷時，也可以設置 type 欄位，支持的類型有文件、目錄、File、Socket、CharDevice 和 BlockDevice。
根據附錄1的volume-pod.yaml創建一個pod，使用hostPath類型的volume
部署後查看pods詳情， 發現volume-pod位於w2節點，登錄到w2 嘗試在pods的容器中創建文件
因為hostPath類型的volume只映射pod所在的節點的文件或目錄到pod中，如果pod因為重啟被調度到其他節點時，將會看不到原來節點保存的數據，因此有了網路存儲+pv+pvc的方式。
通過PersistentVolume(PV)與PersistentVolumeClaim(PVC)將提供存儲與消費存儲分離：
2.PVC由用戶創建來消費存儲，如同通過創建pod來消費cpu、mem資源。
PVC與PV是通過PersistentVolume Controller 進行綁定的。PV Controller 會不斷地循環去查看每一個 PVC，是不是已經處於 Bound（已綁定）狀態。如果不是，那它就會遍歷所有的、可用的 PV，並嘗試將其與未綁定的 PVC 進行綁定，這樣，Kubernetes 就可以保證用戶提交的每一個 PVC，只要有合適的 PV 出現，它就能夠很快進入綁定狀態。而所謂將PV 與 PVC 進行「綁定」，其實就是將這個 PV 對象的名字，填在了 PVC 對象的 spec.volumeName 欄位上 。
這里以NFS+PV+PVC為例進行說明， NFS搭建過程請參考附錄2，根據考附錄3 nginx-pv-pvc.yaml ，創建nginx(deployment)、nginx-pv(pv)、nginx-pvc(pvc)。nginx-pv掛載在/nfs/data/nginx 下。在/nfs/data/nginx下創建文件1.html，pod中也可以訪問，並且pod的重新創建不影響1.html。
上節說的PV和PVC方法雖然能實現屏蔽底層存儲，但是PV創建比較復雜，通常都是由集群管理員管理，這非常不方便。
利用StorageClass實現，可以根據PVC需求，自動構建相對應的PV持久化存儲卷，進一步簡化運維管理成本。
StorageClass對象會定義下面兩部分內容:
示例部分參考 nfs-subdir-external-provisioner 。 相關文件來源於 deploy ，需要略作修改。
1. Volumes
2.《kubernetes權威指南》
3. Kubernetes 存儲設計
NFS(Network File System)網路文件系統，是FreeBSD支持的文件系統中的一種，允許網路中的計算機之間通過TCP/IP網路共享資源。
Ⅷ 通過K8S部署對象存儲MinIO
MinIO 是全球領先的對象存儲先鋒，以 Apache License v2.0 發布的對象存儲伺服器，是為雲應用和虛擬機而設計的分布式對象存儲伺服器。在標准硬體上，讀/寫速度上高達183GB/s和171GB/s。它與 Amazon S3 雲存儲服務兼容。 它最適用於存儲非結構化數據，如照片、視頻、日誌文件、備份和容器/虛擬機映像。 對象的大小可以從幾KB 到最大5TB。
MinIO是一個非常輕量的服務,可以很簡單的和其他應用的結合，類似 NodeJS, Redis 或者 MySQL。
MinIO支持多種靈活的部署方式，支持Docker Compose、Docker Swam、Kubernetes等，詳見官網： https://docs.min.io/docs/minio-deployment-quickstart-guide.html 或者 https://min.io/download#/linux
這里著重介紹K8S下部署
1、standalone模式
由於service採用NodePort類型，通過主機IP:32593訪問web
2、distributed模式
分布式部署，實例數至少4個，所以需要另外創建4個pv
Ⅸ 9. K8s存儲
Kubernetes的Volume是Pod的一部分，Volume不是單獨的對象，不能獨立創建，只能在Pod中定義。
Pod中的所有容器都可以訪問Volume，但必須要掛載，且可以掛載到容器中任何目錄。
實際中使用容器存儲如下圖所示，將容器的內容掛載到Volume中，通過Volume兩個容器間實現了存儲共享。
Volume的生命周期與掛載它的Pod相同，但是Volume裡面的文件可能在Volume消失後仍然存在，這取決於Volume的類型。
Kubernetes的Volume有非常多的類型：
這個Volume掛載後就是一個空目錄，應用程序可以在裡面讀寫文件，emptyDir Volume的生命周期與Pod相同，Pod刪除後Volume的數據也同時刪除掉。
emptyDir的一些用途：
配置示例
emptyDir也可以設置存儲介質為內存
HostPath存儲的內容與節點相關，如果Pod被調度到其他Node，HostPath無法提供跨Node的數據。
配置示例
ConfigMap存儲的是鍵值對，在Volume中應用時鍵值對表示的是 文件名 和 文件內容 ，代表將ConfigMap的每條數據填入Volume。ConfigMap的配置數據在 data 欄位下定義。
ConfigMap文件示例
Volume中引用ConfigMap
與ConfigMap類似，在data欄位中存儲key-value鍵值對形式，不過存儲的value不是明文，是Base64編碼的加密值。
在Volume中引用後，文件中的值是Base64解碼後的值，而非加密值。
Kubernetes抽象了PV（PersistentVolume）和PVC（PersistentVolumeClaim）來解耦網路存儲種類多樣的問題，從而讓使用者不用關心具體的基礎設施，當需要存儲資源的時候，只要像CPU和內存一樣，聲明要多少即可。
PV是集群級別的資源，並不屬於某個命名空間（在 default 命名空間下），而PVC是命名空間級別的資源，PV可以與任何命名空間的PVC資源綁定。
Kubernetes管理員設置好網路存儲的類型，提供對應的PV描述符配置到Kubernetes，使用者需要存儲的時候只需要創建PVC，然後在Pod中使用Volume關聯PVC，即可讓Pod使用到存儲資源，它們之間的關系如下圖所示。
PV 持久卷是用 插件 的形式來實現的，目前支持以下插件：
CSI
Container Storage Interface，容器存儲介面，基於CSI這套介面，可以開發定製出CSI插件，從而支持特定的存儲，達到解耦的目的。
PVC創建示例：
使用StorageClass可以自動創建PV，StorageClass包含 provisioner 、 parameters 和 reclaimPolicy 欄位， 這些欄位會在 StorageClass 需要動態分配 PersistentVolume 時會使用到。在聲明PVC時加上StorageClassName，就可以自動創建PV，並自動創建底層的存儲資源。
provisioner： PV配置器，用來決定使用哪個卷插件制備 PV。 該欄位必須指定。
reclaimPolicy： 回收策略，可以是 Delete 或者 Retain ，默認是 Delete
使用StorageClassName創建PVC示例：