kubernetes社區(qū)與其他開源項(xiàng)目的區(qū)別是什么

本文小編為大家詳細(xì)介紹“kubernetes社區(qū)與其他開源項(xiàng)目的區(qū)別是什么”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“kubernetes社區(qū)與其他開源項(xiàng)目的區(qū)別是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識(shí)吧。

我們知道 Kubernetes 這個(gè)項(xiàng)目是托管在 CNCF 基金會(huì)下面的。但是，我在專欄最前面講解容器與 Kubernetes 的發(fā)展歷史的時(shí)候就已經(jīng)提到過，CNCF 跟 Kubernetes 的關(guān)系，并不是傳統(tǒng)意義上的基金會(huì)與托管項(xiàng)目的關(guān)系，CNCF 實(shí)際上扮演的，是 Kubernetes 項(xiàng)目的 Marketing 的角色。
這就好比，本來 Kubernetes 項(xiàng)目應(yīng)該是由 Google 公司一家維護(hù)、運(yùn)營和推廣的。但是為了表示中立，并且吸引更多的貢獻(xiàn)者加入，Kubernetes 項(xiàng)目從一開始就選擇了由基金會(huì)托管的模式。而這里的關(guān)鍵在于，這個(gè)基金會(huì)本身，就是 Kubernetes 背后 的“大佬們”一手創(chuàng)建出來的，然后以中立的方式，對(duì) Kubernetes 項(xiàng)目進(jìn)行運(yùn)營和 Marketing
通過這種方式，Kubernetes 項(xiàng)目既避免了因?yàn)?Google 公司在開源社區(qū)里的“不良作風(fēng)”和非中立角色被競(jìng)爭(zhēng)對(duì)手口誅筆伐，又可以站在開源基金會(huì)的制高點(diǎn)上團(tuán)結(jié)社區(qū)里所有跟容器相關(guān)的力量。而隨后 CNCF 基金會(huì)的迅速發(fā)展和壯大，也印證了這個(gè)思路其實(shí)是非常正確和有先見之明的。 不過，在 Kubernetes 和 Prometheus 這兩個(gè) CNCF 的一號(hào)和二號(hào)項(xiàng)目相繼畢業(yè)之后，現(xiàn)在 CNCF 社區(qū)的更多職能，就是扮演一個(gè)傳統(tǒng)的開源基金會(huì)的角色，吸納會(huì)員，幫助項(xiàng)目孵化和運(yùn)轉(zhuǎn)
只不過，由于 Kubernetes 項(xiàng)目的巨大成功，CNCF 在云計(jì)算領(lǐng)域已經(jīng)取得了極高的聲譽(yù)和認(rèn)可度，也填補(bǔ)了以往 Linux 基金會(huì)在這一領(lǐng)域的空白。所以說，你可以認(rèn)為現(xiàn)在的 CNCF，就是云計(jì)算領(lǐng)域里的 Apache ，而它的作用跟當(dāng)年大數(shù)據(jù)領(lǐng)域里 Apache 基金會(huì)的作用是一樣的。
不過，需要指出的是，對(duì)于開源項(xiàng)目和開源社區(qū)的運(yùn)作來說，第三方基金會(huì)從來就不是一個(gè)必要條件。事實(shí)上，這個(gè)世界上絕大多數(shù)成功的開源項(xiàng)目和社區(qū)，都來自于一個(gè)聰明的想法或者一幫杰出的黑客。在這些項(xiàng)目的發(fā)展過程中，一個(gè)獨(dú)立的、第三方基金會(huì)的作用，更多是在該項(xiàng)目發(fā)展到一定程度后主動(dòng)進(jìn)行商業(yè)運(yùn)作的一部分。開源項(xiàng)目與基金會(huì)間的這一層關(guān)系，希望你不要本末倒置了
另外，需要指出的是，CNCF 基金會(huì)僅僅負(fù)責(zé)成員項(xiàng)目的 Marketing， 而絕不會(huì)、也沒有能力直接影響具體項(xiàng)目的發(fā)展歷程。無論是任何一家成員公司或者是 CNCF 的 TOC（Technical Oversight Committee，技術(shù)監(jiān)督委員會(huì)），都沒有對(duì) Kubernetes 項(xiàng)目“指手畫腳”的權(quán)利，除非這位 TOC 本人就是 Kubernetes 項(xiàng)目里的關(guān)鍵人物。
所以說，真正能夠影響 Kubernetes 項(xiàng)目發(fā)展的，當(dāng)然還是 Kubernetes 社區(qū)本身。可能你會(huì)好奇，Kubernetes 社區(qū)本身的運(yùn)作方式，又是怎樣的呢？
通常情況下，一個(gè)基金會(huì)下面托管的項(xiàng)目，都需要遵循基金會(huì)本身的管理機(jī)制，比如統(tǒng)一的 CI 系統(tǒng)、Code Review 流程、管理方式等等。
但是，在我們這個(gè)社區(qū)的實(shí)際情況，是先有的 Kubernetes，然后才有的 CNCF，并且 CNCF 基金會(huì)還是 Kubernetes “一手帶大”的。所以，在項(xiàng)目治理這個(gè)事情上，Kubernetes 項(xiàng)目早就自成體系，并且發(fā)展得非常完善了。而基金會(huì)里的其他項(xiàng)目一般各自為陣，CNCF 不會(huì)對(duì)項(xiàng)目本身的治理方法提出過多的要求
而說到 Kubernetes 項(xiàng)目的治理方式，其實(shí)還是比較貼近 Google 風(fēng)格的，即：重視代碼，重視社區(qū)的民主性。
首先，Kubernetes 項(xiàng)目是一個(gè)沒有“Maintainer”的項(xiàng)目。這一點(diǎn)非常有意思，Kubernetes 項(xiàng)目里曾經(jīng)短時(shí)間內(nèi)存在過 Maintainer 這個(gè)角色，但是很快就被廢棄了。取而代之的，則是 approver+reviewer 機(jī)制。這里具體的原理，是在 Kubernetes 的每一個(gè)目錄下，你都可以添加一個(gè) OWNERS 文件，然后在文件里寫入這樣的字段：

