k8s系列---StorageClass

介绍这个概念前,需要提前知道存储卷pv/pvc之类的概念。

之前的文章有关于EFK日志系统的介绍,里面的环境是测试环境,完全按照教程一步步的操作,甚至注释掉了持久化存储,当真正线上部署时,又抓虾,打开持久化之后,发现里面用的存储方式是stroragecalss,动态生成nfs的pv进行空间分配。

接着就开始这篇文章写作

1:nfs系统创建,因已有该环境,而且就是简单搭建一个nfs,步骤不再描述

2:参考之前的pv/pvc教程文章,验证nfs是否正常,懒得验证

3:运行nfs-client-provisioner

想要动态生成PV,需要运行一个NFS-Provisioner服务,将已配置好的NFS系统相关参数录入,并向用户提供创建PV的服务。官方推荐使用Deployment运行一个replica来实现,当然也可以使用Daemonset等其他方式,这些都在官方文档中提供了。

在创建Deployment之前,一定要按照官方文档中的Step 3部分配置相关的内容。

编写rbac.yaml文件如下:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-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-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    namespace: default
roleRef:
  kind: ClusterRole
  name: nfs-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-provisioner
  apiGroup: rbac.authorization.k8s.io

  

4:编写serviceaccount.yaml文件如下:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-provisioner

  

作者原话(但我没遇到。。。):注意,针对已配置好的NFS系统和自己搭建NFS系统,Deployment中使用的镜像不同!这里踩了一个大坑,在转为使用现成系统后没有修改原来的yaml文件中的镜像,导致持续报错,调试了好长时间才意识到问题。

编写deployment.yaml文件如下:

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-provisioner
    spec:
      serviceAccount: nfs-provisioner
      containers:
        - name: nfs-provisioner
          image: registry.cn-hangzhou.aliyuncs.com/open-ali/nfs-client-provisioner
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: example.com/nfs
            - name: NFS_SERVER
              value: [已配置的NFS系统的IP地址]
            - name: NFS_PATH
              value: [已配置的NFS系统的挂载路径]
      volumes:
        - name: nfs-client-root
          nfs:
            server: [已配置的NFS系统的IP地址]
            path: [已配置的NFS系统的挂载路径]

  

作者原话(就按照他的做吧):

注意,官方文档提供的镜像在国内无法正常下载,在网上找到了一个阿里云的镜像作为替代。参考https://www.centos.bz/2018/04/%E5%AE%9E%E6%88%98kubernetes%E5%8A%A8%E6%80%81%E5%8D%B7%E5%AD%98%E5%82%A8nfs/

这个镜像中volume的mountPath默认为/persistentvolumes,不能修改,否则运行时会报错。

创建后观察Pod能否正常运行。后面如果出现错误,可以用kubectl logs查看这个Pod的日志来查看错误,进行调试。

5.创建StorageClass

编写并创建storageclass.yaml如下:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: nfs
provisioner: example.com/nfs

  

6.创建测试claim

接下来要创建测试的claim,以检测StorageClass能否正常工作:

编写并创建test-claim.yaml如下,注意storageClassName应确保与上面创建的StorageClass名称一致。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim1
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi
  storageClassName: nfs

  

创建后,用kubectl get pvc查看,观察新创建的PVC能够自动绑定PV。

7.创建测试Pod

创建一个测试的Pod使用这个PVC,编写test-pod.yaml文件如下:

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-claim1

  

查看Pod状态是否变为Completed。如果是,则应该能在NFS系统的共享路径中看到一个SUCCESS文件。

这样,StorageClass动态创建PV的功能就成功实现了。

接下来,作者测试的statefulset我用它的yaml总是出错,也贴上来把,但是我在做efk的时候,直接使用就不报错。

我的efk配置:

  persistence:
    enabled: true  #之前的教程都是false,现在把所有的这个都改成true,两处修改
    accessMode: ReadWriteOnce
    name: data
    size: "4Gi"
    storageClass: "nfs"

  

这是作者的statefulset yaml文件

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx1"
  replicas: 2
  volumeClaimTemplates:
  - metadata:
      name: test
      annotations:
        volume.beta.kubernetes.io/storage-class: "nfs"
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      serviceAccount: nfs-provisioner
      containers:
      - name: nginx1
        image: nginx
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: "/persistentvolumes"
          name: test

  

注意,这里的mountPath必须指定为/persistentvolumes,否则会出现表面上PV创建成功,其实在NFS系统中找不到的问题。。。

当发现两个Pod都正常运行,且在NFS系统中能够找到PV,说明试验成功。

进一步的,可以用kubectl exec -it 进入Pod,并创建一个文件,看看在PV中能否发现相同的文件已生成。

以上是参考https://www.cnblogs.com/00986014w/p/9406962.html实现,但是还要自输入nfs地址,发现一个文章不用输入,但是我没验证,连接:

Kubernetes-基于StorageClass的动态存储供应

猜你喜欢

转载自www.cnblogs.com/dribs/p/11693559.html