本文档提供了参与Kubernetes项目的全面指南，包括如何通过贡献代码、参与社区会议和利用各种资源来帮助改进Kubernetes。此外，还介绍了如何进行单元测试、集成测试和端到端测试等关键流程。
整理参与Kubernetes的相关内容：
相关链接
slack channel: http://slack.k8s.io/
google group: https://groups.google.com/forum/#!forum/kubernetes-dev
weekly community meeting: https://groups.google.com/forum/#!forum/kubernetes-community-video-chat
官方的Meetup:
https://www.meetup.com/topics/kubernetes/
https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/
Kubernetes API: https://kubernetes.io/docs/reference/
kuberntes.io －－教程
kubeweekly －－－案例分享
design-proposal 设计方案说明（https://github.com/kubernetes/community/blob/master/contributors/design-proposals/），同样可以用来学习插件的开发．
kubernets项目更好的参与 https://github.com/kubernetes/community/tree/master/contributors/devel
list of SIGs(罗列了主要的SIG以及Meetings时间)
https://github.com/kubernetes/community/blob/master/sig-list.md
SIGs
Kubernetes Developer Guide
https://github.com/kubernetes/community/blob/master/contributors/devel/README.md
https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md
有几篇强相关的文档可以read一下,包含的内容
开发以及贡献代码到Kuberentes project的流程
- pr的信息以及代码reviw
- github上提交Issues
- pr处理过程
- 怎么加速Pr的review
- ci最新编译的ｉ去那个看
- 自动化的工具
建立你的开发环境，coding以及debugging
- 建立开发环境
测试（unit, integration and e2e test）
unit测试 运行unit测试，下面是一些常用的例子 cd kubernetes make test #Run all unit tests make test WHAT=./pkg/api #Run tests for pkg/api make test WHAT=”./pkg/api ./pkg/kubelet” # run tests for pkg/api and pkg/kubelet 指定需要运行的test方法 # Runs TestValidatePod in pkg/api/validation with the verbose flag set make test WHAT=./pkg/api/validation GOFLAGS="-v" KUBE_TEST_ARGS='-run ^TestValidatePod$' # Runs tests that match the regex ValidatePod|ValidateConfigMap in pkg/api/validation make test WHAT=./pkg/api/validation GOFLAGS="-v" KUBE_TEST_ARGS="-run ValidatePod|ValidateConfigMap$" 压力测试 make test PARALLEL=2 ITERATION=5 生成覆盖率 make test PARALLEL=2 ITERATION=5 make test WHAT=./pkg/kubectl KUBE_COVER=y ＃only one package-k8s-images Benchmark unit tests go test ./pkg/apiserver -benchmem -run=XXX -bench=BenchmarkWatch 集成测试Integration tests End-to-End tests https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.mdflake free tests
- glog日志打印级别
glog.Errorf()
glog.Warningf()
glog.Infof info级别的日志又分成五个级别，范围依次变高
glog.V(0) ＜glog.V(1)＜glog.V(２)＜glog.V(３) ＜glog.V(４)
可以通过－ｖ＝X来设置X is the descired maximum level to log. - profiling kubernetes
- add a new metrics to kubernetes code.
- 代码规范
- 文档规范
- 运行a fast and lightweight local cluster deployment for development
Kuberntes API的开发
- REST API文档
- Annotations：用于将任意的非识别元数据附加到对象。 自动化Kubernetes对象的程序可能会使用注释来存储少量的状态。
- API conventions(约定)
插件开发
- Authentication 认证插件
- Authorization Plugins 授权插件
- Admission Control Plugins 准入插件
发布流程
具体流程
- Fork kubernetes to your own in the github
- Clone fork to local storage
place Kubernetes' code on your GOPATH using the following cloning procedure. working_dir=$GOPATH/src/k8s.io
mkdir -p $working_dir
cd $working_dir
git clone https://github.com/$user/kubernetes.git
# or: git clone git@github.com:$user/kubernetes.git
cd $working_dir/kubernetes
git remote add upstream https://github.com/kubernetes/kubernetes.git
# or: git remote add upstream git@github.com:kubernetes/kubernetes.git
# Never push to upstream master
git remote set-url --push upstream no_push
# Confirm that your remotes make sense:
git remote -v
3 Branch
Get your local master up to date:
cd $working_dir/kubernetes
git fetch upstream
git checkout master
git rebase upstream/master
Branch from it:
git checkout -b myfeature
Then edit code on the myfeature branch. - Build
cd $working_dir/kubernetes
make
To remove the limit on the number of errors the Go compiler reports (default limit is 10 errors):
make GOGCFLAGS="-e"
To build with optimizations disabled (enables use of source debug tools):
make GOGCFLAGS="-N -l"
To build binaries for all platforms:
make cross
- Install etcd
hack/install-etcd.sh - Test
cd $working_dir/kubernetes
# Run all the presubmission verification. Then, run a specific update script (hack/update-*.sh)
# for each failed verification. For example:
# hack/update-gofmt.sh (to make sure all files are correctly formatted, usually needed when you add new files)
# hack/update-bazel.sh (to update bazel build related files, usually needed when you add or remove imports)
make verify
\# Alternatively, run all update scripts to avoid fixing verification failures one by one.
make update
Run every unit test
make test
# Run package tests verbosely
make test WHAT=./pkg/api/helper GOFLAGS=-v
# Run integration tests, requires etcd
# For more info, visit https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md#integration-tests
make test-integration
# Run e2e tests by building test binaries, turn up a test cluster, run all tests, and tear the cluster down
# Equivalent to: go run hack/e2e.go -- -v --build --up --test --down
# Note: running all e2e tests takes a LONG time! To run specific e2e tests, visit:
# https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md#building-kubernetes-and-running-the-tests
make test-e2e
See the testing guide and end-to-end tests for additional information and scenarios.
Run make help for additional information on these make targets.- Keep your branch in sync
# While on your myfeature branch
git fetch upstream
git rebase upstream/master- Commit
Commit your changes.
git commit
Likely you go back and edit/build/test some more then commit –amend in a few cycles. Push
When ready to review (or just to establish an offsite backup or your work), push your branch to your fork on github.com:
git push -f ${your_remote_name} myfeatureCreate a pull request
- Visit your fork at https://github.com/$user/kubernetes
- Click the Compare & Pull Request button next to your myfeature branch.
- Check out the pull request process for more details.
If you have upstream write access, please refrain from using the GitHub UI for creating PRs, because GitHub will create the PR branch inside the main repository rather than inside your fork.
Get a code review
Once your pull request has been opened it will be assigned to one or more reviewers. Those reviewers will do a thorough code review, looking for correctness, bugs, opportunities for improvement, documentation and comments, and style.
Commit changes made in response to review comments to the same branch on your fork.
Very small PRs are easy to review. Very large PRs are very difficult to review. At the assigned reviewer’s discretion, a PR may be switched to use Reviewable instead. Once a PR is switched to Reviewable, please ONLY send or reply to comments through Reviewable. Mixing code review tools can be very confusing.
See Faster Reviews for some thoughts on how to streamline the review process.- Squash and Merge
Upon merge (by either you or your reviewer), all commits left on the review branch should represent meaningful milestones or units of work. Use commits to add clarity to the development and review process.
Before merging a PR, squash any fix review feedback, typo, and rebased sorts of commits.
It is not imperative that every commit in a PR compile and pass tests independently, but it is worth striving for.
For mass automated fixups (e.g. automated doc formatting), use one or more commits for the changes to tooling and a final commit to apply the fixup en masse. This makes reviews easier.
扫一扫
448
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
