Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Support alternative datastores when deploying K3s clusters #44911

Open
DillonN opened this issue Mar 24, 2024 · 2 comments
Open

[RFE] Support alternative datastores when deploying K3s clusters #44911

DillonN opened this issue Mar 24, 2024 · 2 comments
Labels
kind/enhancement Issues that improve or augment existing functionality

Comments

@DillonN
Copy link

DillonN commented Mar 24, 2024

Is your feature request related to a problem? Please describe.
Currently when deploying a K3s cluster via a node provisioner such as Harvester, etcd is a required component. There is no way to deploy a cluster that uses an alternative datastore such as MySQL or PostgreSQL

Describe the solution you'd like
At a minimum it should be possible to deploy a cluster without any etcd nodes when using K3s. For a full experience, it would be best to have UI options on K3s clusters to select a datastore without having to manually set command line arguments.

Describe alternatives you've considered
It's probably possible to deploy a node pool with control and etcd both enabled, then just swap the datastore after creation. However this seems wasteful as etcd would still be running.

And of course it's possible to create the cluster outside of Rancher and then import it afterward. But this is losing some of the value add that Rancher has for deployment.

Additional context
Not sure if there'd be a way to work this into the etcd snapshot feature, or if that would be incompatible with clusters created this way.

K3s article on datastores: https://docs.k3s.io/datastore

@DillonN DillonN added the kind/enhancement Issues that improve or augment existing functionality label Mar 24, 2024
Copy link
Contributor

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

@DillonN
Copy link
Author

DillonN commented May 25, 2024

Still relevant to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Issues that improve or augment existing functionality
Projects
None yet
Development

No branches or pull requests

1 participant