Kubernetes StorageClass实践


2019年11月26日 15:45:38   1,128 次浏览

手动创建PV不仅繁琐,还可能造成资源浪费。比如某个PV定义的存储空间为10Gi,该PV被某个声明需要8Gi内存的PVC绑定上了,这时候该PV处于Bound状态,无法再和别的PVC进行绑定,PV上剩下的2Gi内存实际上浪费的。StorageClass可以根据PVC的声明,动态创建对应的PV,这样不仅省去了创建PV的过程,还实现了存储资源的动态供应。

StorageClass构成

StorageClass的定义主要包括名称、后端存储的提供者(provisioner)和后端存储的相关参数配置。StorageClass一旦被创建出来,则将无法修改。如需更改,则只能删除原StorageClass的定义重建。

举个简单的StorageClass配置:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage # StorageClass名称
provisioner: fuseim.pri/ifs  # 指定具体存储的提供者
parameters: # 后端存储相关参数配置
  archiveOnDelete: "false"

不同的StorageClass主要区别在于:不同的存储提供者需要填写不同的参数配置,下面实现个NFS作为动态StorageClass存储的例子。

基于NFS存储类型的实践

NFS环境在上一节已经搭建好了,IP为192.168.33.13,路径为/nfs。

在master节点上克隆相关代码:

git clone https://github.com/kubernetes-incubator/external-storage.git

切换到external-storage/nfs-client/deploy目录

cd external-storage/nfs-client/deploy

创建RBAC:

kubectl create -f rbac.yml

接着部署NFS Client Provisioner,部署前修改deployment.yml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client-provisioner
  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: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: mrbird.cc/nfs # 名称随你定义
            - name: NFS_SERVER
              value: 192.168.33.13 # NFS 服务IP
            - name: NFS_PATH
              value: /nfs # NFS 目录
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.33.13 # NFS 服务IP
            path: /nfs # NFS 目录

然后创建该deployment:

kubectl create -f deployment.yml

修改class.yaml配置:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage # StorageClass名称,随你定义
provisioner: mrbird.cc/nfs # 和上面deployment里定义的一致
parameters:
  archiveOnDelete: "false"

创建这个StorageClass:

kubectl create -f class.yml

创建PVC,PVC的定义对应test-claim.yml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
spec:
  storageClassName: managed-nfs-storage # 指定StorageClass名称,即我们上面定义的StorageClass
  accessModes:
    - ReadWriteMany
  resources: 
    requests:
      storage: 1Mi

创建这个PVC:

kubectl create -f test-claim.yml

状态为Bound,说明已经成功绑定上了存储。

查看PV,会看到系统自动创建了PV:

自动创建的PV名称为pvc-3b8c5364-aadb-4b07-a3b5-fddad280fc98。

最后,修改test-pod.yml配置:

kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-pod
    image: busybox # 修改为这个,原先的镜像地址需要科学上网
    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名称,对应上面创建的PVC

该Pod主要就是通过busybox在/mnt目录下创建了个SUCCESS文件。

创建该Pod:

kubectl create -f test-pod.yml

状态为Completed,说明busybox成功执行完了命令并结束了。如果一切顺利的话,在192.168.33.13的/nfs目录下会看到busybox pod创建的SUCCESS文件:

可以看到/nfs目录下新增了一个目录,目录名称格式为:[namespace]-[pvc名称]-[pv名称]。

我们还可以玩一下另一个测试,新建一个test-pod-rc.yml文件:

apiVersion: v1
kind: ReplicationController
metadata:
  name: busybox
spec:
  replicas: 2 # 副本数为2,为了测试共享存储
  selector:
    name: busybox
  template:
    metadata:
      labels:
        name: busybox
    spec:
      containers:
        - image: busybox
          command:
            - sh
            - -c
            - 'while true; do sleep $(($RANDOM % 5 + 5)); done'
          imagePullPolicy: IfNotPresent
          name: busybox
          volumeMounts:
            - name: nfs
              mountPath: "/mnt"
      volumes:
        - name: nfs
          persistentVolumeClaim:
            claimName: test-claim # 指定PVC名称,对应上面创建的PVC

上面busybox做的事情很简单,就是无限期休眠。创建该rc:

可以看到,pod分别部署到了node1和node2上。到node1节点上,进入busybox容器内部的/mnt目录,在该目录下创建一个hello文件:

然后到node2节点上,进入busybox容器内部/mnt目录,观察刚刚在node1节点busybox容器内部创建的hello文件是否已经同步过来了:

可以看到,文件同步成功。并且前面例子创建SUCCESS也同步过来了,这是因为它们指定了同一个PVC。

回到NFS服务器的/nfs目录下,可以看到刚刚创建的hello文件:

发表评论

邮箱地址不会被公开。 必填项已用*标注