I expected to see the Longhorn storage classes I created in rancher-users #harvester

Title

refined-analyst-8898

03/23/2023, 1:26 AM

I expected to see the Longhorn storage classes I created in Harvester available in the K3s cluster I created in Rancher, but only the default class

<http://rancher.io/local-path|rancher.io/local-path>

appears. There must be another step. I see this in StorageClass doc:

Different Longhorn StorageClasses might map to replica policies, or to node schedule policies, or disk schedule policies determined by the cluster administrators

Now I see that I may select the Harvester storage class when creating an image, and may select the image for the nodes when creating a cluster. I see now how the Harvester storage class maps to the node's storage, but what about making Harvester storage classes available in the cluster for PVCs?

full-plastic-79795

03/23/2023, 5:42 AM

Do you mean https://github.com/harvester/harvester/issues/3052 ?

refined-analyst-8898

03/24/2023, 10:00 PM

Skimming a lot of information here. It sounds like the same goal: use Harvester-defined storage classes with the guest cluster's PVCs. Is the current solution applicable only to RKE2 with Harvester as the cloud provider, perhaps?

I am able to select the Harvester cloud provider if I opt-in to deprecated K8s versions and pick 1.24.9+rke2r2 (deprecated). Choosing the same version shown in Mike Russell's screenshot, 1.24.10+rke2r1, this alert appears in the UI:

You cannot select the Harvester cloud provider as the current Harvester version is not compatible with the selected RKE2 Kubernetes version, click here to see which Kubernetes versions are supported.

I am using Rancher 2.7.1 with Harvester 1.1.1.

Thank you for sharing the GH issue about storage tiering. That was a helpful read. If I understood correctly, I should be able to use storage tiering by creating a conformant StorageClass resource in the guest cluster by providing additional manifests when creating the cluster in Rancher. If so, the only remaining problem is to identify a compatible matrix of Rancher, Harvester, and RKE2 versions. I learned from the SUSE support matrix site linked above that I can use Harvester 1.1.1 with Rancher 2.6.9. With those versions the newest RKE2 cluster I can create is v1.22.17+rke2r1. That is older than expected. There appears to be a workaround to change the allowed RKE2 versions for creating clusters in Rancher with Harvester cloud provider, but I don't have enough context to estimate the risk or wisdom of doing that. Is there a better matrix of Rancher, Harvester, and RKE2 versions I can try?

I found that matrix of versions with a guest cluster pvc with default storage class produced a Harvester volume with storage class "longhorn," which is not the default class in Harvester. Additionally, after releasing those guest PVCs, I declared one of the custom SCs I created along with the guest cluster, example below. Still, the PV has the "longhorn" storage class. In this example,

singleton-nvme

is a valid Harvester SC that I expected to use through the CSI in a guest cluster PVC.

---
apiVersion: <http://storage.k8s.io/v1|storage.k8s.io/v1>
kind: StorageClass
metadata:
  name: singleton-nvme
provisioner: <http://driver.harvesterhci.io|driver.harvesterhci.io>
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  hostStorageClass: singleton-nvme

I obtained the same result with RKE2 v1.24.9+rke2r2. It was necessary to opt-in to deprecated versions of RKE2 in Rancher to pick this version. Next I will try stepping forward Rancher from v2.6.9, the version prescribed in the SUSE compatibility matrix.

✅ Storage tiering works in v1.24.11+rke2r1, the default version in Rancher 2.6.11 for Harvester cloud provider.

2 Views

#harvester Join Slack