Customized development of kubernetes process


Three step installation of kubernetes cluster


This paper introduces how to develop kubernetes, how to manage warehouse, how to manage git branch, how to use Ci to compile and publish and how to contribute code to the community, etc. combined with practical examples, I hope to help you.


Construction of development environment

Customized development of kubernetes process


Put project fork into its own warehouse

Clone to local

git clone<your-username>/kubernetes 

Set remote

git remote add upstream
git remote set-url --push upstream no-pushing

Note that there are two remote warehouses in your local warehouse, one is called upstream and the other is called origin

Code synchronization

When the community warehouse code is updated, we want to synchronize with it

Git pull upstream master synchronizes to local first
Git push to origin

If you change the code and want to synchronize it with the community, then PR can

Branch Management

Customized development of kubernetes process

Suppose we want to customize a function, such as the lxcfs enhancement of kubelet that I did before, and we have run multiple versions of k8s online, we hope that several versions of this feature can be added, and the function can also be merged when the new version of k8s is released in the future.

Two commands in Git are very important:

  • Git cherry pick can specify merge specific changes
  • Git rebase is usually used by me to merge multiple commit. Although cherry pick also supports multiple commit, it is easy to get confused

First, cut a branch from the master branch head. We have developed some functions on this branch. For example, I have done C1 C2 twice commit.

Then we want to merge this function into version 2.0. We first cut a branch from the 2.0 tag, and then we can divide it into cherry pick C1 C2, which is very simple and convenient. Other versions need this function in the same way.

Note here that if you don’t use cherry pick to merge directly, because there are many changes after version 2.0, there will be a lot of conflicts.

Ci compilation and release

I prefer drone, so both compilation and release use drone. Amway drone free public service is very easy to use

Customized development of kubernetes process

Because different versions of k8s may need different versions of golang, the most convenient way is to build in a container, but not any image of golang. Because k8s also needs to copy code, and code generation relies on some small tools. Here I provide an official compilation image: fanux / Kube build: v1.12.1-2

At the time of release, a very convenient plug-in of drone is used: plugins / GitHub release. Binary files can be directly put into the release pages of GitHub

. drone.yml looks like this:

kind: pipeline
name: default
    base: /go
    Path: Src / Note that the working directory must write this

-Name: build compile, name at will
  image: fanux/kube-build:v1.12.1-2  
    Go111module: on? Start go Mod
      -Make generated? Files update? API? Known? Videos = true? This is a known API verification, and error may be reported if no compilation is performed
      -Kube ﹣ git ﹣ tree ﹣ state = "clean" Kube ﹣ git ﹣ version = v1.14.0 Kube ﹣ build ﹣ platforms = Linux / AMD64 make all what = CMD / kubelet goflags = - V ﹣ several environment variables are particularly important. If you do not add clean to compile the version number, you will add the "dirty" suffix. You need to add the version number or many times it will not work properly. Build the platform. In this way, you do not need to compile multiple bin files to speed up compilation. W Hat specifies what code needs to be compiled. In most cases, no components need to be compiled
      -Ls ﹐ output / bin / ﹐ you can see the compiled binary here

- name: publish
  image: plugins/github-release
        from_secret: git-release-token
    Files: "output / bin / kubelet" put the previous binary file in the release page
    Title: ${dragon ﹣ tag} use the tag you typed as the title
    Note: specifies a file to describe what you did in the release
        event: tag

After you submit the code, you can brush and shake your voice.

Practice case

The default certificate time of k8s kubeadm is one year. I hope it can be extended to 99 years. In this way, customized development is needed. Then the problem arises. Because there are many versions, it is too troublesome to change every version. The correct way is as follows:

Cut a branch from the master

git checkout -b kubeadm

Modify the code and commit

commit 6d16c60ca5ce8858feeabca7a3a18d59e642ac3f (HEAD -> kubeadm)
Author: fanux <[email protected]>
Date:   Mon Mar 18 20:26:08 2019 +0800

    kubeadm with long cert

commit 364b18cb9ef1e8da2cf09f33d0fd8042de6b327e (upstream/master, origin/master, origin/HEAD, master)

As you can see, we have committed once. Now we just need to merge the change of 6d16c60ca to each version

Merge to 1.13.4

git checkout -b v1.13.4 v1.13.4
git cherry-pick 6d16c60ca5c

Note that if the lines of the same file are modified in this commit, there may be conflicts. You need to resolve the conflicts manually

Resolve the conflict commit

➜  kubernetes git:(v1.13.4) ✗ git add .
➜  kubernetes git:(v1.13.4) ✗ git commit -m "v1.13.4-cert"
[v1.13.4 1bd2e627f5] v1.13.4-cert
 Date: Mon Mar 18 20:26:08 2019 +0800
 4 files changed, 42 insertions(+), 3 deletions(-)
 create mode 100644 .drone.yml
 create mode 100644
➜  kubernetes git:(v1.13.4) git tag v1.13.4-cert
➜  kubernetes git:(v1.13.4) git push --tags

Other precautions

If you want PR to the community, you need CLA certification, or your PR community doesn’t care.

Some files added by CI, such as. Drone.yml dockerfile, should be separated from the actual function, so that only the code needed by PR is convenient.

Other components and the apiserver scheduler can be CI directly into the docker image. The drone is very flexible. Do not use it dead

Scan and follow sealyun
Customized development of kubernetes process
Discussion on additive QQ group: 98488045