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

It's really cool to see this stuff emerging, and the CoreOS folks put out some good info at kubecon. We're currently running k8s on the docker engine like probably just about everyone, but for the same reasons as just about everyone we're interested in seeing the development of standard runtimes for containers and orchestration. Having said that, I'm not sure I'm all in on this idea of "pod sandboxes" as the environment in which application components are grouped. I may just need to wrap my head around it, but after getting comfortable with the cluster as the sandbox for applications composed of pods I guess I haven't grasped the utility of the additional abstraction.


The pod sandbox is the abstraction that replaces the "pause" container that is used to keep namespaces open in every Kubernetes pod today.

Some techinical explanation here: https://groups.google.com/forum/#!topic/kubernetes-users/jVj...

So,a normal Kubernetes user will never know about rkt pod sandboxes and Kubernetes pods will just work as expected. Only you won't have all of these weird "pause" containers everywhere.


+1 Death to `pause` (and it's largely my fault in the first place)


Thanks, that makes sense. I always thought of the pause container as "being" the pod in the networking sense, so if the pod sandbox simply replaces that I guess they could have just called it a pod.




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

Search: