-
Notifications
You must be signed in to change notification settings - Fork 225
create a chroot aci for docker and kubelet #34
Conversation
c0c8634
to
27e4c5f
Compare
6839b27
to
76ac6c3
Compare
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 ( |
mkdir -p /opt/kubelet | ||
tar xzvf node.aci -C /opt/kubelet | ||
|
||
mount_in /proc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead why not mount in root, followed by a chroot?
mount_in / true
chroot $ROOTFS
Added my comments. |
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 |
This is blocked by moby/moby#22846 |
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 |
@philips Thanks for the tip. I will attempt to debug this some more... |
|
||
acbuild run -- \ | ||
curl -sSL --fail \ | ||
"https://get.docker.com/builds/Linux/x86_64/docker-1.11.1.tgz" \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @aaronlevy that I am more motivated by coupling kubelet/docker versions then making it easy to install docker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 notifications@github.com 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://github.com/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://github.com/kubernetes/kube-deploy/pull/34/files/3173ffd06edce04392130f4d4a9f27458cd33022#r68332519,
or mute the thread
https://github.com/notifications/unsubscribe/AF8dbMZ0la5he-1RJ21R2EvGIFZuUG7zks5qOxWVgaJpZM4IisM6
.
@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.. |
@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. |
@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. |
./unpack creates a chroot with docker and kubelet sutible for using as the RootDirectory (chroot env) for a systemd unit.