Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to build the kubernetes development environment". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's ideas to study and learn how to build the kubernetes development environment.

Build Fork in the development environment

Fork the github.com/kubernetes/kubernetes project to your own warehouse

Clone to local git clone https://github.com//kubernetes to set remotegit remote add upstream https://github.com/kubernetes/kubernetes.gitgit remote set-url-- push upstream no-pushing

Notice that your local warehouse has two remote repositories, one called upstream (Community Warehouse) and one called origin (your fork).

Code synchronization

When the community repository code is updated and we want to synchronize with it, then:

Git pull upstream master # first synchronize to local git push # push to origin

If you modify the code and want to synchronize it to the community, then PR is fine.

Branch management

Suppose we want to customize a feature, such as lxcfs enhancements to 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 we can also merge this feature when new versions are released in the future.

It is important to achieve the two commands in this git:

Git cherry-pick can specify merge-specific changes

Git rebase is usually used to merge multiple commit. Although cherry-pick also supports multiple commit, it is easy to get confused if there is too much.

First of all, a branch is cut out from the master branch HEAD, and all the functions we have are developed on this branch, for example, I have done C1 / c2 commit twice.

Then we hope to merge this function to version 2.0, we first cut a branch from the tag of 2.0, and then cherry-pick C1 / c2 on this branch, which is very simple and convenient, and 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 a lot of changes after version 2.0, there will be a lot of conflicts.

CI compilation and release

I prefer drone, so I use drone to compile and publish. Amway's drone free public service is very easy to use.

Since each version of k8s may require a different version of golang, the most convenient thing is to build in the container, but not any golang image can be built, because K8s also needs to copy code, generate code and so on depends on some gadgets. I provide an official compiled image here: fanux/kube-build:v1.12.1-2 is released with a very convenient plug-in for drone: plugins/github-release, which can put binaries directly into the release pages of github.

.drone.yml looks like this:

Kind: pipelinename: defaultworkspace: base: / go path: src/k8s.io/kubernetes # pay attention to the working directory must write this steps:- name: build # compile, name casually image: fanux/kube-build:v1.12.1-2 environment: GO111MODULE: on # start go mod commands:-make generated_files UPDATE_API_KNOWN_VIOLATIONS=true # this is a known api check Error may be reported without adding compilation-several environment variables of KUBE_GIT_TREE_STATE= "clean" KUBE_GIT_VERSION=v1.14.0 KUBE_BUILD_PLATFORMS=linux/amd64 make all WHAT=cmd/kubelet GOFLAGS=-v # are particularly important. If you compile without clean, the version number will be suffixed with dirty, and you need to add the version number, otherwise it will not work properly and build the platform, so that there is no need to compile multiple bin files to speed up the compilation. Specify what code needs to be compiled in WHAT In most cases, there is no need to compile components-ls _ output/bin/ # you can see the compiled binaries here-name: publish image: plugins/github-release settings: api_key: from_secret: git-release-token files: _ output/bin/kubelet # put the previous binaries into release page title: ${DRONE_TAG} # use you Type tag as the title note: Note.md # specify a file describing what you did in release when: event: tag

In this way, you can browse the results such as Douyin after submitting the code.

Practical case

The default certificate for K8s kubeadm is one year, and I hope to extend it to 1999, so customized development is required. Then the question arises: because there are so many versions, do you need to change each version? that's too troublesome. The correct approach is as follows:

Cut a branch git checkout-b kubeadm from master

Modify the code and commit

Commit 6d16c60ca5ce8858feeabca7a3a18d59e642ac3f (HEAD-> kubeadm) Author: fanux Date: Mon Mar 18 20:26:08 2019 + 0800 kubeadm with long certcommit 364b18cb9ef1e8da2cf09f33d0fd8042de6b327e (upstream/master, origin/master, origin/HEAD, master)

You can see that we have commit once, and now we only need to merge the change of 6d16c60ca to each version.

Git checkout-b v1.13.4 v1.13.4git cherry-pick 6d16c60ca5c in merge to 1.13.4 version

Note that this time commit may conflict if you modify the lines of the same file. You need to resolve the conflict manually.

After resolving the conflict, commit can.

➜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 Note.md ➜kubernetes git: (v1.13.4) git tag v1.13.4-cert➜ kubernetes git: (v1.13.4) git push-- other considerations for tags

If you want to give PR to the community, you need to be CLA certified, otherwise your PR community will not care.

Some files added by CI, such as .drone.yml dockerfile, etc., are best separated from the addition of actual functions, so that it is convenient for PR to only PR the code that is actually needed.

Other components and apiserver scheduler can be directly made into docker images by CI. Drone is very flexible, so don't use it dead.

Thank you for your reading, the above is the content of "how to build the kubernetes development environment". After the study of this article, I believe you have a deeper understanding of how to build the kubernetes development environment, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.