# Kubernetes Archeology (K8s A8y): It is the study of certain events which impacted the kubernetes system **URL:** \ **Category:** General Discussions\ **Created:** [May 24, 2018, 9:32pm UTC](https://discuss.kubernetes.io/t/kubernetes-archeology-k8s-a8y-it-is-the-study-of-certain-events-which-impacted-the-kubernetes-system/518 "2018-05-24T21:32:45Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![suvi29](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/suvi29/32/502_2.png) [@suvi29](https://discuss.kubernetes.io/u/suvi29)\ **Post date:** [May 24, 2018, 9:32pm UTC](https://discuss.kubernetes.io/t/kubernetes-archeology-k8s-a8y-it-is-the-study-of-certain-events-which-impacted-the-kubernetes-system/518/1 "2018-05-24T21:32:45Z")
Hi guys, As We know that, the design, philosophy, architecture etc of the [Kubernetes](http://kubernetes.io/) is inspired or influenced by [Borg and Omega](https://queue.acm.org/detail.cfm?id=2898444) at Google. Over the course of this time and **ongoing** journey, there might have been some **events** where components in kubernetes were suggested, added, altered or even removed in order to progress or build the kubernetes system as it is now. As I understand, these things are **overlooked** while talking about the kubernetes eco-system. I believe, to **comprehensively** understand a fascinating complex system, It is essential to go through the journey with kubernetes by understanding these events. Therefore, I would like to begin this thread with [the First GitHub commit for Kubernetes](https://github.com/kubernetes/kubernetes/commit/2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56) by @joe. We could share certain **significant** events which transformed kubernetes. Thanks ---
**Author:** ![joe](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/joe/32/20_2.png) [@joe](https://discuss.kubernetes.io/u/joe)\ **Post date:** [May 25, 2018, 3:18pm UTC](https://discuss.kubernetes.io/t/kubernetes-archeology-k8s-a8y-it-is-the-study-of-certain-events-which-impacted-the-kubernetes-system/518/2 "2018-05-25T15:18:32Z")
I guess my first question would be what features/design choices do you have in mind? Maybe we can get a good conversation going by focusing on something specific? ---
**Author:** ![suvi29](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/suvi29/32/502_2.png) [@suvi29](https://discuss.kubernetes.io/u/suvi29)\ **Post date:** [May 25, 2018, 5:08pm UTC](https://discuss.kubernetes.io/t/kubernetes-archeology-k8s-a8y-it-is-the-study-of-certain-events-which-impacted-the-kubernetes-system/518/3 "2018-05-25T17:08:51Z")
Hi @joe, > Controller Manager and Scheduler are the components that coordinate through the API Server. These are bundled into separate servers called the Controller Manager and the Scheduler. The choice to break these out was so they couldn’t **cheat**. If the core parts of the system had to talk to the API Server like every other component it would help ensure that we were building an extensible system from the start. The fact that there are just two of these is an accident of history. They could conceivably be combined into one big binary or broken out into a dozen+ separate servers. > [Core Kubernetes: Jazz Improv over Orchestration](https://www.cncf.io/blog/2017/11/07/joe-beda-explains-inner-workings-kubernetes/) Correct me If I understand the message from above paragraph correctly, we decided to do a trade-off by separating scheduler from Controller Manager to achieve **extensibility**. What does **cheat** mean in this context? How could it have been a **bad decision** to keep them as a single binary? and Are there other components which could be separated from Controller Manager? Thanks ---
**Author:** ![joe](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/joe/32/20_2.png) [@joe](https://discuss.kubernetes.io/u/joe)\ **Post date:** [May 25, 2018, 8:01pm UTC](https://discuss.kubernetes.io/t/kubernetes-archeology-k8s-a8y-it-is-the-study-of-certain-events-which-impacted-the-kubernetes-system/518/4 "2018-05-25T20:01:03Z")
Hey! Great question. The idea was to make sure that components in the system used APIs that were treated just like end user APIs. This helps developers be more thoughtful about architecture and the interaction between components. It also makes the system fundamentally more extensible. This really somewhat predates/mirrors the thinking around microservices. You have a bunch of smaller services that communicate over well factored, versioned, and well specified interfaces. The issue with putting these things in the same binary is that it is too easy to use “private” APIs that aren’t exposed over the network. That is easier than doing a network API and it simplifies versioning but it leads to tight coupling and a monolith. So while it is _possible_ to keep things loosely coupled through public APIs and be in the same binary, the temptation to do a quick and dirty fix or implementation would be huge. By running these things as a separate binary we make the path of least resistance for developers on the project to do the “right thing”.