Kubernetes学习（五）持久化存储

最新推荐文章于 2024-08-25 16:17:47 发布

wanghaichao1234

最新推荐文章于 2024-08-25 16:17:47 发布

阅读量836

点赞数

分类专栏： Kubernetes 文章标签： kubernetes 学习 docker

本文链接：https://blog.csdn.net/weixin_42017400/article/details/129407364

版权

Kubernetes 专栏收录该内容

9 篇文章 2 订阅

订阅专栏

Volume 卷

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

Docker也有Volume的概念，但对它是有少量且松散的管理。在Docker中，Volume是磁盘上或者另外一个容器内的一个目录。直到最近，Docker才支持对基于本地磁盘的Volume的生存期进行管理。虽然Docker现在也能提供Volume驱动程序，但是目前功能还非常有限（例如，截止Docker 1.7，每个容器只允许有一个Volume驱动程序，并且无法将参数传递给卷）。

另一方面，Kubernetes卷具有明确的生命周期--与包裹它的pod相同。因此，卷比Pod中运行的任何容器的存活周期都长，在容器重新启动时数据也会得到保留。当然，当一个Pod不再存在时，卷也将不再存在。更重要的是Kubernetes支持许多类型的卷，Pod也能同时使用任意数量的卷。

卷的核心是包含一些数据的目录，Pod中的容器可以访问该目录，特定的卷类型可以决定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。

使用卷时，Pod声明中需要提供卷的类型（spec.volumes字段）和卷挂载的位置（spec.containers.volumeMounts字段）

Kubernetes提供了众多的volume类型，包括emptyDir、hostPath、nfs、glusterfs、cephfs、ceph

emptyDir

当Pod指定到某个节点上时，首先创建的是一个emptyDir卷，并且只要Pod在该节点上运行，卷就一直存在。就像它的名称一样，卷最初是空的。尽管Pod中的容器挂载emptyDir卷的路径可能相同也可能不同，但是，这些容器都可以读写emptyDir卷中相同的文件。当Pod从节点上删除时，emptyDir卷中的数据也会永久删除。

容器崩溃并不会导致Pod从节点上移除，因此容器崩溃时emptyDir卷中的数据是安全的。

emptyDir的用途：

缓存空间，例如基于磁盘的归并排序
为耗时较长的计算任务提供检查点，以便任务能方便地从崩溃状态恢复执行
在web服务器容器服务数据时，保存这些文件

hostPath

hostPath卷能将主机节点文件系统上的文件或目录挂载到Pod中。虽然这不是大多数pod需要的，但是它为一些应用提供强大的持久化能力。

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
      - mountPath: /test-nginx
        name: hostpathvolume
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: 80
  volumes:
    - name: hostpathvolume
      hostPath:
          path: /tmp/nginx
          type: DirectoryOrCreate

NFS卷

很多应用需要在集群内部有一个统一的地方存储文件，比如图片日志等，而使用hostPath方式并不灵活，应为需要指定host的地址

挂载NFS卷

1、安装nfs服务

yum install -y nfs-utils

2、修改配置

vim /etc/exports

/nfsdata *(rw,sync,no_root_squash)

3、在master节点启动nfs

systemctl enable --now rpcbind
systemctl enable --now nfs

4、创建Pod，挂载nfs卷

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
      - mountPath: /usr/share/nginx/html
        name: nfs
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: 80
  volumes:
    - name: nfs
      nfs:
        server: master
        path: /nfsdata

PersistantVolume持久化存储

存储的管理是一个与计算实例的管理完全不同的问题。PersistantVolume子系统为用户和管理员提供了一组API，将存储如果供应的细节从其如何被使用中抽象出来。为了实现这点，我们引入了两个新的API资源：PersistantVolume和PersistantVolumeClaim。

