Using the k3s embebbed etcd datastore for other system related components?

[migs35323]

Hello, i have a "system component" that requires a database/datastore and i would like to know if its ok to use the embebbed k3s etcd with other stuff other than k3s itself

I wanted to try out JuiceFS, which requires a database, and since k3s already has the embebbed etcd i tought it should be perfect for my scenario.
In normal SQL instances (or even redis) we can have several databases in a system, so i thought, i can create anther DB in the embebbed etcd cluster

To deploy inside kubernetes, it require a database or datastore to host metadata, which you guess what, requires persistent storage, the thing i am trying to solve lol

[dereknola]

Your better off just using an external etcd DB and pointing K3s + your other applications to that. See https://docs.k3s.io/datastore/ha.

In terms of persistent storage, look at https://docs.k3s.io/storage

[brandond]

Are you familiar at all with how etcd works? it is not a normal SQL engine and does not have a concept of databases or table namespace. It is a global-namespace key-value store. If you are expecting an app that wants a SQL database, to be able to talk to etcd, you are going to be disappointed.

Even if your app does support etcd, and you could get it to store its entries in a key prefix not used by Kubernetes, I would STRONGLY recommend against it. This is your cluster datastore; don't compromise its operational integrity in service of an app that should be running IN the cluster, not ON the cluster.

[migs35323]

thanks, that explained it very well. i will follow that advice.
I was not really sure about having or not different namespaces (even redis has them),
i guessed since basically every app that i use requires volumes and storage drivers being "system components" i assumed there should be no harm in re-using the etcd that is HA in the cluster