Kubernetes. k0s – Creación de StorageClass

Hasta ahora cuando he necesitado persistencia en los Deployments he optado en montar un recurso nfs directamente. Esta solución, aunque práctica, no es la mejor forma de conseguir persistencia en Kubernetes.

    spec:
      volumes:
      - name: nfs-motioneye-etc
        nfs:
          server: ip-servidor-nfs
          path: /DPVs/motionEye/etc
          readOnly: false

El primer paso para configurar la persistencia es crear una StorageClass. He elegido el proyecto https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner que permite utilizar el almacenamiento que tengo disponible, un recurso nfs que me proporciona una NAS QNAP.

Empezamos. El primer lugar es necesario configurar todo lo relativo a los permisos. Esta declaración la tienes disponible en https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/blob/master/deploy/rbac.yaml y es este caso ni me molesto en explicarla, así que apply -f y listo.

Lo siguiente, y es donde está la chicha, la declaración de la StorageClass y del Deployment Este último es el que implementa el provisioner.

Lo primero la StorageClass, donde lo más importante sería el provisioner: qnap-nfs-share.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: qnap-nfs-share
parameters:
  archiveOnDelete: "false"

Lo segundo el Deployment que implementa el provisioner anterior.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  namespace: 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
      containers:
        - name: nfs-client-provisioner
          image: registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: qnap-nfs-share
            - name: NFS_SERVER
              value: ip-servidor-nfs
            - name: NFS_PATH
              value: "/DPVs/nfs-external-provisioner"
      volumes:
        - name: nfs-client-root
          nfs:
            server: ip-servidor-nfs
            path: "/DPVs/nfs-external-provisioner"

Ahora toca probarlo y vemos si es verdad que esto funciona.

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

---

kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-pod
    image: busybox:stable
    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

Una vez aplicado, comprobamos tanto en kubernetes como en el NAS si tenemos el PV creado.

$ kubectl get pvc 
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-claim   Bound    pvc-afb79136-3cfc-4e44-8f84-e0adb9fcebc0   1Mi        RWX            nfs-client     50m

Ale pues funciona, ahora toca probarlo en algún deploy más complejo que este test.