Skip to content

Instantly share code, notes, and snippets.

@tjdett
Last active October 26, 2016 23:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tjdett/7c5e97dcd83a018c3baa583bf559ec5e to your computer and use it in GitHub Desktop.
Save tjdett/7c5e97dcd83a018c3baa583bf559ec5e to your computer and use it in GitHub Desktop.
Kublet & rkt from #rkt @ 2016-10-26T13:44Z
<waly> Hi everyone
<waly> I've read somewhen in the past, that rkt provides a better featureset for the kubelet than docker does. Was somehow around the context, why the kubelet-wrapper is using rkt ... Can somebody explain that/point me to the missing link about that?
<vincent_vdk> waly: maybe because rkt is pod 'aware'
<sur> waly The are two aspects: 1) launching the kubelet and 2) launching pods
<sur> for 1) launching the kubelet the kubelet-wrapper uses rkt, because we can leverage the https://quay.io/repository/coreos/hyperkube image to launch the kubelet using "rkt fly", which doesn't do any isolation, but only chroot, because the kubelet is a privileged component on the host. That way we can reuse the same (hyperkube) image for both the kubelet, and
<sur> all the other kubernetes components (proxy, apiserver, ....)
<sur> for 2) launching pods from withing the kubelet you can also use rkt as the container runtime. There are quite a few nice points for doing so, one summary I tried to give i.e. in this presentation https://speakerdeck.com/surbaniak/microservices-meetup-rkt-plus-kubernetes-equals-rktnetes.
<sur> some points for rkt are, that it understands pods natively, and runs separate processes per pod (no single daemon)
<sur> I hope this helps a bit :-)
<waly> That was a great explanation - thanks! Plus it somehow faces why there's only hyperkube and not apiserver etc
<sur> waly yes, the hyperkube is a single binary which lets you launch all k8s components as subcommands, i.e. "hyperkube kubelet", "hyperkube api-server", ....
<waly> ... but ... Sometimes I want to have only 1(or probably 2) components where hyperkube might be an overkill - there a no official kube-apiserver e.g.?
<sur> If you don't want the other components, then just don't start them ;-) I think the separate binaries are even distributed separately, but in practice everyone just uses hyperkube, because then you have to pull the image only once. It weighs ~237mb. With separate binaries, and therefore separate images you would have to download much more.
<sur> (the hyperkube binary itself weighs 178MB) for k8s 1.4
<waly> sur: sure, it was only about beeing "complete". I for example only run the kubelet in rkt and the other components with docker (just because I use the kubelet-wrapper). Which means, I end up with 2 big images on the master nodes and 1 big on the minions. I'd prefer 1 big on master and 2 small on the minions
<waly> That's why I'm currently doing some "best practice research"
<sur> Deploying k8s is still a fresh story, and out of scope for this channel. Have a look at bootkube, btw https://github.com/kubernetes-incubator/bootkube. It launches a mini in-process single-node seed cluster, and then launches a kubelet master, which hosts all other k8s components as pods (!!) :-)
<waly> Sure, just wanted to tell you the background - thanks for the helpful input!
<sur> sure thing, happy to help, enjoy rkt o/ :-)
<waly> I already do! :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment