Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My biggest question on Docker / k8s: How does one control where persistent data lives and the required performance characteristics? Example: I need SSD + a certain level of availability? Is there a good strategy for managing this?


Right now, it isn't plumbed in but it is on the roadmap.

Either (a) you have network based block device and the master/manager maps that to a machine dynamically as the container get scheduled or (b) you constrain the containers to machines that have the hardware/data you need.

(b) is less than ideal but sometimes necessary.

Some discussion: https://github.com/GoogleCloudPlatform/kubernetes/issues/598


This is THE open question for Docker right now. The first person to actually solve it is going to be in a pretty damn good place.

Docker could make most infrastructure-level "cloud" abstraction obsolete and let people run resilient, scalable clusters on hardware pretty easily. There's CoreOS, Kubernetes, and a few others in the app-instance-scheduling space, but right now, if you want persistent data storage of any kind (block, SQL, blob, whatever) then you still need to tie things down to an individual machine or use VM-level cloud technology to acheive some semblance of fault tolerance. The inability to do persistent storage in a reasonable way is, from where I sit, the main thing keeping Docker from eating the world.

When you can run Postgres in a stable/supported way in a container on my own hardware that gets scheduled around failure/crowding/etc, you no longer needs AWS, VMWare, etc. That could be huge.


This is also what's holding me back from delving into Docker more. Love the concept, and the workflow, but trying to get my head around how the persistent data storage will work is still troubling me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: