IKO - Lessons Learned (Part 4 - The Storage Class)

The IKO will dynamically provision storage in the form of persistent volumes and pods will claim them via persistent volume claims.

But storage can come in different shapes and sizes. The blueprint to the details about the persistent volumes comes in the form of the storage class.

This raises the question: we've deployed the IrisCluster, and haven't specified a storage class yet. So what's going on?

You'll notice that with a simple

kubectl get storageclass

you'll find the storage classes that exist in your cluster. Note that storage classes are a cluster wide resource, not per namespace as other objects, like our pods and services.

You'll also notice that one of the storage classes is marked as default. This is the one that the IKO takes when we do not specify any. What if none are marked as default? In this case we have the following problem:

Persistent volumes are not able to be created, which in turn means persistent volume claims are not bound and therefore the pod is stuck in a pending state. It's like going to a restaurant and after looking at the menu telling the waiter/waitress that you'd like to order food, close the menu, hand it back to your server, and say thanks. We need to be more specific or our instructions are so vague that they mean nothing.

To solve this problem you could either set a default storage class in your cluster, or set the storage class name field in the CRD (this way you don't need to change what your default cluster storage class is in case you choose to use the non default storage class):

apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
  name: simple
spec:
  licenseKeySecret:
    #; to activate ISC license key
    name: iris-key-secret
  configSource:
    #; contains CSP-merge.ini, which is merged into IKO's
    #; auto-generated configuration.
    name: iris-cpf
  imagePullSecrets:
    - name: intersystems-pull-secret
  storageClassName: your-sc

  topology:
    data:
      image: containers.intersystems.com/intersystems/irishealth:2023.3
      compatibilityVersion: "2023.3"
      mirrored: true
      webgateway:
        image: containers.intersystems.com/intersystems/webgateway:2023.3
        type: apache
        replicas: 1
        applicationPaths:
          - /csp/sys
          - /csp/healthshare
          - /api/atelier
          - /csp/broker
          - /isc
          - /oauth2
          - /ui
        loginSecret:
           name: iris-webgateway-secret
           
    arbiter:
     image: containers.intersystems.com/intersystems/arbiter:2023.3
    webgateway:
      replicas: 1
      image: containers.intersystems.com/intersystems/webgateway:2023.3
      applicationPaths:
        #; All of the IRIS instance's system default applications.
        #; For Management Portal only, just use '/csp/sys'.
        #; To support other applications, please add them to this list.
        - /csp/sys
        - /csp/broker
        - /api
        - /isc
        - /oauth2
        - /ui
        - /csp/healthshare
      alternativeServers: LoadBalancing
      loginSecret:
        name: iris-webgateway-secret

  serviceTemplate:
    # ; to enable external IP addresses
    spec:
      type: LoadBalancer

Note that there are specific requirements for the storage class, as documented in the docs:

"Any storage class you define must include Kubernetes setting volumeBindingMode: WaitForFirstConsumerOpens for correct operation of the IKO."

Furthermore, I like to use allowVolumeExpansion: true.

Note that the provisioner of your storage class is platform specific.

The storage class pops up all over the CRD so remember to set it when you are customizing your storage for your cluster, in order to make sure you use the storage class that's right for you.