k8s volume存储卷、PV、PVC和存储类

一、存储卷

1.1 介绍

1.1.1 共享是存储设备类型

多路并行读写
多路只读
单路读写

1.1.2 存储卷类型

因为kubelet是管理容器的，所以存储卷也是由它来管理的；
kubelet在管理时需要依赖存储卷插件，自己本身就支持一些插件。
存储卷插件（也可以叫类型）又分为In-Tree（内部kubelet支持的）和Out-of-Tree（通过CSI接口接入的这种，CSI全名：Container Storage Interface(容器存储接口)）

1. In-Tree类

1. HOST级别：hostPath、Local
2. 网络级别：NFS、GlusterFS、CephFS、rbd(块设备)
   云存储：awsEBS…
   SAN(Storage Area Network)：FC，iSCSI, …
   SDS(Software Defined Storage): Ceph（rbd, cephfs）、…
3. 临时存储：emptyDir
4. pvc也是In-Tree的插件

2. Out-of-Tree类：由管理员通过flexVolume或CSI接入的第三方存储卷类型

Longhorn

3. 查看支持的存储卷类型

kubectl explain pods.spec.volumes

1.1.3 pod使用volume注意

1. 在pod级别定义存储卷
2. 在容器级别挂载存储卷

1.2 选项解析

kubectl explain pods.spec.volumes可以看到以下选项

spec:
  volumes:
  - name <string>  # 存储卷名称标识，仅可使用DNS标签格式的字符，在当前Pod中必须唯一
    VOL_TYPE <Object>  # 存储卷插件及具体的目标存储供给方的相关配置
  containers:
  - name: …
    image: …
    volumeMounts:
    - name <string>  # 要挂载的存储卷的名称，必须匹配存储卷列表中某项的定义
      mountPath <string> # 容器文件系统上的挂载点路径
      readOnly <boolean>  # 是否挂载为只读模式，默认为“否”
      subPath <string>     # 挂载存储卷上的一个子目录至指定的挂载点
      subPathExpr <string>  # 挂载由指定的模式匹配到的存储卷的文件或目录至挂载点

1.3 举例

1.3.1 临时存储emptyDir类型

介绍：这个yaml文件中定义了一个初始化容器和主容器，还有pod级别声明了存储卷，初始化容器和主容器都进行了挂载

1. 首先在Pod级别定义一个名为config-file-store的volume，而且使用的是内存空间，大小限制为16mb
2. 定义一个初始化容器并将config-file-store卷挂载到初始化容器的/data目录下，初始化容器负责下载配置文件到/data中
3. 定义一个主容器并将config-file-store卷以只读的方式挂载到/etc/envoy/下，之后主容器运行命令就可以启动了

apiVersion: v1
kind: Pod
metadata:
  name: volumes-emptydir-demo
  namespace: default
spec:
  initContainers:
  - name: config-file-downloader
    image: ikubernetes/admin-box
    imagePullPolicy: IfNotPresent
    command: ['/bin/sh','-c','wget -O /data/envoy.yaml http://ilinux.io/envoy.yaml']
    volumeMounts:
    - name: config-file-store
      mountPath: /data
  containers:
  - name: envoy
    image: envoyproxy/envoy-alpine:v1.13.1
    command: ['/bin/sh','-c']
    args: ['envoy -c /etc/envoy/envoy.yaml']
    volumeMounts:
    - name: config-file-store
      mountPath: /etc/envoy
      readOnly: true
  volumes:
  - name: config-file-store
    emptyDir:
      medium: Memory      #如果要使用磁盘就使用""就可以了，但是这里只会在节点上创建一个临时存储目录
      sizeLimit: 16Mi

1.3.2 HOST级别hostPath类型

hostPath文件类型(yaml文件中的pods.spec.volumes.hostPath.type字段)

1. File：事先必须存在的文件路径；
2. Directory：事先必须存在的目录路径；
3. DirectoryOrCreate：指定的路径不存时自动将其创建为0755权限的空目录，属主属组均为kubelet；
4. FileOrCreate：指定的路径不存时自动将其创建为0644权限的空文件，属主和属组同为kubelet；
5. Socket：事先必须存在的Socket文件路径；
6. CharDevice：事先必须存在的字符设备文件路径；
7. BlockDevice：事先必须存在的块设备文件路径；
8. “”：空字符串，默认配置，在关联hostPath存储卷之前不进行任何检查

