create a chroot aci for docker and kubelet

[mikedanese]

./unpack creates a chroot with docker and kubelet sutible for using as the RootDirectory (chroot env) for a systemd unit.

[mikedanese]

cc @vishh @aaronlevy @roberthbailey

[aaronlevy]

I like the bash rkt-fly! Overall this lgtm.

Interested in your thoughts on the fixed chroot location Vs treating it more like a container. For example, if the node "container" is run with rkt, rootsfs would end up under separate UUIDs each time ( /var/lib/rkt/pods/run/<UUID>).

[vishh]

Instead why not mount in root, followed by a chroot?

mount_in / true
chroot $ROOTFS

[vishh]

Added my comments.

[aaronlevy]

Thinking about this a bit more, I kind of like the idea of running from a fixed location. That should skirt issues like: rkt/rkt#2553

[mikedanese]

This is blocked by moby/moby#22846

[philips]

Hrm, I have played with running Docker under rkt before and I remember it working. Let me try it again. Here is the gist: https://gist.github.com/philips/4ba6f9888499266b0ab09d95991e6784

[mikedanese]

@philips Thanks for the tip. I will attempt to debug this some more...

[derekwaynecarr]

is it too much to assume that docker will already be installed?

the version of docker to pull is very OS specific, and I struggle to think users will not have it already if they plan to use it.

[aaronlevy]

My increasing concern here is the "kubernetes supports docker vX". This has already become a little fragile with the CoreOS release cycle, where we have shipped docker too soon from k8s perspective (k8s v1.1 & docker v1.10 iirc), then with the upcoming k8s- v1.3 release it was unclear if v1.11 was going to be the blessed version (while even CoreOS alpha still had v1.10).

Decoupling this from the underlying host would (hopefully) make this a little easier to reason about / ship updates as atomic units.

[mikedanese]

Agree with @aaronlevy that I am more motivated by coupling kubelet/docker versions then making it easy to install docker.

[derekwaynecarr]

The community itself doesn't agree on the version of docker to use in kube
1.3, I think this blesses a particular version moving forward. I prefer
it's removed. Maybe I just don't understand the expectation for this PR
generally.

On Thursday, June 23, 2016, Mike Danese [email protected] wrote:

In node-aci/build
#34 (comment):

+set -o xtrace
+
+rm -f node.aci
+
+docker2aci docker://debian:jessie
+
+acbuild begin ./library-debian-jessie.aci
+
+acbuild run -- apt-get update
+acbuild run -- apt-get install -y -q apparmor curl iptables
+acbuild run -- apt-get autoremove
+acbuild run -- apt-get clean
+
+acbuild run -- \

• curl -sSL --fail \
• "https://get.docker.com/builds/Linux/x86_64/docker-1.11.1.tgz" \

Agree with @aaronlevy https:/aaronlevy that I am more
motivated by coupling kubelet/docker versions then making it easy to
install docker.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https:/kubernetes/kube-deploy/pull/34/files/3173ffd06edce04392130f4d4a9f27458cd33022#r68332519,
or mute the thread
https:/notifications/unsubscribe/AF8dbMZ0la5he-1RJ21R2EvGIFZuUG7zks5qOxWVgaJpZM4IisM6
.

[vishh]

@mikedanese As discussed offline today, can we instead use rkt fly to run kubelet and not depend on docker for bootstrapping the kubelet? The rkt dependency is only for kubelet and users can choose to use any runtime..

[mikedanese]

@vishh Yes I would like to use rkt to run this in kubernetes-anywhere if we decide to do this, but I also want it to be possible to use this without the rkt dependency. We can't use the upstream stage1_fly aci until rkt/rkt#2567 is fixed. I have a custom stage1 that solves this for now.

[derekwaynecarr]

@mikedanese - is there a rough flow where this is anticipated to use? i thought the baseline was users come with a machine that conforms to a node spec (container runtime there, networking there), and then we do something. I am not sure where to view this PR in a broader context.

[k8s-reviewable]

This change is