ClusterHQ is shutting down

Re:ClusterHQ is shutting down by tazjin on Thursday December 22, 2016 @06:09PM (#13241243)

> Storage is, essentially, a well-solved problem at the OS level. The fact that this option is marked "single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster" raises eyebrows.

Just to clarify this a bit: Persistent volumes as an API _resource_ in Kubernetes are independent of which node a container requesting them is scheduled on, which is why it makes little sense to have a host-independent host volume.

If you have your storage sorted out on the hosts you can use a "simple" volume to mount it correctly [1]. Scheduling can also be restricted to the correct nodes with that storage by using node selectors / labels.

1: http://kubernetes.io/docs/user-guide/volumes/#hostpath

[ Parent | on HN ]

Re:ClusterHQ is shutting down by TheIronYuppie on Thursday December 22, 2016 @07:10PM (#13241683)

Yep, can't repeat this enough. If you've solved node storage management, you've solved k8s storage management too. Use hostpath and call it a day.

Disclosure: I work at Google on Kubernetes

[ Parent | on HN ]

Re:ClusterHQ is shutting down by chrissnell on Friday December 23, 2016 @12:48AM (#13243125)

Absolutely agree. We just haven't solved node storage management. We need a better way to deal with data storage than simply using StatefulSets and tying database cluster members to a given Kube node.

That's what I'm hoping for in 2017.

[ Parent | on HN ]

Re:ClusterHQ is shutting down by thockingoog on Friday December 23, 2016 @06:22PM (#13247767)

You can either use local disk (thereby tying to a node) or network disk (fully supported, but apparently not good enough in any number of dimensions) or local+replication which kube does NOT currently solve cleanly.

The model I want to see is fast network-centric access to replicated local data. Some vendors are pushing into this space now. 2017 will be exciting.

[ Parent | on HN ]