存储管理

Volumes
HostPath
  • 将节点上的文件或目录挂载到 Pod 上,此时该目录会变成持久化存储目录,即使 Pod 被删除后重启,也可以重新加载到该目录,该目录下的文件不会丢失

  • 效果就是容器里的数据和主机里的数据进行共享

  • 配置文件:

apiVersion: v1
kind: Pod
metadata:
  name: test-volume-pd 
spec:
  containers:
  - image: nginx
    name: nginx-volume
    volumeMounts: #相当于选择磁盘放入
    - mountPath: /test-pd # 挂载到容器的哪个目录
      name: test-volume # 挂载哪个 volume
  volumes: #相当于准备磁盘
  - name: test-volume
    hostPath: #与主机共享路径
      path: /data # 节点中的目录
      type: DirectoryOrCreate # 检查类型,在挂载前对挂载目录做什么检查操作,有多种选项,默认为空字符串,不做任何检查


# 类型:
# 空字符串:默认类型,不做任何检查
# DirectoryOrCreate:如果给定的 path 不存在,就创建一个 755 的空目录
# Directory:这个目录必须存在
# FileOrCreate:如果给定的文件不存在,则创建一个空文件,权限为 644
# File:这个文件必须存在
# Socket:UNIX 套接字,必须存在
# CharDevice:字符设备,必须存在
# BlockDevice:块设备,必须存在


EmptyDir
  • EmptyDir 主要用于一个 Pod 中不同的 Container 共享数据使用的,由于只是在 Pod 内部使用,因此与其他 volume 比较大的区别是,当 Pod 如果被删除了,那么 emptyDir 也会被删除。
  • 存储介质可以是任意类型,如 SSD、磁盘或网络存储。可以将 emptyDir.medium 设置为 Memory 让 k8s 使用 tmpfs(内存支持文件系统),速度比较快,但是重启 tmpfs 节点时,数据会被清除,且设置的大小会计入到 Container 的内存限制中。
  • 配置如下:
apiVersion: v1
kind: Pod
metadata:
  name: empty-dir-pd
spec:
  containers:
  - image: alpine
    name: alpine-emptydir1
    command: ["/bin/sh","-c","sleep 3600;"]
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - image: alpine
    name: alpine-emptydir2
    command: ["/bin/sh","-c","sleep 3600;"]
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}
~                                                                                             
~                                                                                             
~                              

  • 这里再进入容器的时候,需要指定进入到哪一个容器,如:kubectl exec -it empty-dir-pd -c alpine-emptydir1 -- sh
  • 这里可以监听一下试试tail -f a.txt,发现确实有更改。
NFS挂载
  • nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除,nfs 卷的内容在删除 Pod 时会被保存,卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据,并且这些数据可以在 Pod 之间共享。
  • 这里是其他主机上的,可以实现不同节点上的不同pod共享数据
  • 因为不仅跨了主机还跨了网络,所以很慢,
安装NFS
#下面是在想安装的服务端和客户端的代码
#服务端
#下载
 apt update
 apt install nfs-kernel-server

#然后启动
 systemctl start nfs-kernel-server

#创建共享目录
 mkdir -p /home/nfs
 cd /home/nfs
 mkdir rw #读写
 mkdir ro #只读

#设置共享目录,这个是专门设置共享目录的地方
vim /etc/exports
#加入下面两行,意思是在192.168.2.这个网段的所有主机都可以共享
/home/nfs/rw 192.168.2.0/24(rw,sync,no_subtree_check,no_root_squash)
/home/nfs/ro 192.168.2.0/24(ro,sync,no_subtree_check,no_root_squash)

#重新导出共享目录并更改,重启服务
exportfs -ra
systemctl restart nfs-kernel-server


#客户端
#下载
 apt update
 apt install nfs-common

# 创建挂载点并挂在nfs共享目录,这里填的是服务端的ip地址
 mkdir -p /mnt/nfs/rw
 mkdir -p /mnt/nfs/ro
 mount -t nfs 192.168.2.135:/home/nfs/rw /mnt/nfs/rw
 mount -t nfs 192.168.2.135:/home/nfs/ro /mnt/nfs/ro


NFS文件系统挂载
  • 配置如下:
