Three-step installation of kubernetes cluster

Summary

This paper introduces how to redevelop kubernetes, how to manage warehouses, how to manage git branches, how to compile and distribute code by CI, and how to contribute code to the community. With practical examples, it is hoped to be helpful to everyone.

<!--more-->

Construction of Development Environment

Fork

fork the github.com/kubernetes/kubernetes project to your warehouse

Clone to Local

git clone https://github.com/<your-username>/kubernetes 

Setting remote

git remote add upstream https://github.com/kubernetes/kubernetes.git
git remote set-url --push upstream no-pushing

Note that your local warehouse has two remote warehouses, one is upstream and the other is origin.

Code synchronization

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

git pull upstream master  # Synchronize locally first
git push                  # push to origin

If you modify the code to synchronize it with the community, then PR will do.

Branch management

Suppose we want to customize a feature, such as lxcfs enhancement of kubelet, which I did before, and we have several versions of k8s running online. We hope that several versions of this feature can be added, and merge will also be able to add this feature when new versions of k8s are released in the future.

It's important to do the two commands in this git:

• git cherry-pick specifies merge-specific changes
• git rebase is usually used to merge multiple commits. Although cherry-pick s also support multiple commits, more commits tend to be confusing.

First, we cut out a branch from the master branch HEAD. We have some functions to develop on this branch. For example, I made c1 c2 commit twice.

Then we want to merge this function into version 2.0. We first cut a branch from tag 2.0, and then add cherry-pick c1 c2 to it. It's very simple and convenient. Other versions need the same function.

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 Compiling and Publishing

I prefer drone, so compiler and publisher use drone, Amway drone free public service Very useful

Because different versions of k8s may require different golang versions, it is most convenient to build them in containers, but not just a golang image can be built, because k8s also needs to copy code, generate code and other small tools, I provide an official compiler mirror here. Like: fanux/kube-build:v1.12.1-2

drone is a very convenient plug-in for publishing: plugins/github-release, which can directly put binary files into github's release pages.

Drne.yml looks like this:

kind: pipeline
name: default
workspace:
    base: /go
    path: src/k8s.io/kubernetes  # Note that the working directory must write this

steps:
- name: build                    # Compile and write your 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 validation. Without compilation, errors may be reported.
      - 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 the version number is compiled without clean, it will be suffixed with dirty. If the version number is not added, it will not work properly in many cases. Build a platform. This will not need to compile many bin files to speed up the compilation. WHAT specifies what code needs to be compiled, and in most cases, it does not need to compile some components.
      - ls  _output/bin/  # Here you can see the compiled binary file

- name: publish
  image: plugins/github-release
  settings:
    api_key: 
        from_secret: git-release-token
    files: _output/bin/kubelet   # Put the last binary file in release page
    title: ${DRONE_TAG}          # Use the tag you typed as the title
    note: Note.md                # Specify a file to explain what you did in release
    when:
        event: tag

This way, after submitting the code, we can brush the results such as tremble and so on. _________.

Practical cases

The default certificate of k8s kubeadm is one year. I hope it will be extended to 99 years. This will require customized development. 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 master

git checkout -b kubeadm

Modify the code and commit

commit 6d16c60ca5ce8858feeabca7a3a18d59e642ac3f (HEAD -> kubeadm)
Author: fanux <fhtjob@hotmail.com>
Date:   Mon Mar 18 20:26:08 2019 +0800

    kubeadm with long cert

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

You can see that we commit once, and now we just need to merge the change of 6d16c60ca to all versions.

merge to Version 1.13.4

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

Note that commit may still conflict if it modifies the rows of the same file, and you need to resolve the conflict manually.

Conflict resolution commit is enough

➜  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 --tags

Other considerations

If PR is needed for the community CLA certification Well, otherwise your PR community doesn't care.

Some of the files added by CI, such as. drone.yml dockerfile, are best separated from the actual functions, so that only the code needed by PR can be conveniently added.

Other components and apiserver scheduler can be CI directly into docker image, drone is very flexible, do not use dead

Scanning Focus on sealyun

Exploring additive QQ groups: 98488045