tjdett · October 26, 2016 23:06
diff --git a/convo.txt b/convo.txt
 <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! :)
	<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! :)