SaaSHub helps you find the best software and product alternatives Learn more →
Rook Alternatives
Similar projects and alternatives to rook
-
-
-
SonarLint
Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.
-
-
Nginx Proxy Manager
Docker container for managing Nginx proxy hosts with a simple, powerful interface
-
-
zfs-localpv
CSI Driver for dynamic provisioning of Persistent Local Volumes for Kubernetes using ZFS.
-
-
InfluxDB
Build time-series-based applications quickly and at scale.. InfluxDB is the Time Series Platform where developers build real-time applications for analytics, IoT and cloud-native services. Easy to start, it is available in the cloud or on-premises.
-
-
awesome-home-kubernetes
⚠️ Deprecated: Awesome projects involving running Kubernetes at home
-
-
flux2
Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
-
-
-
-
Harbor
An open source trusted cloud native registry project that stores, signs, and scans content.
-
Keycloak
Open Source Identity and Access Management For Modern Applications and Services
-
-
cdk8s
Define Kubernetes native apps and abstractions using object-oriented programming
-
local-path-provisioner
Dynamically provisioning persistent local storage with Kubernetes
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
rook reviews and mentions
-
Running on-premise k8s with a small team: possible or potential nightmare?
Storage: Favor any distributed storage you know to start with for Persistent Volumes: Ceph maybe via rook.io, Longhorn if you go rancher etc
-
My completely automated Homelab featuring Kubernetes
I've dealt with a lot of issues that are very close to just unplugging a node. Unfortunately on node lost, my stateful workloads using rook-ceph block storage won't migrate over to another node automatically due to an issue with rook. Stateless apps (ingress nginx, etc..) not using rook-ceph block failover to another node just fine. I've kind of accepted this for now and I know Longhorn has a feature that makes this work but I find rook-ceph to be more stable for my workloads.
-
[HELP] PXE Boot without data loss
Third, it sounds like you're building a cluster. For this you'll either want a central file server. Or better, setup a distributed storage system. For example a Ceph cluster managed by Rook. This way you can fully wipe a single node and the system will be able to recover/replicate thed data.
- SaaS Deployment Options
-
For those managing k8s clusters, are you using Rook + Ceph?
I just helped write a quick summary of just why you can trust your persistent workloads to Ceph, managed by Rook and it occurred to me that... I'm probably wrong.
-
Turning SQLite into a Distributed Database
So I just fell down the rabbit hole of figuring out how to use SQLite with Ceph (turns out a thing called libcephsqlite[0][1] exists) -- awesome to see this new take on distributed SQLite.
The caveats for dqlite and rqlite always felt kind of awkward/risky to me -- in stark contrast to SQLite which is so stable/"built in" that you don't think about it's failure modes. Having to worry about what exactly I ran (ex. RANDOM()) was just a non-starter (IIRC rqlite has this problem but not dqlite? or the other way around -- one replicates at statement level the other at WAL level).
That said though, the biggest sticking point with all this SQLite goodness is how to make sure that certain libraries (any popular extension -- vsv, spatialite, libcephsqlite) were loaded for any application using SQLite -- there seem to be only a few options:
- calling load_extension[2] from code (this is somewhat frowned upon, but maybe it's fine)
- LD_PRELOAD (mvsqlite does this)
- Building your own SQLite and swapping out shared libs (mvqslite also does this, because statically compiled sqlite is a nuisance)
- Trapping/catching calls to dlopen (also basically requires LD_PRELOAD, but I guess you could go custom kernel or whatever)
This is probably the one big wart of SQLite -- it's a bit difficult to pull in new interesting extensions.
[0]: https://docs.ceph.com/en/latest/rados/api/libcephsqlite/
[1]: https://github.com/rook/rook/issues/10689
[2]: https://www.sqlite.org/lang_corefunc.html#load_extension
-
Openebs ?? Or equivalent
As far as the dynamic, node-migratable persistent storage goes, you probably want Rook (Ceph) at this point. OpenEBS Jiva (i.e. Longhorn) is good, and cStor is decent (but worse, perf wise right now), but there is also Mayastor (there were some limitations that made me not choose mayastor), but I think they're both not as great as ceph -- ceph just has more man years/decades of effort in it, and it's a much more flexible system (and more complex, but sometimes it's worth it).
-
Self Hosted Kubernetes - Solving the Storage Problem
Commenting on the distributed storage (cephfs) section.. we use https://rook.io/, which provides an operator to manage the nasty complexities of ceph on Kubernetes. I like it because it means I can manage the cluster lifecycle with a (not-so-simple) YAML, just like everything else :)
-
Distributed storage
Do know that ODF has ...substantial... resource requirements. You may want to consider using the upstream rook.io with ceph and a custom configuration.
-
Interesting tools?
rook+ceph : baremetal persistant storage
-
A note from our sponsor - #<SponsorshipServiceOld:0x00007fea595cd208>
www.saashub.com | 3 Feb 2023
Stats
rook/rook is an open source project licensed under Apache License 2.0 which is an OSI approved license.