Rockstor Kubernetes Edition

Hi all! First post here, long time software NAS user going back to Nexenta about ten years ago. Love what you guys have done. Using Docker as a plugin format is great.

I actually found the project while doing a search for a NAS on new Kubernetes infrastructure. At risk of alienating good folks that I haven’t even met yet, I’d like to make a case for Rockstor as a Helm package for Kubernetes. I apologize for this in advance for being a long post.

When deploying on Kubernetes, one assumes a user has a lot of hardware. Multiple master nodes and storage farms using products like Ceph are typical. But this isn’t a requirement. If one is willing to learn Kubernetes (not a small feat yet), it’s quite possible to run everything on one machine. The reason for doing so is only about managing scale: In exchange for the up-front complexity, one arrives at pretty limitless scale-out capability. Having worked with both BSD jails, Docker and various orchestrators such as DC/OS and Kubernetes (and where CloudFoundry fits somewhere in that spectrum), I strongly feel like Kubernetes is the orchestration winner in the same way Linux itself was starting to win in the UNIX wars 20 years ago.

A typical Kubernetes production deployment is by a team of people that have a few different skills. One of the biggest pain points for new deployers is they have to figure out persistent storage. The Kubernetes community has created what are called “provisioners” for a huge selection of storage providers that range across the entire spectrum of block and file servers. These deployments are usually focused on production scenarios that serve users of containerized applications. This isn’t too much different than what Rockstor itself does, so there’s already a lot of parallels.

For sake of discussion, let’s imagine Rockstor internally deployed a single-node Kubernetes cluster. What kinds of benefits could users get from this?

On the “hobby system” end of the spectrum, a user probably doesn’t need to scale out. If they were running Kubernetes under the covers of the Rockstor UI, they really wouldn’t care if the system was just as reliable. That’s not exactly true in all cases though, for instance if a user was deploying on Raspberry Pi and wanting to learn clustering or just simply ran out of CPU. I don’t know that this use case is particularly interesting for this discussion. And if that’s the primary user, maybe that’s the end of the discussion.

But as I started with, I found Rockstor because I have a need to manage services such as CIFS, TFTP (for PXE boot) and NFSv4. With a very limited set of hardware, I need to run Docker containers on the same nodes that are doing file service. And because I need to scale out the stack, I need to be running Ceph on the nodes. My long term desire for Rockstor would be as the self-service GUI for people who are a part of an LDAP tree and reduced risk of data loss for busy administrators. In my most attractive target state, Rockstor can use Ceph object stores for it’s backing store, layering it’s suite of services on top of the robustness it provides. No other offerings can do this at the present time, and I believe Rockstor may be the closest of any projects out there to being able to provide this. Creating a Helm Chart for Rockstor could be hugely popular in this manner.

The last thing I want to capture is that Rockstor could also be a starter distribution for Kubernetes itself. Packages like DC/OS, Rancher and OpenShift are indeed distributions of Kubernetes in the same way RHEL/CentOS/Fedora, Ubuntu and SuSE are distributions of the Linux kernel. There are dozens of other distributions that provide specializations on things like security. But in the Kubernetes world, there are still no distributions that have built in storage AND run on a single machine. OpenShift might come closest, but anyone who has tried it has told me that the amount of hardware it needs is bordering on outrageous. I can’t over-emphasize how many people I have met on Kubernetes Slack that are desperate to get Kubernetes running with storage and would see a huge benefit to being able to deploy a distro like Rockstor, then deploy Helm charts directly into Rockstor.

My current Git pull of Helm charts is 253 and it grows every day. How much value would there be if every one of those 253 charts was also a Rock-out? What about the visibility afforded to Rockstor if in turn each one of the existing Rock-outs were intermingled as Helm Charts? If this kind of thing existed on at all in Helm, I would not be here writing, I would be done installing.

Thanks for reading this far. I don’t know any of the reasons this is a bad idea and want to learn. I’ve done enough Kubernetes at this point to see apps like FreeIPA that were difficult to deploy because of unexpected issues like dbus, but once overcome, became more than the sum of it’s parts. And I really think Rockstor could be an app like that, filling a need that a lot of people are after.


Hmm, curious why no response here. I’d be grateful to understand if my post is misinformed or something. Please feel free to PM me if that’s more appropriate.

Replacing the docker engine with the full-blown kubernetes stack would make Rockstor heavier. Moot whether it’s worth it to replace rock-ons with helm charts. IMO, Rockstor should focus on what it already does well: storage. Allowing Rockstor storage to be used in Kubernetes has more bang-for-effort IMO.

I noticed on your other post that you noted the FreeNAS provisioner. And if one has a massive FreeNAS deployment, this is a great option. Unless I am missing something, it’s not an option if one has limited hardware and wants to run both Kubernetes and a NAS on the same machine. And when storage and workloads are across a network, we have unnecessary serialization and networking costs.

FreeNAS is a great example of what I was talking about though. They allow FreeBSD jails to be run inside the server. Because there’s no good way to do this otherwise.

Rather than muddle this thread, I’ll respond there.