Kubernetes(k8s)之Volume（卷）

k8s中的volume

Volume(存储卷)是Pod中能够被多个容器访问的共享目录。Kubermetes的Volume概念、用途和目的与Docker的Volume比较类似，但两者不能等价。
K8s中的Volume被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下（即每个容器共享一个卷但挂载目录不同）。
K8s中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失。

为什么要用volume

容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失，因为容器会以干净的状态重建。其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。 因此K8s 抽象出 Volume 对象来解决这两个问题。

volume特点

K8s卷具有明确的生命周期,与包裹它的 Pod 相同。
卷比Pod中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。
当一个 Pod 不再存在时，卷也将不再存在。
K8s 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。
卷不能挂载到其他卷，也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。

K8s支持多种类型的Volume

Kubernetes 支持下列类型的卷：

• awsElasticBlockStore 、azureDisk、azureFile、cephfs、cinder、configMap、csi
• downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker
• gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、
• nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd
• scaleIO、secret、storageos、vsphereVolume

官方文档可点击查看。

演示环境

server1：172.25.38.1	harbor仓库端
server2：172.25.38.2	k8s master端
server3：172.25.38.3	k8s node端
server4：172.25.38.4	k8s node端

emptyDir卷

当 Pod 指定到某个节点上时，首先创建的是一个 emptyDir 卷，并且只要 Pod 在该节点上运行，卷就一直存在。 就像它的名称表示的那样，卷最初是空的，并且无须指定宿主机上对应的目录文件，因为这是Kubernetes自动分配的一个 目录，当Pod从Node上移除时，emptyDir中的数据也会被永久删除。

emptyDir的一些用途如下：

• 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。
• 长时间任务的中间过程CheckPoint的临时保存目录。
• 一个容器需要从另一个容器中获取数据的目录(多容器共享目录)。

目前，用户无法控制emptyDir使用的介质种类。如果kubelet的配置是使用硬盘，那么所有emptyDir都将被创建在该硬盘上。Pod在将来可以设置emptyDir是位于硬盘、固态硬盘上还是基于内存的tmpfs上。

多容器共享卷

创建一个卷的目录，在里面编写卷相关的yaml配置文件。

vol1.yaml文件内容如下：

apiVersion: v1
kind: Pod			#资源类型是pod
metadata:
  name: vol1
spec:
  containers:		#创建两个容器
  - image: busyboxplus
    name: vm1
    command: ["sleep", "300"]
    volumeMounts:
    - mountPath: /cache		#容器vm1挂载的目录
      name: cache-volume
  - name: vm2
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html		#容器vm2挂载的目录
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:			#创建empty卷
      medium: Memory	#基于内存
      sizeLimit: 100Mi	#限制大小100M

进入第一个容器挂载目录下写入文件

进入另一个容器的挂载目录，可以看到我们在vm1容器里写入的文件，说明卷是共享的

emptyDir卷缺点

不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出，但是这个时间内，其实对node还是有风险的。
影响kubernetes调度，因为empty dir并不涉及node的resources，这样会造成Pod“偷偷”使用了node的内存，但是调度器并不知晓；用户不能及时感知到内存不可用。

示例：配置文件里限制卷大小为100M，生成一个200M的空文件，卷被“撑爆”，容器停止运行。

文件超过sizeLimit，则一段时间后（1-2分钟）会被kubelet evict掉。之所以不是“立即”被evict，是因为kubelet是定期进行检查的，这里会有一个时间差。

hostPath 卷

hostPath卷应用场景

hostPath为在Pod上挂载宿主机上的文件或目录，它通常可以用于以下几方面：
1、容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统进行存储。
2、需要访问宿主机上Docker引擎内部数据结构的容器应用时，可以通过定义hostPath为宿主机/var/lib/docker目录，使容器内部应用可以直接访问Docker的文件系统。

使用hostPath卷时，需要注意的点：

1、在不同的Node上具有相同配置的Pod，可能会因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致。
2、如果使用了资源配额管理，则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理。
3、基础主机上创建的文件或目录只能由 root 用户写入。您需要在 特权容器 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 hostPath 卷。

hostPath 卷的 type

