Somewhat related: can anyone recommend a simple solution to share each node’s ephemeral disk/“emptyDir” across the cluster? Speed is more important than durability, this is just for a temporary batch job cluster. It’d be ideal if I could stripe across nodes and expose one big volume to all pods (JBOD style)
Show HN: Searchable Kubernetes CSI provider listing
11–20 of 23 posts
Re: Show HN: Searchable Kubernetes CSI provider listing
#12Earlier quoted context omitted.
What problem are you trying to solve with replicated storage? A lot of times, finding a solution further up the stack or settling for backups ends up being more robust and reliable. Many folks have been burnt by all the fun failure scenarios of replicated filesystems.
I build a platform which hosts a few thousand services and tens of thousands of nodes. Currently, those services need to each internally manage replicating data and need to be aware of failure domains (host, rack, data center). What I would like to do is develop a system where applications just need to request replicated volumes which span a specific failure domain and push that logic down to the platform.
Rook would suit your problem space very well.
Re: Show HN: Searchable Kubernetes CSI provider listing
#13Disclaimer: My full time job involves developing a CSI driver that is on this list (not simplyblock, but I won't say more than that to avoid completely doxxing myself).
A lot of this chart seems weird - is it somehow autogenerated?
For example, what does it mean for a driver to support ReadWriteOncePod? On Kubernetes, all drivers "automatically" support RWOP if they support normal ReadWriteOnce. I then thought maybe it meant the driver supported the SINGLE_NODE_SINGLE_WRITER CSI Capability (which basically lets a CSI driver differentiate RWO vs RWOP and treat the second specially) - but AliCloud disk supports RWOP on this chart despite not doing that (https://github.com/search?q=repo%3Akubernetes-sigs%2Falibaba...).
Another example, what does it mean for a driver to support "Topology" on this chart? The EBS driver allegedly doesn't despite using most (all?) of the CSI topology features: https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/7...
Also, listing "ephemeral volume" support is kinda misleading because Kubernetes has a "generic ephemeral volumes" feature that lets you use any CSI driver (https://kubernetes.io/docs/concepts/storage/ephemeral-volume...).
Re: Show HN: Searchable Kubernetes CSI provider listing
#14Earlier quoted context omitted.
I build a platform which hosts a few thousand services and tens of thousands of nodes. Currently, those services need to each internally manage replicating data and need to be aware of failure domains (host, rack, data center). What I would like to do is develop a system where applications just need to request replicated volumes which span a specific failure domain and push that logic down to the platform.
Rook would suit your problem space very well.
Thank you
Re: Show HN: Searchable Kubernetes CSI provider listing
#15While this may be useful to some folks, it appears to be content marketing for https://www.simplyblock.io/ , FYI.
Simplyblock sponsors the domain, yes. Good point. Should have mentioned that. It's not on the simplyblock github account though and as you can see on GitHub, I've built it over the weekend :)
Re: Show HN: Searchable Kubernetes CSI provider listing
#16Disclaimer: My full time job involves developing a CSI driver that is on this list (not simplyblock, but I won't say more than that to avoid completely doxxing myself). A lot of this chart seems weird - is it somehow autogenerated? For example, what does it mean for a driver to support ReadWriteOncePod? On Kubernetes, all drivers "automatically" support RWOP if they support normal ReadWriteOnce. I then thought maybe…
I bet there are lots of mistakes yet. It's not really automatically generated, but I started from the list at https://kubernetes-csi.github.io/docs/drivers.html and split the table into a YAML file, marking the features that are mentioned in the docs.
Fixed a few, where I saw thinks in their respective docs, and added features like file or object storage. Also added a few that weren't mentioned.
Topology is https://kubernetes-csi.github.io/docs/topology.html, ReadWriteOncePod is supposed to mean https://kubernetes.io/blog/2023/04/20/read-write-once-pod-ac...
Re: Show HN: Searchable Kubernetes CSI provider listing
#17Somewhat related: can anyone recommend a simple solution to share each node’s ephemeral disk/“emptyDir” across the cluster? Speed is more important than durability, this is just for a temporary batch job cluster. It’d be ideal if I could stripe across nodes and expose one big volume to all pods (JBOD style)
You need some type of cluster-wide shared memory?
Re: Show HN: Searchable Kubernetes CSI provider listing
#18Does anyone have good experiences with a replicated storage CSI which can run on commodity hardware? I tried out OpenEBS Replicated — and it is promising — but it doesn’t really seem mature yet. Im a bit scared to put production critical data into it.
Longhorn, hands down. It’s dead simple to set up and works well with production workloads. We’ve had disks fail, nodes fail, etc. and it has handled everything brilliantly. It’s also near-native speeds, which is really nice.
Re: Show HN: Searchable Kubernetes CSI provider listing
#19Does anyone have good experiences with a replicated storage CSI which can run on commodity hardware? I tried out OpenEBS Replicated — and it is promising — but it doesn’t really seem mature yet. Im a bit scared to put production critical data into it.
Longhorn, hands down. It’s dead simple to set up and works well with production workloads. We’ve had disks fail, nodes fail, etc. and it has handled everything brilliantly. It’s also near-native speeds, which is really nice.
Near native speeds? I’m seeing an order of magnitude slower performance out of mine.
Doing anything special with your config? I already am setting placement options and played with replica options.
My only hope has been to wait for the V2 engine to become stable.
Re: Show HN: Searchable Kubernetes CSI provider listing
#20Earlier quoted context omitted.
Longhorn, hands down. It’s dead simple to set up and works well with production workloads. We’ve had disks fail, nodes fail, etc. and it has handled everything brilliantly. It’s also near-native speeds, which is really nice.
Near native speeds? I’m seeing an order of magnitude slower performance out of mine. Doing anything special with your config? I already am setting placement options and played with replica options. My only hope has been to wait for the V2 engine to become stable.
I guess it depends on how you are measuring it! If you compare it to running it on a RAID5, it is. We are running it on a RAID0 and using Longhorn replication to provide replication instead of the RAID and using striping to get more throughput.