⑴ 深入剖析k8s中的存儲
本文是《深入剖析k8s》學習筆記的第四篇，主要對k8s中的存儲數據卷進行分析和學喚臘習。
容器中的存儲是不穩定的，一旦容器重啟或者銷毀，這些存儲就都會丟失。所以真實使用場景下，都會以數據卷掛載的方式將外部存儲應用到容器中，帶來的好處就是：
在k8s中，如果要在容器中使用數據卷，需要像如下一個pod的yaml示例一樣進行聲明定義：
其中pod的定義中，聲明使用了自定義名稱為 my-volume 的數據卷，並且類型為emptyDir；k8s的volume支持多種數據類型，可以通過命令 kubectl explain pod.spec.volumes 來查看所有支持的volume類型，其中常用的類型及意義比較如下：
從工程分工角度上來說，存儲的定義和聲明應該由運維人員完成，開發人員只要使用即可。因此，為了避免將存儲細節過度地暴露給開發人員，k8s才引進了Persistent Volume Claim(PVC)和Persistent Volume(PV)這兩個API對象，同時也降低了開發人員使用存儲卷的門檻。如此，開發人員只需要如下兩步就能解決存儲卷的使用問題：
那麼開發人員聲明的PVC到底使用的是什麼存儲卷呢，這個和廳就由運維人員負責維護就行了，如下是一個PV的定義，開發人員了解即可：
為什麼這個PV可以和上面的PVC綁定呢？只要符合如下的條件，k8s就會自動將它們綁定，綁定後，在PVC的配置文件中就能看到使用的數據卷就是該PV了。
總的來說，PVC和PV的關系就像是介面和實現的關系，PVC是介面定義，聲明要使用什麼，至於怎麼實現，就是PV去完成的事情。如此解耦，使得開發和運維都能高效地搞定存儲。
假設開發人員在創建好帶有PVC的pod之後，且pod已經運行了，才發現運維還沒有來得及創建對應的PVC或者PVC創建有問題，致使pod存儲卷使用有問題該怎麼辦？只要運維及時創建對應的PV，k8s中的volume controller會循環遍歷沒有成功綁定PV的PVC，幫它們尋找喚鏈隱合適的PV進行綁定。
一個k8s集群往往有很多開發團隊在使用，開發會部署很多pod，如果這些pod都需要存儲卷，運維人員就需要天天創建pv來滿足開發人員pvc綁定的需求了，太浪費人力，所以這種重復工作就被k8s中的storageClass取代了。原先手動創建PV的方式被稱為static provisioning，使用storageClass自動創建PV的方式被稱為dynamic provisioning，storageClass其實就是PV的一個模板，其定義大致分為兩個部分：
在開發人員創建PVC的時候，只要指定使用的storageClassName是如上定義和創建的my-storageclass，那麼k8s就會根據該storageClass自動創建一個PV與該PVC綁定。
⑵ [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之存儲
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的存儲解決方案
⑷ 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示例：
⑸ kubernetes(十一) 數據存儲（掛載卷管理）
在前面已經提到，容器的生命周期可能很短，會被頻繁地創建和銷毀。那麼容器在銷毀時，保存在容器中的數據也會被清除。這種結果對用戶來說，在某些情況下是不樂意看到的。為了持久化保存容器的數據，kubernetes引入了Volume的概念。
Volume是Pod中能夠被多個容器訪問的共享目錄，它被定義在Pod上，然後被一個Pod里的多個容器掛載到具體的文件目錄下，kubernetes通過Volume實現同一個Pod中不同容器之間的數據共享以及數據的持久化存儲。Volume的生命容器不與Pod中單個容器的生命周期相關，當容器終止或者重啟時，Volume中的數據也不會丟失。銷帆宴
kubernetes的Volume支持多種類型，比較常見的有下面幾個：
EmptyDir是最基礎的Volume類型，一個EmptyDir就是Host上的一個空目錄。
EmptyDir是在Pod被分配到Node時創建的，它的初始內容為空，並且無須指定宿主機上對應的目錄文件，因為kubernetes會自動分配一個目錄，當Pod銷毀時， EmptyDir中的數據也會被永久刪除。 EmptyDir用途如下：
接下來，通過一個容器之間文件共享的案例來使用一下EmptyDir。
在一個Pod中准備兩個容器nginx和busybox，然後聲明一個Volume分別掛在到兩個容器的虧銀目錄中，然後nginx容器負責向Volume中寫日誌，busybox中通過命令將日誌內容讀到控制台。
創建一個volume-emptydir.yaml
EmptyDir中數據不會被持久化，它會隨著Pod的結束而銷毀，如果想簡單的將數據持久化到主機中，可以選擇HostPath。
HostPath就是將Node主機中一個實際目錄掛在到Pod中，以供容器使用，這樣的設計就可以保證Pod銷毀了，但是數據依據可以存在於Node主機上。
創建一個volume-hostpath.yaml：
HostPath可以解決數據持久化的問題，但是一旦Node節點故障了，Pod如果轉移到了別的節點，又會出現問題了，此時需要准備單獨的網路存儲系統，比較常用的用NFS、CIFS。
NFS是一個網路文件存儲系統，可以搭建一台NFS伺服器，然後將Pod中的存儲直接連接到NFS系統上，這樣的話，無論Pod在節點上怎麼轉移，只要Node跟NFS的對接沒問題，數據就可以成功訪問。
1）首先要准備nfs的伺服器，這里為了簡單，直接是master節點做nfs伺服器
2）接下來，要在的每個node節點上都安裝下nfs，這樣的目的是為了node節點可以驅動nfs設備
3）接下來，就可以編寫pod的配置文件了，創建volume-nfs.yaml
4）最後，運行下pod，觀察結果
前面已經學習了使用NFS提供存儲，此時就要求用戶會搭建NFS系統，並且會在yaml配置nfs。由於kubernetes支持的存儲系統有很多，要求客戶全都掌握，顯然不現實。為了能夠屏蔽底層存儲實現的細節，方便用戶使用， kubernetes引入PV和PVC兩種資源對象。
PV（Persistent Volume）是持轎培久化卷的意思，是對底層的共享存儲的一種抽象。一般情況下PV由kubernetes管理員進行創建和配置，它與底層具體的共享存儲技術有關，並通過插件完成與共享存儲的對接。
PVC（Persistent Volume Claim）是持久卷聲明的意思，是用戶對於存儲需求的一種聲明。換句話說，PVC其實就是用戶向kubernetes系統發出的一種資源需求申請。
使用了PV和PVC之後，工作可以得到進一步的細分：
PV是存儲資源的抽象，下面是資源清單文件:
PV 的關鍵配置參數說明：
實驗
使用NFS作為存儲，來演示PV的使用，創建3個PV，對應NFS中的3個暴露的路徑。
1.准備NFS環境
2.創建pv.yaml
PVC是資源的申請，用來聲明對存儲空間、訪問模式、存儲類別需求信息。下面是資源清單文件:
PVC 的關鍵配置參數說明：
實驗
1.創建pvc.yaml，申請pv
2.創建pods.yaml, 使用pv
PVC和PV是一一對應的，PV和PVC之間的相互作用遵循以下生命周期：
ConfigMap是一種比較特殊的存儲卷，它的主要作用是用來存儲配置信息的。
創建configmap.yaml，內容如下：
接下來，使用此配置文件創建configmap
接下來創建一個pod-configmap.yaml，將上面創建的configmap掛載進去
在kubernetes中，還存在一種和ConfigMap非常類似的對象，稱為Secret對象。它主要用於存儲敏感信息，例如密碼、秘鑰、證書等等。
1.首先使用base64對數據進行編碼
2.接下來編寫secret.yaml，並創建Secret
3.創建pod-secret.yaml，將上面創建的secret掛載進去：
至此，已經實現了利用secret實現了信息的編碼。
⑹ k8s nfs掛載設置
nfs服務端配置
/data/xxxx *(rw,async,no_root_squash)
k8s 客戶端配置
apiVersion: v1
kind: PersistentVolume
metadata:
name: $Sonar_Name-nfs-pv
namespace: rdc
labels:
sonar: $Sonar_Name
spec:
capacity:
storage: 30Gi
檔缺 accessModes:
行絕辯 - ReadWriteMany
nfs:
server: 192.168.36.32
path: /data/sonar11
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
namespace: rdc
name: $Sonar_Name-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 30Gi
selector:
matchLabels:
sonar: $Sonar_Name
PV 和PVC 是一一對應的關宏碧系
⑺ K8s 數據存儲之Volume
一切container和它之中的數據都是臨時的。如果container重啟，這些數據會丟失。Volume用於container保存需要持久化的數據。這些數據也可以用於container共享。
Docker中有volume的概念。在Docker中，volume是container中的一個目錄。Volume沒有生命周期的概念，volume中的數據只有儲存在本地磁碟這一種形式。
Kubernetes的volume具有明確的生命空間。Volume生命周期比pod中運行的container長。Container重啟之後，volume的數據仍會保留。但是，當Pod銷毀之時，該pod關聯的volume也會同時銷毀。
使用volume的方法：在spec.volumes處聲明volume，在spec.containers[*].volumeMount中掛載volume到container。
可以將ConfigMap的值注入到volume中。這樣可以在pod中使用config map。同時，Volume中的值會隨著ConfigMap的修改而自動更新。
在Volume中使用ConfigMap的用法如下：
這里例子將名字為log-config的config map中key為log_level的值，作為文件log_level的內容，放入config-vol的根目錄。然後把config-vol掛載到 /etc/config ，目錄。也就是container中 /etc/config/log_level 文件的內容為log-config中log_level的值。
可以使用DownWard API的方式，將k8s資源的spec信息作為文件內容放入到volume中。
例子如下：
此處volume使用了downwardAPI。volume中labels文件的內容為pod metadata的labels配置項內容，即：
annotation文件的內容為為pod metadata的annotations配置項內容，即：
生命周期和pod一樣。emptyDir的初始狀態為一個沒有任何內容的volume。如果Pod從集群節點上移除，那麼emptyDir類型的volume中的內容會被清除。
Container遇到崩潰或重啟，這時候Pod本身不會受任何影響，這種情況下emptyDir volume中的數據會保留。Container重啟之後數據仍然可見。
emptyDir volume具有的這種特性適合如下場景使用：
默認來說emptyDir類型volume的物理存儲在硬碟，SSD或網路設備上。可以設置 emptyDir.medium 為 Memory ，這時候k8s會使用tempfs（基於內存的文件系統）。此時volume的容量限制收到container的內存配額的制約。
配置樣例為：
使用tempfs(內存)的羨歷肆emptyDir volume的配置樣例如下；
gitRepo比較簡單：兄轎先准備一個emptyDir類型的volume，再clone一個git repo到volume，爛襲然後把volume mount到container。
此模式掛載pod宿主機文件系統中的文件或目錄到pod。
hostPath必須指定一個path參與，用於指定使用宿主機哪個目錄。
除此之外還有一個可選的type參數，有如下值可供配置：
需要注意的是由於hostPath類型volume的數據和宿主機強綁定，如果pod停止後被schele到其他節點，pod讀取到的數據會有變化。
使用hostPath的例子：
local模式支持使用磁碟，分區或者是目錄。local還支持使用靜態創建的PersistentVolume，不支持Dynamic provisioning(使用PVC的方式)。
與hostPath不同的是，local模式無需手動配置將pod調度到固定的node上。local模式系統通過volume的node affinity配置來感知volume的node限制（volume只能生成在特定的node上）。
使用例子：
nodeAffinity必須配置。這個例子創建出的PersistentVolume必須創建在hostname包含 example-node 的節點上。
VolumeMode默認值為Filesystem。可以配置為 Block ，將volume作為塊設備使用。
使用local模式的時候建議配套的StorageClass的 volumeBindingMode 設置為 WaitForFirstConsumer 。如下所示：
延遲volume綁定可以允許在volume綁定的時候考慮到pod中配置的一些限制，例如node資源限制，node選擇器和pod affinity以及pod anti-affinity。
使用PVC聲明式的創建所需的PersistentVolume。這個稍後在PersistentVolume中介紹。
映射多個類型的配置(數據源)到volume中。相當於多種volume合並使用。
可以映射的volume類型為：
所有的volume數據源要求必須和使用它的pod在同一個namespace之下。
一個使用例子如下：
通常我們綁定volume時，映射的是volume的根目錄。我們可以通過指定subPath參數，將volume中的其他目錄掛載到container中。對於一個pod多個container，且多處使用同一個volume的場景最為適用。
例子如下：
這個例子中mysql和php兩個container使用同一個volume site-data。Volume的 mysql 目錄映射到了mysql container的 /var/lib/mysql 。Volume的 html 目錄映射到了php container的 /var/www/html 。
emptyDir使用磁碟時的限製取決於kubelet所在的文件系統（/var/lib/kubelet）。emptyDir或者hostPath佔用多大磁碟空間是沒有限制的。
⑻ K8s 數據存儲之PersistentVolume
這兩個概念用於pod和volume之間解耦。Pod根據自己的需要提吵悉出數據卷的申請，k8s系統將符合條件的數據卷返回給pod。這樣一來pod就無需直接和數據卷本身強綁定了。Pod無需知道數據卷的細節信息，比如具體用的是什麼存儲。
Pod中對數據卷的申請為PVC，用來和PVC綁定的數據卷稱為PV。
PV可以有多種存儲方式，比如NFS，iSCSI等。
PVC是使用PV資源的聲明。
PV有兩種供應方式
這個階段指的是PV和PVC綁定的過程。系統有一個機制，循環檢查新創建的PVC，然後找到一個符合條件的PV，把他們綁定到一起。如果有多個滿足要求的PV可以綁定，會使用消耗資源最小的那個。PV和PVC之間是一對一的關系。如果找不到符合條件的PV，PVC會一致保持未綁定狀態。
PVC綁定合適的PV之後，Pod使用這個PV。和PVC綁定並處於使用狀態的PV不會被系統刪除，防止數據丟失。
如果用戶刪除了Pod正笑碼在使用的PVC，這個PVC不會被立即移除。直到這個PVC不被任何Pod時候的時候，才會被真正的刪除。
當PV不再使用的時候，k8s根據不同的策略來回收這些PV。
Retain策略在volume不再使用的時候，不刪除舊的數據，等待管理員處理。
Delete策略會刪除不再使用的PV，同時刪除這些PV對應真實存儲的資升升乎源。
刪除volume內的內容，使得volume可供下次使用。
PV的容量
可以使用Filesystem或者Block。Filesystem為默認值。
具有如下可選值：
配置storageClassName。
可以使用如下回收策略：
可以指定存儲的類型。
Local volume必須要設定這個屬性。該屬性規定了volume可以通過哪些node訪問。
訪問模式。和PV相同。
volume的掛載模式，可以為Filesystem或block。
約定聲明PV的大小等參數。
用於限制volume，只有label匹配的volume才能綁定到PVC上。可以使用 matchLabels 或者 matchExpressions 來約束。
用於實現動態供給。只有StorageClassName相同的PV和PVC才能夠綁定到一起。如果PVC的StorageClassName設置為""，那麼它只會和StorageClassName也為""的PV綁定到一起。
創建StorageClass的時候如果將它的 storageclass.kubernetes.io/is-default-class annotation設置為true，那麼此StorageClass會成為默認的StorageClass。如果PVC沒有指定StorageClassName，那麼它會和StorageClassName為默認StorageClass的PV綁定到一起。當然，使用這個特性必須要開啟DefaultStorageClass的admission plugin。
如果沒有啟動這個admission plugin。沒有指定StorageClass的PVC只能和沒有指定StorageClass的PV綁定在一起。沒有指定StorageClass和設置StorageClass的值為""，含義是相同的。
這種類型的PV把數據儲存在集群中某個節點上。
注意：nodeAffinity屬性是必須要指定的，因為local模式一定要確定數據保存在哪個機器。
對應StorageClass如下：
⑼ microk8s上給Pod掛載NFS
團隊新開發的區域醫療平台包含一個課件上傳與播放模塊，其實際的業務包含如下的步驟：
1. 縣級和鄉鎮衛生院的醫生們通過在線視頻參加培訓、並錄制視頻。
2. 醫生上傳視頻，並共享課件。
3. 平台上的其他醫生可以在課件學習欄目學習錄制的培訓會議。
通常，課件的上傳和保存我們都是通過對象存儲做的，對象存儲的好處顯而易見：不擔心文件丟失（三份備份）， 不擔心容量（雲服務商集群），https/http訪問， 數據安全（對象訪問簽名）； 但是這個平台需要部署到區域醫療機構的機房裡，多數情況下是沒有對象存儲的，外購對象存儲也成本過高， 所以我們採用了折中的方案，存儲系統換為NFS， 只需要一個大存儲量的機器就可以了，大概服務如下：
我們開發了一個uploader服務，用於上傳文件，同時使用Nginx提供http/https服務，兩個服務之間共享存儲，使用NFS存儲掛載給他們。
這里我們來看看怎麼給microk8s上的pod掛載NFS存儲。
首先，我們需要安裝NFS server 用於測試
我們使用ubuntu來進行測試，先執行命令：sudo apt install nfs-kernel-server
這個命令將安裝伺服器端，以及所有相關的包：
在home目錄下創建一個nfsshare的文件夾用作共享目錄。然後我們來編輯nfs配置文件，配置該共享目錄，默認允許所有IP段掛在：
啟動nfs： sudo /etc/init.d/nfs-kernel-server start
可以使用服務命令查看服務狀態： service nfs-kernel-server status
使用ip addr命令查看以下當前主機的IP：
現在我們來使用nfsclient端測試一下：
sudo mount 10.0.2.15:/home/nfsshare /mnt
查詢 /mnt 目錄，可以看到在 /home/nsshare下面創建的文件和子目錄
測試完後umount 掛載點： sudo umount -v /mnt
1. 先寫一個PV， 用來表示可以掛載的NFS存儲：
2. 接著寫一個PVC，用於綁定PV:
3. 然後寫包裝了nginx的存儲服務的deployment文件：
4. 最後寫存儲服務對應的service文件：
完成了所有配置文件，使用microk8s kubectl apply -f 命令，依次創建資源對象。
查詢創建的pod：
使用exec 登陸docker，
查詢/usr/share/storage目錄，如下圖，nfs已經掛載好了，可以看見我們在test目錄下創建了幾個文件：
最後，我們來驗證一下http方式訪問文件
現在storage的nfs目錄下創建兩個子目錄，attachement、video ， 對應docker的掛在路徑為： /usr/share/storage/atttachment、/usr/share/storage/video。
在兩個文件夾下面，分別創建兩個文件 helloA.txt helloB.txt, 並隨意寫寫內容。
完成後我們通過30080埠，從microk8s節點的瀏覽器訪問兩個文件：
至此，在k8s下，給pod掛在nfs的工作，並通過http訪問的任務就完了。另外：
1. 後續需要考慮，通過Lua寫一個腳本和nginx集成，實現訪問資源簽名驗證，這個機制可以很容易的參考對象存儲的驗證。
2. 這里沒有討論，如何寫upload和製作storage服務的鏡像，upload服務也需要掛載nfs，原理是一樣的，所以就不再討論。 storage服務是基於Nginx鏡像實現，下面的附錄了帶上了可參考的配置文件。
==============================================================
附錄A： storageservice服務中，nginx的配置文件storage.conf
附錄B： storageservice服務中dockerfile文件
附錄C： Storageservice的build.gradle文件
參考 一個Springboot項目的build.gradle和Dockerfile ， 這里的buiild.gradle文件不需要java build， 僅需要用來生成新docker鏡像。
⑽ 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
測試