Kubernetes Project Exploration, Part 1 - A brief overview of Kubernetes project stack

3 minute read


Kubernetes, an open-sourced container orchestration platform praised as the future of cloud infrastructure, gains more and more attention nowadays. It extends resource management from a single machine to a cluster of machines, and thus can be seen as the operating system of cloud.

This article series will briefly introduce K8s project stack and mechanism of important components.

Kubernetes project stack

Before deep diving into core logic of Kubernetes, let’s have quick overview of what k8s project stack consists of.

K8S is one of the best open source projects in terms of project organization and support. It sets an outstanding example of how a totally open-sourced project should be grouped, organized and hosted over Internet.

K8s project is located at here.


This is the core project of K8S stack. Will discuss later on.


Each engineer engaged in an open-sourced project once felt the pain of reading obscure code alone without any help.

Developers are usually from different places of the world and it is hard for them to sit together in reality and discuss like team/friends. This is the most challenging part for open-source projects.

For an open source project to succeed, not only code, but people need to be organized as well. That’s why k8s provide tremendous support for community.

Special Interest Groups (SIGs)

SIG is a persistent open groups that focus on a part of the project. Example SIGs are sig-node, sig-scheduling, etc.

Each SIG corresponds to a folder in community project, thus you can easily find all the docs/events/etc you want of a SIG.

Working Groups(WG)

WGs mainly focus on addressing issues across SIGs.


Instant Messaging

Slack is popular among k8s communities nowadays. Just pick a SIG you are interested in and join that channel.


KubeCon, powered by CNCF, holds regular meetings each year where people share thoughts and innovation about Kubernetes.


When developing a brand new feature for a project, it’s usually not very stable and not totally ready for GA yet. Thus we need a “staging” space to put new features temporarily.

After the feature is stable enough, we move the feature to the main repo. Kubernete’s enhancements repo serves as this purpose. It functions much like OpenCV’s opencv_contrib repo.


Everybody once submitted a PR to K8S project knows how powerful(even verbose :wink:) the code submission process is. This project contains all tools/scripts to make K8S projects’ CI/CD pipeline as complete and reliable as possible. Each PR triggers several checks/tests and you can interact with k8s-bot on github directly.


Would like to try K8S but no machines at hand? Minikube is your best friend. Minikube is most suitable for a newbie to try out k8s. It can also serve as a playground to test configuration, deployment, etc.


Like any mature projects, k8s provides a dashboard to visualize/operate its internal state as well. It is an convenient out-of-the-box solution, but not very flexible and customizable.

On many k8s-based platforms it is replaced with third-party choices. I personally use Grafana for metrics visualization and Vscode k8s extension for cluster operation/inspection.


The k8s homepage https://kubernetes.io/ is open-sourced as well, try submitting a PR for typos when you catch one:sunglasses:.

Kubernetes core project

The kubernetes/kubernetes project contains core functionalities of k8s.

Its file structure is as follows:


This folder contains all the build scripts. The main script for building components binaries is build/run.sh. The build process runs in a Docker container to provide consistent build environment.


This folder contains source code of all the executables(kubectl, kubelet, etc). It uses cobra.Command library to handle logic of creating command-line binary and setup options and configs.


This folder is where most k8s core logic live. Each components corresponds to a sub-folder. Start here if you would like to deep-dive into one specific k8s component.


As Kubernetes project becomes larger and larger, different components are no more suitable to live in a single project. However, scattering source code everywhere will make it painful to lookup.

K8S project resolves this problem by introducing staging folder. The source code of different components are still checked into kubernetes/kubernetes project at staging folder, but they are later on published to external k8s.io repositories(e.g. k8s.io/kube-scheduler) and referenced by other projects through k8s.io repo.