持久卷（PersistantVolume PV）是集群中的一块存储，可以由管理员事先提供，或者使用存储类来动态提供。持久卷是集群资源，就像节点也是集群资源一样，PV持久卷和普通Volume一样，也是使用卷插件来实现的，只是他们拥有独立于任何使用PV的Pod的生命周期。此API对象中记录了存储的实现细节，无论背后是nfs、iSCSI还是特定于云平台的存储系统。

持久卷申领（PersistantVolumeClain PVC）表达的是用户对存储的请求。概念上与Pod类似。Pod会耗节点资源，而PVC申领会耗用PV资源。Pod可以请求特定数量的资源（cpu、内存），同样PVC申领也可以请求特定大小和访问模式

尽管PVC允许用户消耗抽象的存储资源，常见的情况是针对不同的用户需要具有不同属性的PV卷。集群管理员需要能够提供不同性质的PV，并且这些PV卷之间的差别仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。为了满足这类需求，就有了存储类StorageClass资源

示例：pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
  labels:
    name: pv-demo
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /nfsdata
    server: master

[root@master k8s]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-demo   5Gi        RWO            Recycle          Available                                   29s
[root@master k8s]#

PersistantVolumeClain

访问模式

Claim在请求具有特定访问模式的存储时，使用与卷相同的访问模式约定

卷模式

Claim使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
  labels:
    name: pvc-demo
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: 2Gi

[root@master k8s]# kubectl get pvc
NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-demo   Bound    pv-demo   5Gi        RWO                           5s
[root@master k8s]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS   REASON   AGE
pv-demo   5Gi        RWO            Recycle          Bound    default/pvc-demo                           8m32s
[root@master k8s]#

StorageClass

Kubernetes提供了一套可以自动创建PV的机制，Dynamic Provisioning，这个机制单独核心就是StorageClass这个API对象

StorageClass对象定义了以下两部分内容

1.PV的属性，比如存储类型、Volume大小等

2.创建这种PV需要用到的存储插件

为什么需要StorageClass

在一个大规模的Kubernetes集群里，可以有成千上万个PVC，这就意味着运维人员必须实现创建出多个PV。此外，随着项目的需要，会有新的PVC不断被提交，那么运维人员就需要不断的添加新的PV，否则新Pod就会因为PVC绑定不到PV从而导致创建失败。而且通过PVC请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求。

而且不同的应用对于存储性能的要求也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes引入了一个新的资源对象：StorageClass，通过StorageClass的定义，管理员可以将存储资源定义为某种资源类型，比如快速存储、慢性存储等，用户根据StorageClass的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用特性去申请合适的存储资源了。

StorageClass对象的命名很重要，用户使用这个命名请求生成一个特定的类，当创建StorageClass对象时，管理员设置StorageClass对象的命名和其他参数，一旦创建了对象就不能再对其更新。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: qgg-nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
  archiveOnDelete: "false"

示例：PVC&Storage挂载NFS

1、创建Persistent Volume Provisioner

nfs-provisioner.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default #与RBAC文件中的namespace保持一致
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: registry.cn-beijing.aliyuncs.com/qingfeng666/nfs-client-provisioner:v3.1.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: qgg-nfs-storage #provisioner名称,请确保该名称与 nfs-StorageClass.yaml文件中的provisioner名称保持一致
            - name: NFS_SERVER
              value: master #NFS Server IP地址
            - name: NFS_PATH
              value: /nfsdata #NFS挂载卷
      volumes:
        - name: nfs-client-root
          nfs:
            server: master #NFS Server IP地址
            path: /nfsdata #NFS 挂载卷

2、创建用户和角色RBAC

rbac.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default        #根据实际环境设定namespace,下面类同
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
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
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
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: default
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
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

3、创建storage-class

storage-class.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: qgg-nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
  archiveOnDelete: "false"

4、创建PVC

pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"   #与nfs-StorageClass.yaml metadata.name保持一致
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

5、创建Pod，引用Storage Class

pod.yaml

kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-pod
    image: nginx
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && exit 0 || exit 1"
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim  #与PVC名称保持一致