This message was deleted.

I don't think you'll find any official Longhorn documentation on using MinIO on top of Longhorn currently, so the community is a good place to turn! (In fact, Longhorn is set to introduce its own experimental S3 Gateway feature in v1.6.0 that will provide a native S3 interface to Longhorn volumes.) One thing I'll throw out there is that it's generally not a good idea to build application replication on top of Longhorn replication. If your application (MinIO) is already replicating (or, in this case, protecting your data with erasure-coding) in a way that gives you confidence, there's probably no good reason to use multiple Longhorn replicas for each volume. Doing so may result in added latency (Longhorn is only as fast as the slowest path between the engine and each replica's physical disk) and unnecessary storage utilization. You may want to consider the

strict-local

option for the global or volume-specific

data-locality

setting. Enabling this option ensures each MinIO volume has only one replica on the same node that its workload pod runs. Assuming MinIO is already protecting your data by distributing it across nodes and disks (+erasure-coding), this should give you the best achievable Longhorn performance.

Sweet, that's the direction I was leaning so will give it a go and see what happens. Thanks for your thoughts.

Unfortunately, no, not really. One thing to consider is that Longhorn encryption currently relies on Kubernetes secrets to store keys. A brief glance at some MinIO documentation suggests MinIO supports external KMS solutions. I think the Longhorn solution is pretty straightforward, but if you have a requirement for (or want to experiment with) KMS, that's still a ways off.