Kubernetes Source Code Analysis

Recently, I have been assigned to implement a task manage system based on etcd storage backend. Some of its design and implmentation are inspired by Kubernetes.

As a Go developer, dealing with Kubernetes may be an everyday routine, and you may konw a few of it, such as the basic concepts , architecure overview , api convension and processing flow. But when you dig into its source code, you will find some of its designs may be interesting, and it provides a lot insights for Go development, especially for NoSQL-based system as well as micro-service development.

This post focuses on design and implementation of kubernetes, and corresponding source codes may be linked.

Table of Contents

• Overview
  • Project Structure
  • Design Pattern
  • The Functional Option
  • Coding Tools
• API Server
  • The runtime.Object
  • The API Installer
  • The Subresource
  • The registry Machanism
  • The useful client
• Controller Manager
  • Dealing with Object Relationship
• References

Overview

At the first glance of the overall kubernetes project layout, it shares some common points with Standard Go Project Layout, which helps improving scalability of the project code, keeping the code less messy even getting hundred of developers involved. git clone and go mod vendor is a good starting point to let you navigate source code of kubernetes.

The followings are some coding styles/conventions appered a lot among the projects. To some extent, they are good parctices.

Project Structure

Apart from kubernetes/kubernetes, there is more than 60 pinned repositories wihin https://github.com/kubernetes, and each of them is playing an important role to make kubernete to be an integrated one. They locates in venodor dirctory after running go mod vendor.

To be more detailed, repository kubernetes/apiserver is the source code for apiserver, locating in the path of vendor/k8s.io/apiserver, as kubernetes/kubernetes has imported the related packages of it (check go.mod ). So does the other repositories like kubernetes/apimachinery and kubernetes/client-go.

We can see that by letting kubernetes/kubenetes as the root repository, and the rest of pinned repositories as the imported ones, makes the relationship between package more clear. Also notice that the imported repositories share the same directory layer, as you can see in vendor/k8s.io/xxxx.

Also, each repository has well-designed features that make it reasonable to be a single repostory. This helps each of them strictly follows the importing direction. For instance, kubernetes/apiserver has imported kubernetes/client-go, and both of them have imported kubernetes/apimachinery. A clear project structure helps avoiding cycle impor