背景介绍：
    近期使用gitlab-ci构建服务的时候发现build过程非常慢，大约要十分钟上，以前也就5分钟内，根据gitlab-ci的build日志发现下面报错

    1. section_start:1597140526:restore_cache
    2. Restoring cache
    3. Checking cache for maven-caches...
    4. FATAL: file does not exist                       
    5. Failed to extract cache
    6. section_end:1597140527:restore_cache
    7. section_start:1597140527:step_script

    原理介绍：
    gitlab-ci build结束时，会将jar打包时相关依赖包上传至自建的对象缓存服务【https://docs.min.io/cn/】，下一次构建时，如果没有添加新的依赖时，会首先到缓存服务中下载相关依赖，减少大部分依赖下载的时间。

    根据上面的报错信息我们知道可能是缓存服务minio出现问题，果然打开mino发现什么文件都没有了，到k8s服务中查看，对应的硬盘没有了，可能是我不小心删除了【细思极恐啊】。

    解决方案：
    在不重新发版，不动用服务的情况下，我们只需要重新添加新的pv即可。

    1、找到pod服务 [存储]中服务的claimName
    2、在存储声明中创建上面claimName的pvc
    3、存储卷不需要任何操作，会自动创建高效云盘，并绑定存储声明上
    4、云盘中查询 云盘自动绑定到了k8s其中任何一个节点服务器上即可。
    5、由于minio服务有2个pod服务，他们共享一个pv，但是创建完一个文件夹【说明添加的pv对应的磁盘不需要额外格式化】刷新后，发现文件夹偶现，说明这种存储类型【alicloud-disk-available】不支持多个pod服务共享，于是将pod调整为一个即可。
    image.png
    PV的访问模式有三种：

    **第一种，ReadWriteOnce：**是最基本的方式，可读可写，但只支持被单个Pod挂载。
**第二种，ReadOnlyMany：**可以以只读的方式被多个Pod挂载。
**第三种，ReadWriteMany：**这种存储可以以读写的方式被多个Pod共享。不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较常用的是NFS。
在PVC绑定PV时通常根据两个条件来绑定，一个是存储的大小，另一个就是访问模式。

    关于gitlab-ci缓存配置后记：

    gitlab配置缓存服务minio，每次build前拉取已经存在的依赖，有新的依赖加入时，会重新拉取，build结束时，
重新上传到缓存服务中。
这部分的功能存在于.gitlab-ci.yml中
cache:
  key: maven-caches
  paths:
    - .m2/repository/

 而缓存服务minio则配置在每个gitlab-runner中的/etc/gitlab-runner/config.toml
 [runners.cache]
    Type = "s3"
    Shared = true
    [runners.cache.s3]
      ServerAddress = "storage.wlc.cn"
      AccessKey = "AKIEPLEXAM"
      SecretKey = "wJEEXAMKEY"
      BucketName = "gitlab-runner-caches"
      Insecure = true
    [runners.cache.gcs]

修改完配置不需要重新启动gitlab-runner
If you edit config.toml, then for most options, the Runner does not require a restart. It checks the file every five minutes and automatically picks up any changes. This includes any parameters that are defined in the [[runners]] section and most parameters in the global section, except for listen_address