
Kubernetes from the ground up: the API server - luu
http://kamalmarhubi.com/blog/2015/09/06/kubernetes-from-the-ground-up-the-api-server/
======
jvns
> When a kubelet starts up, it registers itself as a node with the API server
> and starts watching for pods to run. This is really great, because it means
> that when we get to running a multinode cluster, we can add nodes without
> having to reconfigure the API server

I really like the parts of this series that emphasize Kubernetes' design
decisions -- it also says that all state is stored in etcd and that the API
server is the only component that has access to etcd.

------
AndrewHampton
I'm really enjoying this series. We started using kubernetes at work a few
weeks ago and detailed documentation like this is pretty hard to find.

Kamal, what resources are you using to learn the information in these posts?

~~~
kalmar
My main resource is probably time. I read all the documentation when
Kubernetes was first announced, and reread it when they were coming up to 1.0.
I've also been following the proposals and issues a little. I've also got a
clone of the codebase and read bits to make sure I'm understanding what goes
on.

But yeah, it's a really fast moving project with a lot of moving parts, and
I'm still not on top of everything!

~~~
AndrewHampton
Thanks for the info! I've found the end user documentation to be excellent,
but the documentation for actually managing a cluster to be lack luster. This
series has been perfect for filling in that gap. Thanks again!

~~~
TheIronYuppie
Disclaimer: I work at Google on Kubernetes

I'd love if you could mention stuff in particular that you felt like was
missing - we're trying hard to catch up!

~~~
mkulke
Specifically some canonical instructions on how to harden a cluster would be
helpful. Many Starting Guides have nodes use plain http to talk to the api
server, thus even deployed containers can do this do.

It took me a while to find a proper kubeconfig example for kubelet and kube-
proxy token auth (the one I eventually found was buried in some github issue i
think).

Also, I found no information on how on what to put in the authorization jsonl
file for kubelet (the given example is wrong, since the kubelet needs to
write/report node status to the api) and kube-proxy. Peeking into the code
helped, but I guess this information could be helpful for admins.

------
aprdm
Thanks for the writing up, really nice series so far! I would like to know
what are the competitors of Kubernetes to run docker in production and if you
think Kubernetes is suitable for small / single man projects? Or what would
you advice instead?

Cheers

~~~
krenoten
Kubernetes is very much still under development. Most of the work up to 1.0
has gone into refinement of the API, rather than stability. For instance, HA
is only now being seriously worked on - and if your API server goes down and
you need to start it on another host, if you don't have an external
reconvergence mechanism you have to restart every kubelet so they can point to
the new one.

Mesos is much more mature, but is more low-level, and schedulers like Aurora
or Marathon do not give you the same service abstraction, but they have many
features not currently present in Kubernetes. But, in return for being more
low-level, you can run things that are simply impossible in a declarative
system like Kubernetes. Personally I see Kubernetes-on-Mesos as being a really
bright future choice, but like pretty much anything other than Marathon/Aurora
on Mesos, it's pretty nascent.

~~~
kalmar
> But, in return for being more low-level, you can run things that are simply
> impossible in a declarative system like Kubernetes.

Can you give an example? I know next to nothing about Mesos, Aurora, or
Marathon.

~~~
krenoten
It's like many things that are declarative - you can only do what has been
explicitly enabled in the declaration handling logic. This is good and bad.
It's good because it restricts what is possible (protecting you slightly more
from bad users) and can make learning and using the system easier. But you
can't go beyond this. With a non-declarative scheduler you can implement far
more interesting (for better or worse) management systems.

One area where we've been seeing some interesting work happening is in
stateful services running on top of schedulers. With something like postgres,
there is interesting logic that must happen for responsible management beyond
just throwing up 3 of them. You need to manage replication carefully. When a
node goes down somewhere, you need to react somewhere else in a controlled
way. With Mesos, you can write a scheduler that encodes your runbook. With
kubernetes, you need a lot more out-of-band stuff.

~~~
TheIronYuppie
Disclaimer: I work at Google on Kubernetes.

You're correct that the scheduler in the box is declarative. However, it is
easy (well, as easy as writing a framework) to swap out a scheduler that might
be a better fit for what you're looking for.

See this stackoverflow answer by one of the core Kubernetes team for more
info: [http://stackoverflow.com/questions/28857993/how-does-
kuberne...](http://stackoverflow.com/questions/28857993/how-does-kubernetes-
scheduler-work)

------
gtaylor
Really enjoying this series. Thanks, Kamal!

------
josephjacks
Great series, Kamal! Keep up the great work.

