文章目录

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/