apiVersion: v1
kind: Pod
metadata:
  name: nfs-test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html #在 Nginx web 服务器中,/usr/share/nginx/html 是 Nginx 的默认文档根目录,这意味着当用户请求你的网站时,Nginx 会从这个目录中查找静态文件(如 HTML、CSS、JavaScript 文件等)来响应请求。
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 192.168.2.135 # 网络存储服务地址
      path: /home/nfs/rw/www/index # 网络存储路径
      readOnly: false # 是否只读


  • 创建之后,在网络存储相应的地方加入index.html,也就是/home/nfs/rw/www/index/index.html,然后直接kubectl get po -o wide找到相应pod的ip,然后直接curl就可以看到内容,删了pod之后还会保存。
PV和PVC(最重要的存储)
  • 问题:可能用到存储方式不一样

在这里插入图片描述

  • 持久卷(PersistentVolume,PV) 是集群中的一块存储,可以由管理员事先制备, 或者使用存储类(Storage Class)来动态制备。 持久卷是集群资源,就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样, 也是使用卷插件来实现的,只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节,无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。

  • 这里PV是一个抽象的概念,起到了一个规范的作用,不管背后使用的什么存储系统,操作PV就是操作背后的存储系统。

  • 持久卷申领(PersistentVolumeClaim,PVC) 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源,而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源(CPU 和内存);同样 PVC 申领也可以请求特定的大小和访问模式 (例如,可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载,参见访问模式)。

  • 下图是具体的流程

在这里插入图片描述

生命周期
构建

静态构建

  • 集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息, 并且对集群用户可用(可见)。PV 卷对象存在于 Kubernetes API 中,可供用户消费(使用)。

动态构建

  • 如果集群中已经有的 PV 无法满足 PVC 的需求,那么集群会根据 PVC 自动构建一个 PV,该操作是通过 StorageClass 实现的。
  • 想要实现这个操作,前提是 PVC 必须设置 StorageClass,否则会无法动态构建该 PV,可以通过启用 DefaultStorageClass 来实现 PV 的构建。
绑定
  • 当用户创建一个 PVC 对象后,主节点会监测新的 PVC 对象,并且寻找与之匹配的 PV 卷,找到 PV 卷后将二者绑定在一起。
  • 如果找不到对应的 PV,则需要看 PVC 是否设置 StorageClass 来决定是否动态创建 PV,若没有配置,PVC 就会一致处于未绑定状态,直到有与之匹配的 PV 后才会申领绑定关系。
使用
  • Pod 将 PVC 当作存储卷来使用,集群会通过 PVC 找到绑定的 PV,并为 Pod 挂载该卷。
  • Pod 一旦使用 PVC 绑定 PV 后,为了保护数据,避免数据丢失问题,PV 对象会受到保护,在系统中无法被删除。
回收策略

保留

回收策略 Retain 使得用户可以手动回收资源。当 PersistentVolumeClaim 对象被删除时,PersistentVolume 卷仍然存在,对应的数据卷被视为"已释放(released)"。 由于卷上仍然存在这前一申领人的数据,该卷还不能用于其他申领。 管理员可以通过下面的步骤来手动回收该卷:
1. 删除 PersistentVolume 对象。与之相关的、位于外部基础设施中的存储资产 (例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷)在 PV 删除之后仍然存在。
2. 根据情况,手动清除所关联的存储资产上的数据。
3. 手动删除所关联的存储资产。
如果你希望重用该存储资产,可以基于存储资产的定义创建新的 PersistentVolume 卷对象。

删除

  • 对于支持 Delete 回收策略的卷插件,删除动作会将 PersistentVolume 对象从 Kubernetes 中移除,同时也会从外部基础设施(如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷)中移除所关联的存储资产。 动态制备的卷会继承其 StorageClass 中设置的回收策略, 该策略默认为 Delete。管理员需要根据用户的期望来配置 StorageClass; 否则 PV 卷被创建之后必须要被编辑或者修补。

