Hello folks, another question for y'all. We're eva...
# spicedb
d
Hello folks, another question for y'all. We're evaluating SpiceDB and I see the docs explicitly recommend the K8s operator for deployment. Is there a reason why the operator is recommended over deploying an instance of SpiceDB using normal Kubernetes deployment methods?
(Apologies if this is a redundant question.)
My team has experience deploying K8s manifests and usually sticks to pinned versions of image manifests, controlled migrations, etc. We also have run a distributed cache on K8s before ("groupcache"). I think the operator helps configure both, but maybe there's something else I'm missing
e
You can (and people do) run on k8s without the operator. But we use it to run our production spicedb instances, and it makes it a lot harder to get some things wrong that folks often have issues with: setting up the distributed cache correctly, stepping through phased migrations correctly, etc. automatic updates are optional, you can pin to a specific version if you'd like
d
No doubt, it makes it look super seamless. I think generally our K8s folks don't love the idea of deploying custom operators. It's great that is an option though!
Thanks.
3 Views