Docker的文件系统 与Docker容器具有相同的生命周期，但是Docker容器肯定会遇到同时运行到多节
点场景中，这个时候，会因为节点崩溃、服务崩溃、网络原因，导致容器异常退出，所以一旦我们将数据存储到容器内部，肯定会导致数据丢失。

 - Docker镜像是只读的文件，Docker容器可读可写，但是不能够数据持久化。
 所以为了避免这种数据异常丢失的情况，我们一般会将 容器的数据(程序状态数据、应用存储数据等)，存储在容器的文件系统之外。

 - 通过引入外部的存储空间来实现 数据的可持久化效果。

- 通过数据卷 或者 数据卷容器，将当前宿主机上面的文件系统目录与容器里面的工作目录进行一一的关联。
- 即使我们对本地是磁盘做 raid等冗余功能，但是这种等级的安全很鸡肋。

- 通过网络的方式，将外部的存储空间挂载到当前宿主机，然后借助于host机制实现容器数据的可持久化。

有两个关键点：
1、容器引擎对共享式存储设备的支持类型：
 - 多路并行读写 - 多个容器内可以同时对同一个存储设备进行读写操作
 - 多路只读 - 多个容器内可以同时对同一个存储设备进行只读操作
 - 单路读写 - 多个容器内可以通过同一个中间容器对同一个存储设备进行读写操作
2、pod内部容器使用存储卷有两步：
 - 在Pod上定义存储卷，并关联至目标存储服务上
 - 在需要用到存储卷的容器上，挂载其所属的Pod的存储卷

类型            举例
本地数据卷      emptyDir、hostPath、local等
云存储数据卷    gcePersistentDisk、awsElasticBlockStore等
网络存储卷      NFS、gitRepo、NAS、SAN等
分布式存储卷    GlusterFS、CephFS、rdb(块设备)、iscsi等
信息数据卷      flocker、secret等


k8s还支持 CSI(Container Storage Interface)接口方式，来实现更大范围的存储功能扩展。

比如：
Rancher 是为使用容器的公司打造的容器管理平台。Rancher 简化了使用 Kubernetes 的流程，开
发者可以随处运行 Kubernetes，满足 IT 需求规范，赋能 DevOps 团队。这个团队研发的Longhorn就是要给非常好的存储平台。

Longhorn是一个轻量级且功能强大的云原生Kubernetes分布式存储平台，可以在任意基础设施上运
行。Longhorn与Rancher结合使用，将帮助您在Kubernetes环境中轻松、快速和可靠地部署高可用性持久化块存储。

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

虽然这种借助于k8s存储插件的方式，为pod应用引入各种存储机制，但是这种方案有天然的劣势：
 1 要保证所有的pod节点支持后端的指定类型的存储服务。
 2 所有的后端指定服务的配置都要在pod上自定义
 3 这些卷插件将pod定制的配置属性传递给kubelet，然后实现对应的效果。
 -- 从字面上来理解，如果一个开发者要开发一个pod对象，必须首先是一个存储专家，而这是不可能的。
 
所以，使用k8s的门槛高多了。而k8s为了避免这种为用户带来不好影响的现象，引入了两个非常重要的存储资源对象 -- PV 和 PVC

1、由专业的存储管理员来管理所有的存储后端：
 - 在专用的存储设备上，创建各种类型级别的PV(Persistent Volume)
 - 或者通过存储模板文件SC(storageclasses)来自动创建大量不同类型的PV对象。
2、由开发人员定制需要的PVC(Persistent Volume Claim)，然后关联到pod上
3、Pod通过PVC到PV上请求一块独立大小的网络存储空间，然后直接使用

一个emptyDir volume在pod被调度到某个Node时候自动创建的，无需指定宿主机上对应的目录。特点如下：
1、跟随 Pod 初始化而来，开始是空数据卷
2、Pod 移除，emptyDir中数据随之永久消除
3、emptyDir 一般做本地临时存储空间使用
4、emptyDir 数据卷介质种类跟当前主机的磁盘一样。

kubectl explain pod.spec.volumes.emptyDir
  medium   指定媒介类型，主要有 disk Memory(默认) 两种
  sizeLimit 现在资源使用情况
   
kubectl explain pod.spec.containers.volumeMounts
  mountPath   挂载到容器中的路径
  name 指定挂载的volumes名称
  readOnly   是否只读挂载
  subPath   是否挂载子路径

# volume配置样式
 volumes:
 - name: volume_name
   emptyDir: {}
# volume使用样式
 containers:
   - volumeMounts:
       - name: volume_name
         mountPath: /path/to/container/
                  
注意：关于volume和容器的关系，每个容器都可以单独挂载多个volume，每种volume都可以被多个容器挂载

cat >storage-empty.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: nginx-volume
  labels:
    name: nginx-volume
spec:
  volumes:
  - name: empty-volume
    emptyDir: {}
  containers:
    - name: nginx-volume
      image: 192.168.10.33:80/k8s/my_nginx:v1
      volumeMounts:
       - name: empty-volume
         mountPath: /nginx/www/empty/
EOF

# 应用资源配置清单 
master1 storage]# kubectl apply  -f storage-empty.yml 

master1 storage]# kubectl get pods
NAME           READY   STATUS    RESTARTS   AGE
nginx-volume   1/1     Running   0          69s

