Customizable Default Configuration for Storage Class in User Clusters

[csengerszabo]

Description of the feature you would like to add / User story

As a KKP admin
I want the ability to update default configurations within user clusters, particularly for storage classes
In order to customize their behavior according to our requirements.

Solution details

• As a user, I should be able to update the configuration of the storage class in a user cluster.
  • Particularly:
    • allowVolumeExpansion should be configurable and set to true.
    • reclaimPolicy should be configurable and set to Retain.
• The solution should allow for easy extension to accommodate potential future needs for configuring other default settings for user clusters
• The configuration of defaults is applied consistently to every newly created user cluster

Alternative approaches

• reconfigure the defaults, at least for the storageclass for every user cluster being created

Use cases

• Updating the default behaviour of the default storage class of the user clusters

Additional information

• By default, if not explicitly configured, allowVolumeExpansion is deactivated and reclaimPolicy is set to delete

[embik]

This issue needs clarification: Is it end users (people creating clusters) or platform admins (changing the defaults of what is deployed) that should be able to change this? The first section says As a KKP admin, but the solution details say As a user. End users should just deploy their own StorageClasses if the defaults don't suit them.

[judge-red]

If I may chime in as a platform admin: we simply build a custom addons image with our own storage classes included and we then overwrite the addons that are installed through the KubermaticConfiguration, i.e. we removed the default-storage-class addon from the list and added our own. So this is already possible.

I obviously wouldn't be opposed to having an easier solution that doesn't involve building our own addons image and overwriting the addons list. But imho only being able to configure the parameters Csenger mentioned wouldn't be helpful. We'd need to overwrite the default storage classes, probably through the KubermaticConfiguration, completely. For example we also set .parameters.type and we have 4 instead of 2 StorageClasses, because we provide them with both reclaimPolicy: Retain and reclaimPolicy: Delete as different end users have different needs.

[steled]

@embik my 5 cents:
For End Users this is clear, they just deploy their own StorageClass.
For us it is more important from KKP Admin point of view.

I'm with @judge-red. It would be great to have an easier solution than building a custom addon.

[xrstf]

Is this something that could be solved by using the Applications feature in KKP?

[steled]

Hi @xrstf,

IIRC, the application feature needs to be enabled separately for each user cluster.
For us, it would be great if we could generally override or set new defaults.

[judge-red]

@xrstf I think if it was possible to mandate certain applications, like we can with addons, that could work. But I don't think that's currently possible, is it?

That said, we also don't wan't the default StorageClasses defined in the KKP addon, as they're non-functional for us. So we'd still need to overwrite the defaultManifests of the addons to exclude this, which is a pain point, unless these are deployed differently, or we can control deployment in a different way.

[xrstf]

You're right, but overriding the defaultManifests should at least be a bit simpler than maintaining your own set of addons. Apps would make that maintenance a bit easier was my thinking.

[judge-red]

Simpler yes. But just recently we ran into the issue that addons were removed from KKP and we missed that we should remove them from the defaultManifests. It was a quick fix, but it's still something we need to maintain and for which it's hard to monitor upstream changes (i.e. changes in the default defaultManifests).