Files
container.training/slides/flux/openebs.md
2025-11-04 08:19:09 +01:00

4.1 KiB

K03- Installing OpenEBS as our CSI

OpenEBS is a CSI solution capable of hyperconvergence, synchronous replication and other extra features.
It installs with Helm charts.

  • Flux is able to watch Helm repositories and install HelmReleases
  • To inject its configuration into the Helm chart , Flux relies on a ConfigMap including the values.yaml file

.lab[

k8s@shpod ~$  mkdir -p ./clusters/METAL/openebs/ &&                  \
              cp -pr ~/container.training/k8s/M6-openebs-*.yaml      \
                    ./clusters/METAL/openebs/ &&                     \
              cd ./clusters/METAL/openebs/ &&                        \
              mv M6-openebs-kustomization.yaml kustomization.yaml && \
              cd - 

]


Creating an Helm source in Flux for OpenEBS Helm chart

.lab[

k8s@shpod ~$ flux create source helm openebs \
    --url=https://openebs.github.io/openebs  \
    --interval=3m                            \
    --export > ./clusters/METAL/openebs/sync.yaml

]


Creating the HelmRelease in Flux

.lab[

k8s@shpod ~$ flux create helmrelease openebs    \
    --namespace=openebs                         \
    --source=HelmRepository/openebs.flux-system \
    --chart=openebs                             \
    --values-from=ConfigMap/openebs-values     \
    --export >> ./clusters/METAL/openebs/sync.yaml

]


📂 Let's review the files

  • M6-openebs-components.yaml
    To include the Flux resources in the same namespace where Flux installs the OpenEBS resources, we need to create the namespace before the installation occurs

  • sync.yaml
    The resources Flux uses to watch and get the Helm chart

  • M6-openebs-values.yaml
    the values.yaml file that will be injected into the Helm chart

  • kustomization.yaml
    This one is a bit special: it includes a ConfigMap generator

  • M6-openebs-kustomizeconfig.yaml

    This one is tricky: in order for Flux to trigger an upgrade of the Helm Release when the ConfigMap is altered, you need to explain to the Kustomize ConfigMap generator how the resources are relating with each others. 🤯

And here we go!


class: pic

Running Mario


And the result

Now, we have a cluster featuring openEBS.
But still… The PersistentVolumeClaim remains in Pending state!😭

k8s@shpod ~$ kubectl get storageclass
NAME               PROVISIONER        RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
openebs-hostpath   openebs.io/local   Delete          WaitForFirstConsumer   false                  82m

We still don't have a default StorageClass!😤


Manually enforcing the default StorageClass

Even if Flux is constantly reconciling our resources, we still are able to test evolutions by hand.

.lab[

k8s@shpod ~$ flux suspend helmrelease openebs -n openebs
► suspending helmrelease openebs in openebs namespace
✔ helmrelease suspended
k8s@shpod ~$ kubectl patch storageclass openebs-hostpath \
                -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

k8s@shpod ~$ k get storageclass
NAME                         PROVISIONER        RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
openebs-hostpath (default)   openebs.io/local   Delete          WaitForFirstConsumer   false                  82m

]


Now the database is OK

k8s@shpod ~$ get pvc,pods -n movy-test
NAME                                         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/postgresql-data-db-0   Bound    pvc-ede1634f-2478-42cd-8ee3-7547cd7cdde2   1Gi        RWO            openebs-hostpath   <unset>                 20m

NAME                       READY   STATUS    RESTARTS   AGE
pod/db-0                   1/1     Running   0          5h43m
()