文章目錄

• kubernetes12（kubernetes的儲存）
• • 一.引子
  • 二.kubenetes的儲存分類及基本概念
  • • （一）.kubernetes的儲存基本概念
    • （二）.kubernetes的儲存重要概念
  • 三.基于以上四個概念的kubenetes儲存配置
  • • （一）.volumes
    • （二）.PersistentVolume（PV和PVC結合比較）
    • （三）.StorageClass
    • （四）. PersistentVolumeClaim
    • （五）.關于 StatefulSet （管理有狀態服務的POD）

kubernetes12（kubernetes的儲存）

一.引子

任何系統或服務都離不開的就是儲存，在當前時代，數據丟失的影響是非常大的。911事件之中大量公司破產就是因為數據丟失，公司直接清零。所以儲存是非常重要的。接下來筆者帶大家走進kuberbetes的儲存世界。kubernetes說到底還是進行容器的管理，大家可以看看以前筆者寫的關于docker的儲存管理。

在此章節開始之前，筆者帶大家復習一下知識點有狀態服務和無狀態服務：無狀態應用（Stateless Application）是指應用不會在會話中保存下次會話所需要的客戶端數據。每一個會話都像首次執行一樣，不會依賴之前的數據進行響應。有狀態的應用（Stateful Application）是指應用會在會話中保存客戶端的數據，并在客戶端下一次的請求中來使用那些數據。

二.kubenetes的儲存分類及基本概念

（一）.kubernetes的儲存基本概念

容器中的存儲都是臨時的，因此Pod重啟的時候，內部的數據會發生丟失。實際應用中，我們有些應用是無狀態，有些應用則需要保持狀態數據，確保Pod重啟之后能夠讀取到之前的狀態數據，有些應用則作為集群提供服務。這三種服務歸納為無狀態服務、有狀態服務以及有狀態的集群服務，其中后面兩個存在數據保存與共享的需求，因此就要采用容器外的存儲方案。

（二）.kubernetes的儲存重要概念

Kubernetes中存儲中有四個重要的概念：Volume、PersistentVolume （PV）、PersistentVolumeClaim(PVC)、StorageClass。掌握了這四個概念，就掌握了Kubernetes中存儲系統的核心。

• Volumes：最基礎的存儲抽象，其支持多種類型，包括本地存儲、NFS、FC以及眾多的云存儲，我們也可以編寫自己的存儲插件來支持特定的存儲系統。Volume可以被Pod直接使用，也可以被PV使用。普通的Volume和Pod之間是一種靜態的綁定關系，在定義Pod的同時，通過volume屬性來定義存儲的類型，通過volumeMount來定義容器內的掛載點。
• PersistentVolume：與普通的Volume不同，PV是Kubernetes中的一個資源對象，創建一個PV相當于創建了一個存儲資源對象，這個資源的使用要通過PVC來請求。
• StorageClass：StorageClass為管理員提供了一種描述他們提供的存儲的“類”的方法。 不同的類可能映射到服務質量級別，或備份策略，或者由群集管理員確定的任意策略。
• PersistentVolumeClaim：PVC是用戶對存儲資源PV的請求，根據PVC中指定的條件Kubernetes動態的尋找系統中的PV資源并進行綁定。目前PVC與PV匹配可以通過StorageClassName、matchLabels或者matchExpressions三種方式。

大家可以通過以下圖示了解四者之間的關系：

三.基于以上四個概念的kubenetes儲存配置

（一）.volumes

1.volumes的概念

容器磁盤上的文件的生命周期是短暫的，這就使得在容器中運行重要應用時會出現一些問題。首先，當容器崩潰時，kubelet 會重啟它，但是容器中的文件將丟失——容器以干凈的狀態（鏡像最初的狀態）重新啟動。其次，在 Pod 中同時運行多個容器時，這些容器之間通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解決了這些問題背后的實現方式可以有很多種。
Kubernetes 中的卷有明確的壽命 —— 與封裝它的 Pod 相同。所f以，卷的生命比 Pod 中的所有容器都長，當這個容器重啟時數據仍然得以保存。當然，當 Pod 不再存在時，卷也將不復存在。也許更重要的是，Kubernetes 支持多種類型的卷，Pod 可以同時使用任意數量的卷

2.Volumes支持卷的類型：

• awsElasticBlockStoreazureDiskazureFilecephfscsidownwardAPIemptyDir`
• fcflockergcePersistentDiskgitRepoglusterfshostPathiscsilocalnfs`
• persistentVolumeClaimprojectedportworxVolumequobyterbdscaleIOsecret`
• storageos vsphereVolume

3.volumes支持的一些典型卷的配置

（1）.emptyDir
emptyDir在Pod被分配到Node上之后創建，并且在Pod運行期間一直存在。初始的時候為一個空文件夾，當Pod從Node中移除時，emptyDir將被永久刪除。Container的意外退出并不會導致emptyDir被刪除。emptyDir適用于一些臨時存放數據的場景。默認情況下，emptyDir存儲在Node支持的介質上，不管是磁盤、SSD還是網絡存儲，也可以設置為Memory。

emptyDir` 的用法有：