回收

  • 警告: 回收策略 Recycle 已被废弃。取而代之的建议方案是使用动态制备。
  • 如果下层的卷插件支持,回收策略 Recycle 会在卷上执行一些基本的擦除 (rm -rf /thevolume/*)操作,之后允许该卷用于新的 PVC 申领。
PV
状态
  • Available:空闲,未被绑定

  • Bound:已经被 PVC 绑定

  • Released:PVC 被删除,资源已回收,但是 PV 未被重新使用

  • Failed:自动回收失败

  • 配置文件如下:

apiVersion: v1
kind: PersistentVolume #描述资源对象为PV
metadata:
  name: pv0001 #PV的名字
spec:
  capacity:
    storage: 5Gi # pv 的容量
  volumeMode: Filesystem # 存储类型为文件系统
  accessModes: # 访问模式:ReadWriteOnce(单词)、ReadWriteMany(可以被多个使用)、ReadOnlyMany
    - ReadWriteMany # 可被单节点独写
  persistentVolumeReclaimPolicy: Retain # 回收策略
  storageClassName: slow # 创建 PV 的存储类名,需要与 pvc 的相同
  mountOptions: # 加载配置
    - hard
    - nfsvers=4.1
  nfs: # 连接到 nfs
    path: /home/nfs/rw/test-pv # 存储路径
    server: 192.168.2.135 # nfs 服务地址


PVC
  • pvc绑定pv
  • 配置文件如下:

# 这里是pvc绑定pv
apiVersion: v1
kind: PersistentVolumeClaim #资源类型为pvc
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany # 权限需要与对应的 pv 相同
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi # 资源可以小于 pv 的,但是不能大于,如果大于就会匹配不到 pv
  storageClassName: slow # 名字需要与对应的 pv 相同
#  selector: # 使用选择器选择对应的 pv
#    matchLabels:
#      release: "stable"
#    matchExpressions:
#      - {key: environment, operator: In, values: [dev]}



  • pvc绑定pod

apiVersion: v1
kind: Pod
metadata:
  name: test-volume-pd
spec:
  containers:
  - image: nginx
    name: nginx-volume
    volumeMounts:
    - mountPath: /usr/share/nginx/html # 挂载到容器的哪个目录
      name: test-volume # 挂载哪个 volume
  volumes:
  - name: test-volume
    persistentVolumeClaim: #关联pvc
      claimName: nfs-pvc #要关联到哪个pvc

StorageClass存储类的概念与作用
  • 每个 StorageClass 都有一个制备器(Provisioner),用来决定使用哪个卷插件制备 PV。
  • 如下图:

在这里插入图片描述

实现动态创建NFS-PV案例

  • 先配置nfs-provisioner,StorageClass和RBAC配置
#nfs-provisioner
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
  labels:
    app: 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 #pvc要调用k8s的api,所以要有账号
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs #对应SC里的名字
            - name: NFS_SERVER
              value: 192.168.2.135
            - name: NFS_PATH
              value: /home/nfs/rw
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.2.135
            path: /home/nfs/rw


# StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: -nfs-storage
  namespace: kube-system
provisioner: fuseim.pri/ifs # 外部制备器提供者,编写为提供者的名称
parameters:
  archiveOnDelete: "false" # 是否存档,false 表示不存档,会删除 oldPath 下面的数据,true 表示存档,会重命名路径
reclaimPolicy: Retain # 回收策略,默认为 Delete 可以配置为 Retain
volumeBindingMode: Immediate # 默认为 Immediate,表示创建 PVC 立即进行绑定,只有 azuredisk 和 AWSelasticblockstore 支持其他值


# RBAC配置
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
  namespace: kube-system
rules:
  - 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
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: kube-system
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
  namespace: kube-system
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
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io


  • PVC处于pending状态有两个解决方法:

# 第一种
修改 apiserver 配置文件
vim /etc/kubernetes/manifests/kube-apiserver.yaml

spec:
  containers:
  - command:
    - kube-apiserver
    - --feature-gates=RemoveSelfLink=false # 新增该行
    ......

修改后重新应用该配置
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml


#第二种
将 provisioner 修改为如下镜像之一即可

gcr.io/k8s-staging-sig-storage/nfs-subdir-external-provisioner:v4.0.0

registry.cn-beijing.aliyuncs.com/pylixm/nfs-subdir-external-provisioner:v4.0.0


Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