除了必需的 path 属性之外，用户可以选择性地为 hostPath 卷指定 type。

创建hostPath 卷

编写yaml配置文件，内容如下

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data
      type: DirectoryOrCreate	#不存在这个目录则创建

应用配置文件

server3上原本没有这个目录，现在自动创建了

在server2里写入文件，在server3/data目录下也能看到

NFS共享文件

在server1、2、3、4都下载nfs组件

都启动nfs

更改server1的配置文件，/etc/exports文件内容如下

/mnt/nfs        *(rw,no_root_squash)

server2访问server1的nfs成功！

编写配置文件nfs.yaml来共享server1的文件系统，内容如下

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 172.25.38.1		#共享server1的文件系统
      path: /mnt/nfs

应用配置文件，查看pod的详细信息，共享成功

在server1的nfs数据目录下写入文件

在server2进入pod挂载目录也可以看到

PersistentVolume持久卷（PV）

什么是PV

PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。

什么是PVC

PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。

PV与PVC的关系

PVC与PV的绑定是一对一的映射。没找到匹配的PV，那么PVC会无限期得处于unbound未绑定状态。

PV的使用、释放、回收

• 使用
  Pod使用PVC就像使用volume一样。集群检查PVC，查找绑定的PV，并映射PV给Pod。对于支持多种访问模式的PV，用户可以指定想用的模式。一旦用户拥有了一个PVC，并且PVC被绑定，那么只要用户还需要，PV就一直属于这个用户。用户调度Pod，通过在Pod的volume块中包含PVC来访问PV。

• 释放
  当用户使用PV完毕后，他们可以通过API来删除PVC对象。当PVC被删除后，对应的PV就被认为是已经是“released”了，但还不能再给另外一个PVC使用。前一个PVC的属于还存在于该PV中，必须根据策略来处理掉。

• 回收
  PV的回收策略告诉集群，在PV被释放之后集群应该如何处理该PV。当前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（删除）。保留允许手动地再次声明资源。对于支持删除操作的PV卷，删除操作会从Kubernetes中移除PV对象，还有对应的外部存储（如AWS EBS，GCE PD，Azure Disk，或者Cinder volume）。动态供给的卷总是会被删除。

参数解释

• 访问模式
  ReadWriteOnce – 该volume只能被单个节点以读写的方式映射
  ReadOnlyMany – 该volume可以被多个节点以只读方式映射
  ReadWriteMany – 该volume可以被多个节点以读写的方式映射

• 在命令行中，访问模式可以简写为：
  RWO - ReadWriteOnce
  ROX - ReadOnlyMany
  RWX - ReadWriteMany

• 回收策略
  Retain：保留，需要手动回收
  Recycle：回收，自动删除卷中数据
  Delete：删除，相关联的存储资产，如AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷都会被删除

当前，只有NFS和HostPath支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷支持删除操作。

• 状态：
  Available：空闲的资源，未绑定给PVC
  Bound：绑定给了某个PVC
  Released：PVC已经删除了，但是PV还没有被集群回收
  Failed：PV在自动回收中失败了
  命令行可以显示PV绑定的PVC名称。

创建静态PV

静态PV：集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用。

编写yaml配置文件，内容如下，共享nfs的资源创建

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle	#用完回收
  storageClassName: nfs
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /mnt/nfs
    server: 172.25.38.1

应用文件，创建出pv，查看详细信息目前还是可用状态，共享server1的文件系统

创建pvc，配置文件内容如下

vim pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

查看pvc和pv已互相绑定

创建pod，将pvc挂载到指定目录

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: pv1
  volumes:
  - name: pv1
    persistentVolumeClaim:
      claimName: pvc1

在nfs端写入文件，进入pod内挂载点可看到是同步的

进入pod内挂载点写入东西，在nfs端同样可以同步

看下ip，访问也没有问题

创建动态PV

动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。

StorageClass

StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。

每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。

StorageClass的属性
Provisioner（存储分配器）：用来决定使用哪个卷插件分配 PV，该字段必须指定。可以指定内部分配器，也可以指定外部分配器。外部分配器的代码地址为： kubernetes-incubator/external-storage，其中包括NFS和Ceph等。

