Kubernetes开发者入门

前言:无意间开了个定阅号,算给自己找了一个写博客的理由和动力吧;怎么也得对得起关注的小伙伴们。其实想了想,还真不知道写点什么;现在的文章很多,除了公司的推广软文,还有一些使用者记录的一些笔记。不过好像没什么人写关于开发者的文章,索性先写一段时间关于Kuberentes开发的文章,包括一些社区的讨论和一些issue的fix过程;希望可以帮到国内的Kuberentes开发者。

社区里最简单的 PR 应该就是typo;typo可以帮助熟悉社区的流程,也是刷数据的利器!刚进Mesos社区那会儿很少fix typo:在产品线上呆时间长了,认为只有P1/S1才有意义。见仁见智吧,至少熟悉流程还是必要的。这里拿typo开始说,看看在k8s提交PR大概需要哪些过程和涉及人员、角色。

第一步:找typo

怎么找typo?这个看你自己的本事了。这里主要想介绍一下Kuberentes社区的几个repo:

kubernetes/kubernetes: Kubernetes的主社区,kube-apiserver, kube-controller-manager, kubelet等的代码都在这里;有时候社区里会说upstream,一般也指这个。但由于这里的代码太多,而且github的权限控制粒度较粗,各个组件正在拆分出去,以独立的repo管理。拆分的原则有相应的讨论及文档,后继再写文章详细介绍

kuberentes/community: 这里记录了kuberentes 各个feature的设计文档,新的proposal也需要以PR的形式在这里提交。例如之前提交的 “Policy based resource sharing”,现在还没有review完。

kubernetes/kubernetes.github.io: 这里是https://kubernetes.io的代码,以Markdown语法编写。

kuberentes下面还有很多其它的repo,比如 ingress, dashboard等。不过 kubernetes/kuberentes 的流程是最用的,但也是最长、最麻烦的。后面的描述都以kuberenetes/kubernetes中的typo为基础描述。

第二步:创建PR

创建PR (pull request) 时并不一定要创建issue,特别是像typo这样的小PR。至于如何创建PR,请参考github 的相关文档。 如果要为某个issue创建PR, 需要在PR的描述里填写 fixes #issue_num。这样 PR 在 merge后issue会“自动”关闭。 PR创建后,k8s机器人会做以下几件事:

  1. 检查创建者的linux function cla;如果没签,就按它的提示做就可以了
  2. 在相应OWNER列表里选取一个人做为reviewer
  3. 如果是kubernetes member,则启动CI来检查PR,例如UT, e2e test;如果不是kuberentes member ,则需要一个member 帮忙启动相应ci

待CI没有问题后,可以ping 相应的reviewers来检查代码了。

第三步:分支合并

一般typo都没有什么comments,只是别再引入typo就行。在reviewer认为可以后,需要标 lgtm (look go to me) 标签;同时需要该模块的approver标记 approve 标签。两个标签都有了以后,就可以等待合并了。 代码的合并也是由k8s机器人完成的,可以在 http://submit-queue.k8s.io/#/queue 看到等待合并的PR。在合并之前,k8s机器人也会自动重新跑ci以保证代码没有问题。

以上三步差不多就可以将typo提交到主干上。其中大部分工作都有k8s机器人自动完成,比如分配reviewer;相关的人员也只是reviewer 和 approver两个。这里有些细节没办法展开讲,比如k8s里的角色。后面的文章再把这些细节慢慢展开吧。

Written on April 4, 2017