No default storageclass for PVC when using Gravity generic cloud provider

Hello,
When creating a Gravity cluster with statefulsets and volumeClaimTemplates on a generic cloud provider (sudo ./gravity install --cloud-provider=generic), how should:

  1. provision a storageClass ? If so, what provisioner should it use ?
    For example, “docker.io/hostpath” did not work. The kubectl get events expectedly shows the following message:
    “waiting for a volume to be created, either by external provisioner “docker.io/hostpath” or manually created by system administrator”
kind: StorageClass
apiVersion: storage.k8s.io/v1
reclaimPolicy: Delete
allowVolumeExpansion: true
metadata:
  name: storageclass-hostpath
  labels:
    provider: docker
provisioner: docker.io/hostpath
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: local-test
spec:
  serviceName: "local-service"
  replicas: 3
  selector:
    matchLabels:
      app: local-test
  template:
    metadata:
      labels:
        app: local-test
    spec:
      containers:
      - name: test-container
        image: k8s.gcr.io/busybox
        command:
        - "/bin/sh"
        args:
        - "-c"
        - "sleep 100000"
        volumeMounts:
        - name: local-vol
          mountPath: /usr/test-pod
  volumeClaimTemplates:
  - metadata:
      name: local-vol
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "storageclass-hostpath"
      resources:
        requests:
          storage: 368Gi
  1. What alternatives are available, if the hostpath provisioner is not going to work - should one look at solutions like Rook ?

Thanks.

Hi @chetananand,

Welcome to the Gravitational Community!

I believe we already replied to this question in our community Slack, so I’m just gonna cross-post the answer here for easier discoverability.

Gravity by default does not install any automatic volume provisioners so if you want to use persistent volumes, you will either need to create PersistentVolume objects manually in the cluster or deploy a dynamic provisioner yourself.

For example, there is the local volume provisioner provided by Kubernetes folks. There is also one from OpenEBS which I know some of our customers successfully run.

Keep in mind though that most volume provisioners (incl. the ones mentioned above as well as Rook and others) require privileged containers which are at the moment of this writing are disabled in Gravity. We’re now working on adding ability to optionally enable them, this feature should land in next 6.0 and 6.1 patch releases and of course will be included in all future major releases as well.

Another way to solve this right now is to build your own custom runtime container where you can enable privileged containers yourself and tweak any of the system components to your liking. This is obviously a much more flexible but undoubtedly more involved way, the instructions on how to do that are available in our documentation.

Hope this helps,
Roman