本文轉(zhuǎn)載自：談?wù)凨ubernetes開源社區(qū)和未來走向
我們知道 Kubernetes 這個項(xiàng)目是托管在 CNCF 基金會下面的拓售。但是，我在專欄最前面講解容器與 Kubernetes 的發(fā)展歷史的時候就已經(jīng)提到過镶奉，CNCF 跟 Kubernetes 的關(guān)系础淤，并不是傳統(tǒng)意義上的基金會與托管項(xiàng)目的關(guān)系，CNCF 實(shí)際上扮演的哨苛，是 Kubernetes 項(xiàng)目的 Marketing 的角色鸽凶。
這就好比，本來 Kubernetes 項(xiàng)目應(yīng)該是由 Google 公司一家維護(hù)建峭、運(yùn)營和推廣的玻侥。但是為了表示中立，并且吸引更多的貢獻(xiàn)者加入亿蒸，Kubernetes 項(xiàng)目從一開始就選擇了由基金會托管的模式凑兰。而這里的關(guān)鍵在于，這個基金會本身边锁，就是 Kubernetes 背后
的“大佬們”一手創(chuàng)建出來的姑食，然后以中立的方式，對 Kubernetes 項(xiàng)目進(jìn)行運(yùn)營和 Marketing
通過這種方式砚蓬，Kubernetes 項(xiàng)目既避免了因?yàn)?Google 公司在開源社區(qū)里的“不良作風(fēng)”和非中立角色被競爭對手口誅筆伐矢门，又可以站在開源基金會的制高點(diǎn)上團(tuán)結(jié)社區(qū)里所有跟容器相關(guān)的力量。而隨后 CNCF 基金會的迅速發(fā)展和壯大灰蛙，也印證了這個思路其實(shí)是非常正確和有先見之明的祟剔。
不過，在 Kubernetes 和 Prometheus 這兩個 CNCF 的一號和二號項(xiàng)目相繼畢業(yè)之后摩梧，現(xiàn)在 CNCF 社區(qū)的更多職能物延，就是扮演一個傳統(tǒng)的開源基金會的角色，吸納會員仅父，幫助項(xiàng)目孵化和運(yùn)轉(zhuǎn)
只不過叛薯，由于 Kubernetes 項(xiàng)目的巨大成功，CNCF 在云計(jì)算領(lǐng)域已經(jīng)取得了極高的聲譽(yù)和認(rèn)可度笙纤，也填補(bǔ)了以往 Linux 基金會在這一領(lǐng)域的空白航闺。所以說，你可以認(rèn)為現(xiàn)在的 CNCF县貌，就是云計(jì)算領(lǐng)域里的 Apache 匀油，而它的作用跟當(dāng)年大數(shù)據(jù)領(lǐng)域里 Apache 基金會的作用是一樣的。
不過腥椒，需要指出的是阿宅，對于開源項(xiàng)目和開源社區(qū)的運(yùn)作來說候衍，第三方基金會從來就不是一個必要條件。事實(shí)上洒放，這個世界上絕大多數(shù)成功的開源項(xiàng)目和社區(qū)蛉鹿，都來自于一個聰明的想法或者一幫杰出的黑客。在這些項(xiàng)目的發(fā)展過程中往湿，一個獨(dú)立的妖异、第三方基金會的作用，更多是在該項(xiàng)目發(fā)展到一定程度后主動進(jìn)行商業(yè)運(yùn)作的一部分煌茴。開源項(xiàng)目與基金會間的這一層關(guān)系随闺，希望你不要本末倒置了
另外，需要指出的是蔓腐，CNCF 基金會僅僅負(fù)責(zé)成員項(xiàng)目的 Marketing矩乐， 而絕不會、也沒有能力直接影響具體項(xiàng)目的發(fā)展歷程回论。無論是任何一家成員公司或者是 CNCF 的 TOC（Technical Oversight Committee散罕，技術(shù)監(jiān)督委員會），都沒有對 Kubernetes 項(xiàng)目“指手畫腳”的權(quán)利傀蓉，除非這位 TOC 本人就是 Kubernetes 項(xiàng)目里的關(guān)鍵人物欧漱。
所以說，真正能夠影響 Kubernetes 項(xiàng)目發(fā)展的葬燎，當(dāng)然還是 Kubernetes 社區(qū)本身误甚。可能你會好奇谱净，Kubernetes 社區(qū)本身的運(yùn)作方式窑邦，又是怎樣的呢？
通常情況下壕探，一個基金會下面托管的項(xiàng)目冈钦，都需要遵循基金會本身的管理機(jī)制，比如統(tǒng)一的 CI 系統(tǒng)李请、Code Review 流程瞧筛、管理方式等等。
但是导盅，在我們這個社區(qū)的實(shí)際情況较幌，是先有的 Kubernetes，然后才有的 CNCF白翻，并且 CNCF 基金會還是 Kubernetes “一手帶大”的绅络。所以，在項(xiàng)目治理這個事情上嘁字，Kubernetes 項(xiàng)目早就自成體系恩急，并且發(fā)展得非常完善了。而基金會里的其他項(xiàng)目一般各自為陣纪蜒，CNCF 不會對項(xiàng)目本身的治理方法提出過多的要求
而說到 Kubernetes 項(xiàng)目的治理方式衷恭，其實(shí)還是比較貼近 Google 風(fēng)格的，即：重視代碼纯续，重視社區(qū)的民主性随珠。
首先，Kubernetes 項(xiàng)目是一個沒有“Maintainer”的項(xiàng)目猬错。這一點(diǎn)非常有意思窗看，Kubernetes 項(xiàng)目里曾經(jīng)短時間內(nèi)存在過 Maintainer 這個角色，但是很快就被廢棄了倦炒。取而代之的显沈，則是 approver+reviewer 機(jī)制。這里具體的原理逢唤，是在 Kubernetes 的每一個目錄下拉讯，你都可以添加一個 OWNERS 文件，然后在文件里寫入這樣的字段：
approvers:
- caesarxuchao
reviewers:
- lavalamp
labels:
- sig/api-machinery
- area/apiserver
比如鳖藕，上面這個例子里魔慷，approver 的 GitHub ID 就是 caesarxuchao （Xu Chao），reviewer 就是 lavalamp著恩。這就意味著院尔，任何人提交的 Pull Request（PR，代碼修改請求）喉誊，只要修改了這個目錄下的文件邀摆，那么就必須要經(jīng)過 lavalamp 的 Code Review，然后再經(jīng)過 caesarxuchao 的 Approve 才可以被合并裹驰。當(dāng)然隧熙，在這個文件里，caesarxuchao 的權(quán)力是最大的幻林，它可以既做 Code Review贞盯，也做最后的 Approve。但沪饺， lavalamp 是不能進(jìn)行 Approve 的躏敢。
當(dāng)然，無論是 Code Review 通過整葡，還是 Approve件余，這些維護(hù)者只需要在 PR 下面 Comment /lgtm 和 /approve，Kubernetes 項(xiàng)目的機(jī)器人（k8s-ci-robot）就會自動給該 PR 加上 lgtm 和 approve 標(biāo)簽，然后進(jìn)入 Kubernetes 項(xiàng)目 CI 系統(tǒng)的合并隊(duì)列啼器，最后被合并旬渠。此外，如果你要對這個項(xiàng)目加標(biāo)簽端壳，或者把它 Assign 給其他人告丢，也都可以通過 Comment 的方式來進(jìn)行。
可以看到损谦，在上述整個過程中岖免，代碼維護(hù)者不需要對 Kubernetes 項(xiàng)目擁有寫權(quán)限，就可以完成代碼審核照捡、合并等所有流程颅湘。這當(dāng)然得益于 Kubernetes 社區(qū)完善的機(jī)器人機(jī)制，這也是 GitHub 最吸引人的特性之一栗精。
順便說一句闯参，很多人問我，GitHub 比 GitLab 或者其他代碼托管平臺強(qiáng)在哪里术羔？實(shí)際上赢赊， GitHub 龐大的 API 和插件生態(tài)，才是這個產(chǎn)品最具吸引力的地方级历。
當(dāng)然释移，當(dāng)你想要將你的想法以代碼的形式提交給 Kubernetes 項(xiàng)目時，除非你的改動是 bugfix 或者很簡單的改動寥殖，否則玩讳，你直接提交一個 PR 上去，是大概率不會被 Approve 的嚼贡。這里的流程熏纯，一定要按照我下面的講解來進(jìn)行：
- 在 Kubernetes 主庫里創(chuàng)建 Issue，詳細(xì)地描述你希望解決的問題粤策、方案樟澜，以及開發(fā)計(jì)劃。而如果社區(qū)里已經(jīng)有相關(guān)的 Issue 存在叮盘，那你就必須要在這里把它們引用過來秩贰。而如果社區(qū)里已經(jīng)存在相同的 Issue 了，你就需要確認(rèn)一下柔吼，是不是應(yīng)該直接轉(zhuǎn)到原有 issue 上進(jìn)行討論毒费。
- 給 Issue 加上與它相關(guān)的 SIG 的標(biāo)簽。比如愈魏，你可以直接 Comment /sig node觅玻，那么這個 Issue 就會被加上 sig-node 的標(biāo)簽想际，這樣 SIG-Node 的成員就會特別留意這個 Issue。
- 收集社區(qū)對這個 Issue 的信息溪厘，回復(fù) Comment胡本，與 SIG 成員達(dá)成一致。必要的時候桩匪，你還需要參加 SIG 的周會打瘪，更好地闡述你的想法和計(jì)劃
- 在與 SIG 的大多數(shù)成員達(dá)成一致后，你就可以開始進(jìn)行詳細(xì)的設(shè)計(jì)了
- 如果設(shè)計(jì)比較復(fù)雜的話傻昙，你還需要在 Kubernetes 的設(shè)計(jì)提議目錄（在 Kubernetes Community 庫里）下提交一個 PR，把你的設(shè)計(jì)文檔加進(jìn)去彩扔。這時候妆档，所有關(guān)心這個設(shè)計(jì)的社區(qū)成員，都會來對你的設(shè)計(jì)進(jìn)行討論虫碉。不過最后贾惦，在整個 Kubernetes 社區(qū)只有很少一部分成員才有權(quán)限來 Review 和 Approve 你的設(shè)計(jì)文檔。他們當(dāng)然也被定義在了這個目錄下面的 OWNERS 文件里敦捧，如下所示
reviewers:
- brendandburns
- dchen1107
- jbeda
- lavalamp
- smarterclayton
- thockin
- wojtek-t
- bgrant0607
approvers:
- brendandburns
- dchen1107
- jbeda
- lavalamp
- smarterclayton
- thockin
- wojtek-t
- bgrant0607
labels:
- kind/design
這幾位成員须板，就可以稱為社區(qū)里的“大佬”了。不過我在這里要提醒你的是兢卵，“大佬”并不一定代表水平高习瑰，所以你還是要擦亮眼睛。此外秽荤，Kubernetes 項(xiàng)目的幾位創(chuàng)始成員甜奄，被稱作 Elders（元老），分別是 jbeda窃款、bgrant0607课兄、brendandburns、dchen1107 和 thockin晨继。
- 上述 Design Proposal 被合并后烟阐，你就可以開始按照設(shè)計(jì)文檔的內(nèi)容編寫代碼了。這個流程紊扬，才是正常大家所熟知的編寫代碼蜒茄、提交 PR、通過 CI 測試珠月、進(jìn)行 Code Review扩淀，然后等待合并的流程。
- 如果你的 feature 是需要要在 Kubernetes 的正式 Release 里發(fā)布上線的啤挎，那么你還需要在Kubernetes Enhancements這個庫里面提交一個 KEP（即 Kubernetes Enhancement Proposal）驻谆。這個 KEP 的主要內(nèi)容卵凑，是詳細(xì)地描述你的編碼計(jì)劃、測試計(jì)劃胜臊、發(fā)布計(jì)劃勺卢，以及向后兼容計(jì)劃等軟件工程相關(guān)的信息，供全社區(qū)進(jìn)行監(jiān)督和指導(dǎo)象对。
以上內(nèi)容黑忱，就是 Kubernetes 社區(qū)運(yùn)作的主要方式了。
