Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what is the kubernetes development process". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Construction of development environment

Fork

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, but it is easy to get confused.

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 different golang versions, 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, generates code and so on depends on some gadgets. I provide an official compilation image: fanux/kube-build:v1.12.1-2.

Drone is released with a very convenient plug-in: plugins/github-release, you 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 the tag you typed 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: fanuxDate: 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, ➜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-certDate: Mon Mar 18 20:26:08 2019 + 08004 files changed, 42 insertions (+) 3 deletions (-) create mode 100644 .drone.ymlcreate mode 100644 Note.md ➜kubernetes git: (v1.13.4) git tag v1.13.4-cert➜ kubernetes git: (v1.13.4) git push-- this is the content of tags "what is the kubernetes development process"? Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.