• 暫存空間，例如用于基于磁盤的合并排序
• 用作長時間計算崩潰恢復時的檢查點
• Web服務器容器提供數據時，保存內容管理器容器提取的文件

簡單實例

apiVersion: v1 kind: Pod metadata:name: test-pd spec:containers:- image: k8s.gcr.io/test-webservername: test-containervolumeMounts:- mountPath: /cachename: cache-volumevolumes:- name: cache-volumeemptyDir: {}

（2）.hostPath
卷將主機節點的文件系統中的文件或目錄掛載到集群中。
hostPath的用途如下：

• 運行需要訪問 Docker 內部的容器；使用 /var/lib/docker的 hostPath
• 在容器中運行 cAdvisor；使用 /dev/cgroups 的 hostPath
• 允許 pod 指定給定的 hostPath 是否應該在 pod 運行之前存在，是否應該創建，以及它應該以什么形式存在

實例

apiVersion: v1 kind: Pod metadata:name: test-pd spec:containers:- image: k8s.gcr.io/test-webservername: test-containervolumeMounts:- mountPath: /test-pdname: test-volumevolumes:- name: test-volumehostPath:# directory location on hostpath: /data# this field is optionaltype: Directory

（二）.PersistentVolume（PV和PVC結合比較）

1.PV與PVC的結合比較

• Persistent Volumes 提供了一個抽象層，向用戶屏蔽了具體的存儲實現形式。
• PersistentVolume
  PV：集群管理員提供的一塊存儲，是Volumes的插件，類似于Pod，但是具有獨立于Pod的生命周期。具體存儲可以是NFS、云服務商提供的存儲服務。
• PersistentVolumeClaim PVC：PVC是用戶的存儲請求，PVC消耗PV資源。是用戶存儲的請求。它與 Pod相似。Pod 消耗節點資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源（CPU和內存）。聲明可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或 只讀多次模式掛載）

2.PV與PVC相互作用的生命周期

PV和PVC之間的相互作用遵循這個生命周期:Provisioning ——-> Binding
——–>Using——>Releasing——>Recycling

（1）.PV的提供方式（Provisioning）

• 靜態供給（static）：集群管理員創建多個PV。 它們攜帶可供集群用戶使用的真實存儲的詳細信息。 它們存在于KubernetesAPI中，可用于消費。
• 動態供給：管理員創建的靜態 PV 都不匹配用戶的 PersistentVolumeClaim 時，集群可能會嘗試動態地為 PVC創建卷。此配置基于 StorageClasses：PVC 必須請求 [存儲類]，并且管理員必須創建并配置該類才能進行動態創建。聲明該類為 “” 可以有效地禁用其動態配置 要啟用基于存儲級別的動態存儲配置，集群管理員需要啟用 API server 上的DefaultStorageClass[準入控制器] 。例如，通過確保 DefaultStorageClass 位于 API server組件的 --admission-control標志，使用逗號分隔的有序值列表中，可以完成此操作

（2）.綁定（Binding）

• 在動態配置的情況下，用戶創建或已經創建了具有特定數量的存儲請求和特定訪問模式的PersistentVolumeClaim。主機中的控制回路監視新的PVC，找到匹配的PV（如果可能），并將它們綁定在一起。如果為新的PVC動態配置PV，則循環將始終將該PV綁定到PVC。 否則，用戶總是至少得到他們要求的內容，但是卷可能超出了要求。一旦綁定，PersistentVolumeClaim綁定是排他的，不管他們如何綁定。
• 如果匹配的卷不存在，PVC將保持無限期。 隨著匹配卷變得可用，PVC將被綁定。 例如，提供許多50GiPV的集群將不匹配要求100Gi的PVC。 當集群中添加100Gi PV時，可以綁定PVC。

（3）.使用（Using）

• Pod使用PVC作為卷。 集群檢查聲明以找到綁定的卷并掛載該卷的卷。
  對于支持多種訪問模式的卷，用戶在將其聲明用作pod中的卷時指定所需的模式。
• 一旦用戶有聲明并且該聲明被綁定，綁定的PV屬于用戶，只要他們需要它。
  用戶通過在其Pod的卷塊中包含persistentVolumeClaim來安排Pods并訪問其聲明的PV。
• 在用對象保護：PVC 保護的目的是確保由 pod 正在使用的 PVC 不會從系統中移除，因為如果被移除的話可能會導致數據丟失。對于正在使用的PV提供了保護機制，正在使用的PV如果被用戶刪除，PV的刪除會推遲到用戶對PV的使用結束。

（4）.釋放（Releasing）

• 當用戶完成卷時，他們可以從允許資源回收的API中刪除PVC對象。 當聲明被刪除時，卷被認為是“釋放的”，但是它還不能用于另一個聲明。以前的用戶的數據仍然保留在必須根據政策處理的卷上.

