In this post, I will go into what we implemented so far from an architectural design perspective, how Kubernetes actually works from the inside and what will do going forward.
What we have done so far?
So Until this point, we implemented a basic creation of pods, nodes, services, and inner and outer networks of the nodes.
The flow is as followed:
So the client with the own-kubernetes CLI creates a node, and the node is created with Docker. Then the client sends an HTTP request to the IP and port of the node to create a pod and with that all of its networking.
How Kubernetes works from the inside?
So in Kubernetes, the design is that the master node (in our case our environment) has an etcd DB which is a key-value DB that is the source of truth of the cluster, and every interaction with the etcd is with the Kubernetes API.
The following flow is taken from the book Kubernetes in Action by Marko Luksa, highly recommended for anyone that wants to learn everything about Kubernetes and its inside:
So the way Kubernetes works is as the chart above, let's say we want to create a single Pod:
the kubectl makes a request to the Kubernetes API (usually some kubectl apply)
- the API server saves the new pod spec in etcd
- the scheduler gets a notification for a new Pod addition to the etcd without node assign and assigns a new node (with some decision conditions I will not get into)
- the kubelet inside the node it was assigned to is getting a notification and creating the new pod.
There is also a another component that called controller manager, used to get the actual state of a resource to the desired state, usely update and delete resource and get also notification for every etcd change.
What we will do next?
So Kubernetes design is parted into components that avoid coupling, whereas our design is highly coupled and moving forward will probably be a monolith.
Our design will stay that way, we store the created resources in the etcd, but we will not work as decoupled components that are getting notifications, because I want this series to focus on getting a POC of minimal functionality of a working Kubernetes.
It was important to me to make this article before we move forward for you to realize the design we are doing is not a match to the Kubernetes design (but can be with extra work).
Top comments (3)
This is amazing work!
Do you plan on continuing this?
Thank you for the comment and the compliment!
I am currently working on rebuilding everything to be less coupled and more like real Kubernetes components (kube-api, etcd, kube-proxy decoupled into pods)
I will finish soon and post a new series that is more accurate to the existing Kubernetes design.
That's awesome.
That would be extremely helpful!