Reclaim Policy（回收策略）：通过reclaimPolicy字段指定创建的Persistent Volume的回收策略，回收策略包括：Delete 或者 Retain，没有指定默认为Delete。

更多属性查看：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/

创建新目录，写创建sc的yaml配置文件

内容如下：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: nfs-subdir-external-provisioner:v4.0.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: westos.org/nfs
            - name: NFS_SERVER
              value: 172.25.38.1
            - name: NFS_PATH
              value: /mnt/nfs
      volumes:
        - name: nfs-client-root
          nfs:
            server: 172.25.38.1
            path: /mnt/nfs
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: westos.org/nfs
parameters:
  archiveOnDelete: "true"	#自动回收开启

创建一个namespace

应用配置文件

已经有了sc

编写创建pvc的配置文件，内容如下：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs-pv1		#记住自己写的名字，下边要用到
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

创建pvc，根据sc设置的规则分配绑定pv

在nfs端可以看到已经自动创建了卷目录

删掉pvc

再看nfs端目录名已变，自动回收了

再重新创建pvc，然后写创建pod的文件，将pvc挂载，文件内容如下

kind: Pod
apiVersion: v1
metadata:
  name: test-pod-2
spec:
  containers:
  - name: test-pod
    image: nginx
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/usr/share/nginx/html"		#挂载点
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: nfs-pv1

创建pod后访问出现403错误，因为没有发布页面

在nfs端写个发布页面

再回来访问，成功！说明因为挂载了pvc，所以是同步的

删除pod，删除pvc

将sc配置文件里的自动回收true改为false关闭

重新应用sc的yaml配置文件

重新创建pvc，同之前一样，自动绑定pv

在nfs端可以看到自动创建的目录

关闭自动同步

删掉pvc和pv

再看目录没了，因为没开自动回收

手动指定sc

默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims 配置存储（只能有一个默认StorageClass）。
如果没有默认StorageClass，PVC 也没有指定storageClassName 的值，那么意味着它只能够跟 storageClassName 也是“”的 PV 进行绑定。

示例：
将创建pvc的配置文件里说明sc的注释掉

重新应用，可以看到没有策略，创建的pvc没有绑定pv

手动补丁加上sc

删除pvc再重新创建，可以看到pv绑定成功

StatefulSet控制器控制pod

StatefulSet将应用状态抽象成了两种情况：
1、拓扑状态：应用实例必须按照某种顺序启动。新创建的Pod必须和原来Pod的网络标识一样。
2、存储状态：应用的多个实例分别绑定了不同存储数据。

StatefulSet给所有的Pod进行了编号，编号规则是：$(statefulset名称)-$(序号)，从0开始。

Pod被删除后重建，重建Pod的网络标识也不会改变，Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来,并且为每个Pod提供了一个固定且唯一的访问入口，即Pod对应的DNS记录。

示例：
编写创建svc的配置文件，内容如下

apiVersion: v1
kind: Service
metadata:
 name: nginx-svc
 labels:
  app: nginx
spec:
 ports:
 - port: 80
   name: web
 clusterIP: None
 selector:
  app: nginx

创建svc，查看详细信息没有后端

编写创建StatefulSet控制器的配置文件，内容如下

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx-svc"
 replicas: 3
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
   - name: nginx
     image: nginx
     volumeMounts:
       - name: www
         mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
  - metadata:
     name: www
    spec:
     #storageClassName: managed-nfs-storage
     accessModes:
     - ReadWriteOnce
     resources:
      requests:
       storage: 1Gi

创建StatefulSet控制器

再查看服务已有后端

将StatefulSet控制器配置文件里的副本数改为6个

查看创建过程，是按序创建的（之前都是一起创建，是无序的）

将StatefulSet控制器配置文件里的副本数改为0个

相当于删除控制器，可以看到也是按序删除的

将StatefulSet控制器配置文件里的副本数改为3个

重新应用文件

运行一个pod，进入查看解析如下，curl访问没有问题

换个镜像试试

进入pod查看解析，访问也没有问题

实现负载均衡

到nfs端可以看到自动创建的卷目录

分别写入发布页面

直接访问服务，实现了负载均衡