1. 编写yaml文件

vim volumes-hostpath-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volumes-hostpath-demo
  namespace: dev
spec:
  containers:
  - name: filebeat
    image: ikubernetes/filebeat:5.6.7-alpine
    env:
    - name: REDIS_HOST
      value: redis.ilinux.io:6379
    - name: LOG_LEVEL
      value: info
    volumeMounts:
    - name: varlog
      mountPath: /var/log
    - name: socket
      mountPath: /var/run/docker.sock
    - name: varlibdockercontainers
      mountPath: /var/lib/docker/containers
      readOnly: true
  volumes:
  - name: varlog
    hostPath:
      path: /var/log
  - name: varlibdockercontainers
    hostPath:
      path: /var/lib/docker/containers
  - name: socket
    hostPath:
      path: /var/run/docker.sock

2. 查看

1.查看运行状态
[root@master01 volumes]# kubectl get pod -n dev -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
volumes-hostpath-demo   1/1     Running   0          30s   10.244.1.25   node01   <none>           <none>

2.进入容器内部看挂载点是不是有这些文件,可以看到已经挂载进来了
[root@master01 volumes]# kubectl exec -n dev -it volumes-hostpath-demo -- /bin/sh
/ # ls -l /var/run/docker.sock
srw-rw----    1 root     985              0 Jun 19 05:21 /var/run/docker.sock

1.3.3 网络级别NFS类型

注意下方的yaml文件中定义了一个1099用户，其中1099用户必须在nfs服务器上也存在，并且要对nfs服务端中的共享目录有读写权限，这样容器中的1099用户才可以写入挂载的这个目录
而且k8s的node节点上也需要支持mount -t nfs，pod内的容器才能支持挂载

nfs系统中也需要存在1099用户
cat /etc/passwd
redis-user:x :1099:1099::/home/redis-user:/bin/bash

nfs共享目录权限：
drwxr-xr-x. 2 redis-user root 6 9月 14 21:36 redis
drwxr-xr-x. 2 redis-user root 31 6月 19 17:38 redis001
drwxr-xr-x. 2 redis-user root 6 6月 19 16:51 redis002
drwxr-xr-x. 2 redis-user root 6 6月 19 16:51 redis003
drwxr-xr-x. 2 redis-user root 6 6月 19 16:51 redis004
drwxr-xr-x. 2 redis-user root 6 6月 19 16:51 redis005

1. nfs-server端服务器上创建nfs目录并赋予权限

[root@node02 ~]# useradd -u 1099 redis-user
[root@node02 ~]# mkdir /data/redis -p
[root@node02 ~]# chown 1099 -R /data/redis/
配置nfs
[root@node02 ~]# cat /etc/exports  
/data/redis 192.168.8.0/24(rw) #这里是集群节点的IP段

2. 编写yaml文件

vim volumes-nfs-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volumes-nfs-demo
  namespace: dev
  labels:
    app: redis
spec:
  containers:
  - name: redis
    image: redis:alpine
    ports:
    - containerPort: 6379
      name: redisport
    securityContext:
      runAsUser: 1099
    volumeMounts:
    - mountPath: /data
      name: redisdata
  volumes:
    - name: redisdata
      nfs:
        server: 192.168.8.30
        path: /data/redis
        readOnly: false

2. 查看

[root@master01 volumes]# kubectl apply -f volumes-nfs-demo.yaml
进入容器内，发现有dump.rdb
kubectl exec -n dev -it volumes-nfs-demo -- /bin/sh
/data $ ls -l
total 4
-rw-r--r--    1 1099     nobody          92 Jun 19 07:51 dump.rdb
创建文件测试
/data $ touch a

查看nfs-server服务器上的目录中是否有
[root@node02 redis]# pwd
/data/redis
[root@node02 redis]# ls
a  dump.rdb

1.3.4 网络级别rdb类型

apiVersion: v1
kind: Pod
metadata:
  name: volumes-rbd-demo
  namespace: dev
