In Kubernetes, the reference from a container manifest to an image is a "name" - that name is arbitrary and it is up to the user to specific how that name interacts with their docker build and docker registry scenarios. That includes ensuring that the name and label the user uses to refer to their image is not changed accidentally (so that new images aren't introduced outside of a controlled deployment process) and that the registry DNS that hosts the images is continuously available as long as that image may be needed (see docker image discussions for how this might change).

That loose coupling is valuable for flexibility, but the lack of a concrete process leaves room for error and requires thought and control. In addition, the resolution of those names is tightly bound to the execution of the container in the Kubelet.

We think there is value in Kubernetes providing a set of higher level concepts above pods/replication controllers that can be used to create deployable units of containers. Two concepts we see as valuable are "builds" and "deployments" - the former can be used to compose new images (by leveraging the Kubernetes cluster for build slaves with resource control) and the latter can manage the process of transitioning between one set of podTemplates to another (and can be triggered by builds).

First, is this something that should be in Kubernetes? Should it be on top of Kubernetes as a separate server? Or is it something that could be optionally enabled by those who wish to work on it? We've got some ideas of how we could make this flow work really cleanly with Docker and images, but we'd want to get feedback on those ideas.