I was fond of container orchestration, and in particular of course Kubernetes. I wanted to go into the Kubernetes open source, When I saw the code base I was initially overwhelmed.
I decided with my love for Golang I want to build it on my own to understand how It works better and maybe get into its code base more easily.
These multiple articles will go through my journey on how to build Kubernetes on my own with Golang.
Disclaimer: This project will be a minimal but working implementation, not close to the official Kubernetes implementation and maybe a lot different, but trying to follow its requirements of container orchestration, and all of it will be locally on VMs and not distributed over multiple servers.
Each article will cover some topics and source code on the implementation.
Before we begin I welcome of course throughout my articles to suggest fixes in the comments (including typos because English isn't my native language 😉).
What do you need to know before starting this series?
- basic Go syntax
- basic docker concepts
- basic understanding in Linux
How Kubernetes works
This article will focus on how Kubernetes works on the inside, if you are already familiar with the inside of Kubernetes you can go to the next article.
source for this section
First, let's define a container orchestration system - a way to manage the lifecycle of containerized applications, like the ability to automate deployment and scale easily. These containers act as replicas and serve to load balance incoming requests. A container orchestrator supervises these groups of containers and ensures that everything works correctly.
We will break down each Kubernetes concept we should know
The smallest unit that Kubernetes administers, can contain one or more containers. Pods have a single IP address that is assigned to every container within the pod.
Define the way at which you want to run your application by letting you set the details of your pods, like replicas, update strategy, etc. It will describe to Kubernetes your application's desired state.
Abstraction over the pods, the interface the various application consumers interact with because pod states are always changing and cant be relied on.
Manages and runs pods, it's a machine (virtual or physical) that performs the given work.
The main entry point of the administrators and users to manage the various nodes.
All the above components put together as a single unit.
Exposes a REST interface to the Kubernetes cluster. All operations on pods, services, etc. are executed with the API endpoints provided by it.
Responsible for assigning work to various nodes, keeping watch over the resource capacity, and ensuring that a worker node's performance is within an appropriate threshold.
Making sure that the state of the cluster components works as expected, oversees various controllers which respond to events, like when a node goes down.
Tracks the state of a pod to ensure that all the containers are running. It provides a heartbeat message every few seconds to the control plane.
Routes the traffic coming into a node from the service into the correct containers.
Distributed key-value store that Kubernetes uses to share information about the overall state of a cluster.
Complete architecture of kubernetes
In the next chapter we will get into the code, will cover pod creation and running with containerd.
Top comments (0)