（5）.回收及回收策略（Recycling）

• Retain（保留）—— 手動回收，保留現場，Kubernetes等待用戶手工處理數據。
• Reclaim （重用）—— 這個策略已經不推薦使用了，應該使用 Dynamic Provisioning 代替。
• Recycle（回收）——基本擦除（rm -rf /thevolume/*）
• Delete（刪除）——關聯的存儲資產（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）將被刪除
• 擴容——主要是對于一些云存儲類型，例如gcePersistentDisk、Azure Disk提供了擴容特性，在1.11版本還處于測試階段。

當前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持刪除策略

3.Persistent Volumes 的一些屬性和狀態
（1）.PV屬性

• Capacity：一般情況PV擁有固定的容量
• Volume Mode：在1.9版本中是alpha特性，允許設置 filesystem 使用文件系統（默認），設置 raw 使用裸設備。
• Access Modes：當請求具有特定訪問模式的存儲時，聲明使用與卷相同的約定
• Class：可以設置成StorageClass的名稱。具有Class屬性的PV只能綁定到還有相同CLASS名稱的PVC上。沒有CLASS的PV只能綁定到沒有CLASS的PVC上。

（2）.PV狀態

• Available：未被任何PVC使用
• Bound：綁定到了PVC上
• Released：PVC被刪掉，資源未被使用
• Failed：自動回收失敗

（三）.StorageClass

每個StorageClass包含字段provisioninger和參數，當屬于類的PersistentVolume需要動態配置時使用。

StorageClass對象的名稱很重要，用戶可以如何請求特定的類。 管理員在首次創建StorageClass對象時設置類的名稱和其他參數，并且在創建對象后無法更新對象。

管理員可以僅為不要求任何特定類綁定的PVC指定默認的StorageClass：有關詳細信息，請參閱PersistentVolumeClaim部分。

kind: StorageClass apiVersion: storage.k8s.io/v1 metadata:name: standard provisioner: kubernetes.io/aws-ebs parameters:type: gp2

（四）. PersistentVolumeClaim

是用戶存儲的請求。它與 Pod 相似。Pod 消耗節點資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源（CPU 和內存）。聲明可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或 只讀多次模式掛載）

創建服務并使用PVC

apiVersion: v1 kind: Service metadata:name: nginxlabels:app: nginx spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata:name: web spec:selector:matchLabels:app: nginxserviceName: "nginx"replicas: 3template:metadata:labels:app: nginxspec:containers:- name: nginximage: k8s.gcr.io/nginx-slim:0.8ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "nfs"resources:requests:storage: 1Gi

（五）.關于 StatefulSet （管理有狀態服務的POD）

1.statefulset對pod的基礎管理

• 匹配 Pod name ( 網絡標識 ) 的模式為：(statefulset名稱)-(序號)，比如上面的示例：web-0，web-1，web-2
• StatefulSet 為每個 Pod 副本創建了一個 DNS 域名，這個域名的格式為： (podname).(headless server name)，也就意味著服務間是通過Pod域名來通信而非 Pod IP，因為當Pod所在Node發生故障時， Pod 會被飄移到其它 Node 上，Pod IP 會發生變化，但是 Pod 域名不會有變化
• StatefulSet 使用 Headless 服務來控制 Pod 的域名，這個域名的 FQDN 為：(service name).(namespace).svc.cluster.local，其中，“cluster.local” 指的是集群的域名
• 根據 volumeClaimTemplates，為每個 Pod 創建一個 pvc，pvc 的命名規則匹配模式：(volumeClaimTemplates.name)-(pod_name)，比如上面的 volumeMounts.name=www， Pod name=web-[0-2]，因此創建出來的 PVC 是 www-web-0、www-web-1、www-web-2**
• 刪除 Pod 不會刪除其 pvc，手動刪除 pvc 將自動釋放 pv

2.Statefulset的啟停順序：

• 有序部署：部署StatefulSet時，如果有多個Pod副本，它們會被順序地創建（從0到N-1）并且，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態。
• 有序刪除：當Pod被刪除時，它們被終止的順序是從N-1到0。
• 有序擴展：當對Pod執行擴展操作時，與部署一樣，它前面的Pod必須都處于Running和Ready狀態。

3.StatefulSet使用場景：

• 穩定的持久化存儲，即Pod重新調度后還是能訪問到相同的持久化數據，基于 PVC 來實現。
• 穩定的網絡標識符，即 Pod 重新調度后其 PodName 和 HostName 不變。
• 有序部署，有序擴展，基于 init containers 來實現。
• 有序收縮。

kubernetes修行不易，不積硅步無以至千里。
參考文章：

https://kubernetes.io/docs/concepts/storage/volumes/
https://kubernetes.io/docs/concepts/storage/persistent-volumes/
https://kubernetes.io/docs/concepts/storage/storage-classes/
https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/
https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/

總結

以上是生活随笔為你收集整理的kubernetes12（kubernetes的储存）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。