# 查看挂载的信息
master1 storage]# kubectl describe pod nginx-volume 
...
    Mounts:
      /nginx/www/empty/ from empty-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kd8dw (ro)
...

# 查看目录是否存在
master1 storage]# kubectl exec nginx-volume -- ls /nginx/www
empty

master1 storage]# kubectl exec -it nginx-volume -- /bin/bash
root@nginx-volume:/# 

# 往文件目录写入数据
master1 storage]# kubectl exec -it nginx-volume -- /bin/bash
root@nginx-volume:/# echo "nihao" > /nginx/www/nihao.txt

# 到节点查询文件位置
node1 ~]# find / -name "nihao.txt"
/run/containerd/io.containerd.runtime.v2.task/k8s.io/ec0ce61aa680a89da7d97ea631332e131b05840913e4d691a984516bf35a3e0f/rootfs/nginx/www/nihao.txt
/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/2060/fs/nginx/www/nihao.txt

cat >storage-nginx-volume.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  volumes:
  - name: nginx-index
    emptyDir: {}

  containers:
  - name: nginx
    image: 192.168.10.33:80/k8s/my_nginx:v1
    volumeMounts:
    - name: nginx-index
      mountPath: /usr/share/nginx/html/

  - name: busybox
    image: 192.168.10.33:80/k8s/busybox:latest
    volumeMounts:
    - name: nginx-index
      mountPath: /data/
    command:
    - "/bin/sh"
    - "-c"
    - "while true; do echo $(date) > /data/index.html; sleep 2; done"
EOF

master1 ]# kubectl apply -f storage-nginx-volume.yml 
pod/volume-test created

master1 ]# kubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
volume-test   2/2     Running   0          4s    10.244.3.227   node1   <none>           <none>

master1 ]# curl  10.244.3.227
Thu Mar 23 12:00:55 UTC 2023

hostPath将宿主机上的目录挂载到Pod中作为数据的存储目录，一般用在如下场景：
1、容器应用程序中某些文件需要永久保存
2、某些容器应用需要用到容器的内部数据结构，可将宿主机的/var/lib/docker挂载到Pod中
3、Pod删除，宿主机文件不受影响
hostPath使用注意事项：
1、不同宿主机的文件内容不一定完全相同，所以Pod迁移前后的访问效果不一样
2、宿主机的目录不属于资源对象的资源，所以我们对资源设置的资源配额限制对hostPath目录无效

kubectl explain pod.spec.volumes.hostPath
   path 指定宿主机的路径
   type 指定路径的类型，一共有7种，默认的类型是没有指定空字符串，默认配置，在关联hostPath存储卷之前不进行任何检查,如果宿主机没有对应的目录，也会自动创建
   DirectoryOrCreate 宿主机上不存在，创建此0755权限的空目录，属主属组均为kubelet  
   Directory 必须存在挂载已存在的目录  
   FileOrCreate 宿主机上不存在挂载文件，就创建0644权限的空文件，属主和属组同为kubelet 
   File 必须存在文件
   Socket 事先必须存在的Socket文件路径
   CharDevice 事先必须存在的字符设备文件路径
   BlockDevice 事先必须存在的块设备文件路径
 参考资料：https://kubernetes.io/docs/concepts/storage/volumes#hostpath

volumes:
 - name: volume_name
   hostPath:
     path: /path/to/host

cat >hostpath-redis.yml<<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-redis
spec:
  nodeName: node2
  volumes:
  - name: redis-backup
    hostPath:
     path: /backup/redis
  containers:
    - name: hostpath-redis
      image: 192.168.10.33:80/k8s/redis:latest
      volumeMounts:
       - name: redis-backup
         mountPath: /data
EOF

关键点：
    spec.containers.volumeMounts的name属性和spec.volumes的那么属性完全一致,因为他们是基于name来关联的。  
注意：
    redis的镜像将数据保存到了容器的/data目录下。

master1 ]# kubectl apply -f hostpath-redis.yml 
pod/hostpath-redis created

master1 ]# kubectl get pods -o wide
NAME             READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
hostpath-redis   1/1     Running   0          43s   10.244.4.100   node2   <none>           <none>

# 本地目录存在
node2 ~]# ll /backup/redis/
total 0


# 查看pod的描述信息
master1 ]# kubectl describe pod hostpath-redis
...
    Environment:  <none>
    Mounts:
      /data from redis-backup (rw)
Volumes:
  redis-backup:
    Type:          HostPath (bare host directory volume)
    Path:          /backup/redis
...

# 写数据并且持久化入盘
master1 storage]# kubectl exec -it hostpath-redis -- /bin/bash

root@hostpath-redis:/data# redis-cli 
127.0.0.1:6379> set volume hostpath
OK
127.0.0.1:6379> set name cyc
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> exit

# 删除pod重新创建，看看数据是否存在
[root@master1 storage]# kubectl delete  -f hostpath-redis.yml 
pod "hostpath-redis" deleted

[root@master1 storage]# kubectl apply  -f hostpath-redis.yml 
pod/hostpath-redis created

[root@master1 storage]# kubectl get pods
NAME             READY   STATUS    RESTARTS   AGE
hostpath-redis   1/1     Running   0          3s

[root@master1 storage]# kubectl exec -it hostpath-redis -- /bin/bash

root@hostpath-redis:/data# redis-cli 
127.0.0.1:6379> get name
"cyc"
127.0.0.1:6379> get volume
"hostpath"
127.0.0.1:6379>