Break Kubelet into separate project

[michaelneale]

Does it make any sense to extract the "pod" code into a place that could potentially be combined with docker itself (I say potentially, as the docker project may prefer to leave this out - as a 3rd party tool).

The need to stand up 3 containers for a single app is pretty common - for example - discourse has a setup that stands up a few containers to run their app on a single node: https://github.com/discourse/discourse_docker

The pod concept (at least some of it) may be able to be separated - avoiding a proliferation of formats/tricks to do essentially the same thing.

[thockin]

We're very open to teaching Docker to manage pods. We have discussed with
Docker folks and they also seemed open to it, though the conversations
about it always seem to derail into other topics. In the mean time, we
have been pushing on a few individual changes to add the features required
one-by-one.

On Sun, Jul 13, 2014 at 9:24 PM, Michael Neale notifications@github.com
wrote:

Does it make any sense to extract the "pod" code into a place that could
potentially be combined with docker itself (I say potentially, as the
docker project may prefer to leave this out - as a 3rd party tool).

The need to stand up 3 containers for a single app is pretty common - for
example - discourse has a setup that stands up a few containers to run
their app on a single node: https://github.com/discourse/discourse_docker

The pod concept (at least some of it) may be able to be separated -
avoiding a proliferation of formats/tricks to do essentially the same
thing.

Reply to this email directly or view it on GitHub
#444.

[smarterclayton]

Some discussion here: https://groups.google.com/forum/m/#!topic/docker-dev/1K0Ff7Em18U

I tried to capture the ideas from the unconf about "groups" of containers (which most people seemed to think might not be a terrible idea).

Might be good to list the items out somewhere.

[michaelneale]

libswarm did pop into my mind too - good to see others are discussing and coming to same conclusion.

My specific case was in distributing an open source "app" which is composed of a few containers working in concert. Having an obvious way to run via the docker command: "docker pod run pod.json" seemed like a desirable end goal.

[bgrant0607]

Related docker issue: moby/moby#7576.

[bgrant0607]

/cc @rakyll, who filed #1599, which I closed in favor of this issue.

Kubelet would be useful as a standalone project.

[bgrant0607]

This has a hard dependency on #2742 and a soft dependency on #489. We'd also need to make parts of the Kubernetes API (pods) available to Kubelet.

[bgrant0607]

Due to the difficulties this would create for build and test, we've decided that breaking our code into multiple projects will not happen before we reach our 1.0 milestone.

[proppy]

+1 to split the runPod logic and the PodSpec from pkg/kubelet and pkg/api/v1beta3, it would make written some small tool like podlet a trivial exercise.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale