This would actually require a number of features:

• Configuration of stdin. The Docker remote API includes AttachStdin, OpenStdin, and StdinOnce. The latter would be useful for command execution, such as configuration generators. Currently, we don't open stdin on containers.
• Possibly request for a tty. Currently, we don't allow one to be requested. Useful for interactive containers.
• API for waiting for a pod to be scheduled. (Presumably based on the new Event API.)
• API for tunneling stdin/stdout/stderr. Docker's attach API hijacks the HTTP connection for this.
• Client integration of all of the above.

Interactive containers make it very easy to explore the container environment (e.g., explore the filesystem, print env vars, start the application manually), which is one of the features that makes Docker so accessible to users. As Kubernetes adds more functionality over raw Docker, it will become more important to provide a means for this exploration within the Kubernetes container environment (perhaps running a local cluster), rather than just expecting users to use raw Docker. This could also perhaps be done using ssh or exec, but achieving a similar experience might still require most of the above features.

I think the main use case for non-interactive attachment (StdinOnce, no tty) is execution of containers on multiple inputs, where the user doesn't want to couple the container images to a particular storage system and/or where the data volume is small and using a distributed storage system (e.g., GCS, S3) or data repo (e.g., github, Docker registry) would be overkill (and likely slow). However, as with volumes, I could imagine eventually supporting multiple input sources, in addition to streaming via the API.

Attach is not something we support internally, but is worthy of consideration for making the system more user-friendly and facilitating workflow/orchestration clients.

Port forwarding has been implemented.

Blog post here:
http://blog.kubernetes.io/2015/03/weekly-kubernetes-community-hangout.html