spec:
  containers:
  - name: redis
    image: redis:alpine
    ports:
    - containerPort: 6379
      name: redisport
    volumeMounts:
    - mountPath: /data
      name: redis-rbd-vol
  volumes:
    - name: redis-rbd-vol
      rbd:
        monitors:
        - '192.168.8.61:6789'
        - '192.168.8.62:6789'
        - '192.168.8.63:6789'
        pool: kube
        image: redis-img1
        fsType: xfs
        readOnly: false
        user: kube
        keyring: /etc/ceph/ceph.client.kube.keyring
        #密钥保存在节点上的这个文件内，这意味这每个节点都需要有这个文件

1.3.5 网络级别GlusterFS类型

apiVersion: v1
kind: Pod
metadata:
  name: volumes-glusterfs-demo
  labels:
    app: redis
spec:
  containers:
  - name: redis
    image: redis:alpine
    ports:
    - containerPort: 6379
      name: redisport
    volumeMounts:
    - mountPath: /data
      name: redisdata
  volumes:
    - name: redisdata
      glusterfs:
        endpoints: glusterfs-endpoints
        path: kube-redis
        readOnly: false

1.3.6 网络级别CephFS类型

apiVersion: v1
kind: Pod
metadata:
  name: volumes-cephfs-demo
spec:
  containers:
  - name: redis 
    image: redis:alpine
    volumeMounts:
    - mountPath: "/data"
      name: redis-cephfs-vol
  volumes:
  - name: redis-cephfs-vol
    cephfs:
      monitors:
      - 172.29.200.1:6789
      - 172.29.200.2:6789
      - 172.29.200.3:6789
      path: /kube/namespaces/default/redis1
      user: fsclient
      secretFile: "/etc/ceph/fsclient.key"
      readOnly: false

1.3.7 拉取git仓库的代码到pod目录中

vim volumes-gitrepo-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volumes-gitrepo-demo
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    gitRepo:
      repository: https://github.com/iKubernetes/Kubernetes_Advanced_Practical_2rd.git
      directory: .
      revision: "master"

1.3.8 块存储cinder类型

apiVersion: v1
kind: Pod
metadata:
  name: volume-cinder-demo
spec:
  containers:
   - image: mysql
      name: mysql
      args:
        - "--ignore-db-dir"
        - "lost+found"
      env:
        - name: MYSQL_ROOT_PASSWORD
          value: YOUR_PASS
      ports:
        - containerPort: 3306
          name: mysqlport
      volumeMounts:
        - name: mysqldata
          mountPath: /var/lib/mysql
  volumes:
    - name: mysqldata
      cinder:
        volumeID: e2b8d2f7-wece-90d1-a505-4acf607a90bc
        fsType: ext4

1.3.9 基于CSI接口的longhorn类型

1. 编写yaml并部署

vim volumes-longhorn-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volumes-longhorn-demo
  namespace: dev
spec:
  nodeName: node03
  containers:
  - name: redis
    image: redis:alpine
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
      name: redisport
    volumeMounts:
    - mountPath: /data
      name: redis-data-vol
  volumes:
  - name: redis-data-vol
    persistentVolumeClaim:
      claimName: pvc-dyn-longhorn-demo

2. 验证

登录部署好的pod内的容器
登录redis设置key并保存，可以看到是可读写的
kubectl exec -n dev -it volumes-longhorn-demo -- /bin/sh
/data # redis-cli 
127.0.0.1:6379> set test 1
OK
127.0.0.1:6379> get test
"1"
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> exit
/data # ls
dump.rdb    lost+found

二、pv、pvc和存储类

2.1 pv、pvc存储类的介绍

2.1.1 pv和PVC的关系

pv和pvc是一对一的，一个pv只能绑定一个pvc，一个pvc也只能绑定一个pv
PVC: Persistent Volume Claim，持久卷申请，简称PVC；k8s上标准的资源类型之一； 由用户使用；名称空间级别；
PV： Persistent Volume，持久卷，可被PVC绑定；而PV一定要与某个真正的存储空间（一般是网络存储服务上的存储空间）对应起来，才能真正存储数据。由集群管理员负责管理。集群级别。

2.1.2 Pod使用pv和pvc的步骤