approvers:
- caesarxuchao
reviewers:
- lavalamp
labels:
- sig/api-machinery
- area/apiserver

比如，上面這個(gè)例子里，approver 的 GitHub ID 就是 caesarxuchao （Xu Chao），reviewer 就是 lavalamp。這就意味著，任何人提交的 Pull Request（PR，代碼修改請(qǐng)求），只要修改了這個(gè)目錄下的文件，那么就必須要經(jīng)過 lavalamp 的 Code Review，然后再經(jīng)過 caesarxuchao 的 Approve 才可以被合并。當(dāng)然，在這個(gè)文件里，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）就會(huì)自動(dòng)給該 PR 加上 lgtm 和 approve 標(biāo)簽，然后進(jìn)入 Kubernetes 項(xiàng)目 CI 系統(tǒng)的合并隊(duì)列，最后被合并。此外，如果你要對(duì)這個(gè)項(xiàng)目加標(biāo)簽，或者把它 Assign 給其他人，也都可以通過 Comment 的方式來進(jìn)行。
可以看到，在上述整個(gè)過程中，代碼維護(hù)者不需要對(duì) Kubernetes 項(xiàng)目擁有寫權(quán)限，就可以完成代碼審核、合并等所有流程。這當(dāng)然得益于 Kubernetes 社區(qū)完善的機(jī)器人機(jī)制，這也是 GitHub 最吸引人的特性之一。
順便說一句，很多人問我，GitHub 比 GitLab 或者其他代碼托管平臺(tái)強(qiáng)在哪里？實(shí)際上， GitHub 龐大的 API 和插件生態(tài)，才是這個(gè)產(chǎn)品最具吸引力的地方。
當(dāng)然，當(dāng)你想要將你的想法以代碼的形式提交給 Kubernetes 項(xiàng)目時(shí)，除非你的改動(dòng)是 bugfix 或者很簡(jiǎn)單的改動(dòng)，否則，你直接提交一個(gè) PR 上去，是大概率不會(huì)被 Approve 的。這里的流程，一定要按照我下面的講解來進(jìn)行：

1. 在 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)行討論。

2. 給 Issue 加上與它相關(guān)的 SIG 的標(biāo)簽。比如，你可以直接 Comment /sig node，那么這個(gè) Issue 就會(huì)被加上 sig-node 的標(biāo)簽，這樣 SIG-Node 的成員就會(huì)特別留意這個(gè) Issue。

3. 收集社區(qū)對(duì)這個(gè) Issue 的信息，回復(fù) Comment，與 SIG 成員達(dá)成一致。必要的時(shí)候，你還需要參加 SIG 的周會(huì)，更好地闡述你的想法和計(jì)劃

4. 在與 SIG 的大多數(shù)成員達(dá)成一致后，你就可以開始進(jìn)行詳細(xì)的設(shè)計(jì)了

5. 如果設(shè)計(jì)比較復(fù)雜的話，你還需要在 Kubernetes 的設(shè)計(jì)提議目錄（在 Kubernetes Community 庫里）下提交一個(gè) PR，把你的設(shè)計(jì)文檔加進(jìn)去。這時(shí)候，所有關(guān)心這個(gè)設(shè)計(jì)的社區(qū)成員，都會(huì)來對(duì)你的設(shè)計(jì)進(jìn)行討論。不過最后，在整個(gè) Kubernetes 社區(qū)只有很少一部分成員才有權(quán)限來 Review 和 Approve 你的設(shè)計(jì)文檔。他們當(dāng)然也被定義在了這個(gè)目錄下面的 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。

1. 上述 Design Proposal 被合并后，你就可以開始按照設(shè)計(jì)文檔的內(nèi)容編寫代碼了。這個(gè)流程，才是正常大家所熟知的編寫代碼、提交 PR、通過 CI 測(cè)試、進(jìn)行 Code Review，然后等待合并的流程。

2. 如果你的 feature 是需要要在 Kubernetes 的正式 Release 里發(fā)布上線的，那么你還需要在Kubernetes Enhancements這個(gè)庫里面提交一個(gè) KEP（即 Kubernetes Enhancement Proposal）。這個(gè) KEP 的主要內(nèi)容，是詳細(xì)地描述你的編碼計(jì)劃、測(cè)試計(jì)劃、發(fā)布計(jì)劃，以及向后兼容計(jì)劃等軟件工程相關(guān)的信息，供全社區(qū)進(jìn)行監(jiān)督和指導(dǎo)。
   

讀到這里，這篇“kubernetes社區(qū)與其他開源項(xiàng)目的區(qū)別是什么”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。