1. 集群管理员Admin：创建好PV；
2. User: 按需创建PVC(PVC创建完成后，需要找到最为匹配的PV，并与之绑定)，而后创建Pod，在Pod调用persistentVolumeClaim类型的存储卷插件调用同一个名称空间中的PVC资源

2.1.3 pvc绑定pv的过程

1. pvc创建好之后在哪里可以找到合适的pv

二者要么都不属于任何StorageClass资源，要么属于同一个StorageClass资源

2. pvc创建好之后怎么找到合适的pv

经过pvc中定义的条件匹配合适的pv

2.1.4 StorageClass存储类介绍

StorageClass：模板, 简称SC；PV和PVC都可属于某个特定的SC；
作用：类似k8s中名称空间：一个PVC只能够在自己所处的SC内找PV；或者，一个不属于任何SC的PVC只能够在不属于任何SC的PV中进行筛选；
工作原理（这里工作原理是以ceph来举例的，可见：本文章 2.3.3.1 ceph类型）：当用户在以下名为fast-rbd存储类内创建了一个pvc，而这个类中并没有合适的pv匹配这个pvc的话，这个类就会利用定义好的账号密码去ceph里创建一个image（在这里的意思是磁盘，因为这是rbd里的image），然后创建一个pv。

StorageClass资源可以写编写一个创建PV的模板：可以将某个存储服务与SC关联起来，并且将该存储服务的管理接口提供给SC，从而让SC能够在存储服务上CRUD（Create、Read、Update和Delete）存储单元；因而，在同一个SC上声明PVC时，若无现存可匹配的PV，则SC能够调用管理接口直接创建出一个符合PVC声明的需求的PV来。这种PV的提供机制，就称为Dynamic Provision(动态提供)。

ceph中的rbd支持动态预配，但kubeadm部署的k8s集群，却不支持该功能，原因在于kube-controller-manager是一个镜像，而镜像内部未内置ceph客户端工具。Controller Manager是一个静态Pod，其中含有PV Controller和PVC Controller

以下是制作有ceph客户端工具的kube-controller-manager镜像的Dockerfile

ARG KUBE_VERSION="v1.19.4"

FROM registry.aliyuncs.com/google_containers/kube-controller-manager:${KUBE_VERSION}

RUN apt update && apt install -y wget  gnupg lsb-release

ARG CEPH_VERSION="octopus"
RUN wget -q -O - https://mirrors.aliyun.com/ceph/keys/release.asc | apt-key add - && \
      echo deb https://mirrors.aliyun.com/ceph/debian-${CEPH_VERSION}/ $(lsb_release -sc) main > /etc/apt/sources.list.d/ceph.list && \
      apt update && \
      apt install -y ceph-common ceph-fuse 

RUN rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*

2.2 选项解释

2.21 pv选项

kubectl explain PersistentVolume.spec
除了存储卷插件之外，PersistentVolume资源规范Spec字段主要支持嵌套以下几个通用字段，它们用于定义PV的容量、访问模式和回收策略等属性。

1. capacity ：指定PV的容量；目前，Capacity仅支持存储容量设定，将来还应该可以指定IOPS和吞吐量（throughput）。
2. accessModes <[]string>：指定当前PV支持访问模式；存储系统支持存取能力大体可分为ReadWriteOnce（RWO单路读写）、ReadOnlyMany（ROX多路只读）和ReadWriteMany（RWX多路读写）三种类型，某个特定的存储系统可能会支持其中的部分或全部的能力。
3. persistentVolumeReclaimPolicy ：PV空间被释放时的处理机制；可用类型仅为Retain（默认保留）、Recycle（回收，把pv内的数据清除，被废弃了）或Delete（pv直接删除）。目前，仅nfs和hostPath支持Recycle策略，也仅有部分存储系统支持Delete策略。
4. volumeMode ：该PV的卷模型，用于指定此存储卷被格式化为文件系统使用还是直接使用裸格式的块设备；默认值为Filesystem，仅块设备接口的存储系统支持该功能。
5. storageClassName ：当前PV所属的StorageClass资源的名称，指定的存储类需要事先存在；默认为空值，即不属于任何存储类。
6. mountOptions ：挂载选项组成的列表，例如ro、soft和hard等。
7. nodeAffinity