本文小編為大家詳細介紹“kubernetes社區與其他開源項目的區別是什么”，內容詳細，步驟清晰，細節處理妥當，希望這篇“kubernetes社區與其他開源項目的區別是什么”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。
我們知道 Kubernetes 這個項目是托管在 CNCF 基金會下面的。但是，我在專欄最前面講解容器與 Kubernetes 的發展歷史的時候就已經提到過，CNCF 跟 Kubernetes 的關系，并不是傳統意義上的基金會與托管項目的關系，CNCF 實際上扮演的，是 Kubernetes 項目的 Marketing 的角色。
這就好比，本來 Kubernetes 項目應該是由 Google 公司一家維護、運營和推廣的。但是為了表示中立，并且吸引更多的貢獻者加入，Kubernetes 項目從一開始就選擇了由基金會托管的模式。而這里的關鍵在于，這個基金會本身，就是 Kubernetes 背后 的“大佬們”一手創建出來的，然后以中立的方式，對 Kubernetes 項目進行運營和 Marketing
通過這種方式，Kubernetes 項目既避免了因為 Google 公司在開源社區里的“不良作風”和非中立角色被競爭對手口誅筆伐，又可以站在開源基金會的制高點上團結社區里所有跟容器相關的力量。而隨后 CNCF 基金會的迅速發展和壯大，也印證了這個思路其實是非常正確和有先見之明的。 不過，在 Kubernetes 和 Prometheus 這兩個 CNCF 的一號和二號項目相繼畢業之后，現在 CNCF 社區的更多職能，就是扮演一個傳統的開源基金會的角色，吸納會員，幫助項目孵化和運轉
只不過，由于 Kubernetes 項目的巨大成功，CNCF 在云計算領域已經取得了極高的聲譽和認可度，也填補了以往 Linux 基金會在這一領域的空白。所以說，你可以認為現在的 CNCF，就是云計算領域里的 Apache ，而它的作用跟當年大數據領域里 Apache 基金會的作用是一樣的。
不過，需要指出的是，對于開源項目和開源社區的運作來說，第三方基金會從來就不是一個必要條件。事實上，這個世界上絕大多數成功的開源項目和社區，都來自于一個聰明的想法或者一幫杰出的黑客。在這些項目的發展過程中，一個獨立的、第三方基金會的作用，更多是在該項目發展到一定程度后主動進行商業運作的一部分。開源項目與基金會間的這一層關系，希望你不要本末倒置了
另外，需要指出的是，CNCF 基金會僅僅負責成員項目的 Marketing， 而絕不會、也沒有能力直接影響具體項目的發展歷程。無論是任何一家成員公司或者是 CNCF 的 TOC（Technical Oversight Committee，技術監督委員會），都沒有對 Kubernetes 項目“指手畫腳”的權利，除非這位 TOC 本人就是 Kubernetes 項目里的關鍵人物。
所以說，真正能夠影響 Kubernetes 項目發展的，當然還是 Kubernetes 社區本身?？赡苣銜闷?，Kubernetes 社區本身的運作方式，又是怎樣的呢？
通常情況下，一個基金會下面托管的項目，都需要遵循基金會本身的管理機制，比如統一的 CI 系統、Code Review 流程、管理方式等等。
但是，在我們這個社區的實際情況，是先有的 Kubernetes，然后才有的 CNCF，并且 CNCF 基金會還是 Kubernetes “一手帶大”的。所以，在項目治理這個事情上，Kubernetes 項目早就自成體系，并且發展得非常完善了。而基金會里的其他項目一般各自為陣，CNCF 不會對項目本身的治理方法提出過多的要求
而說到 Kubernetes 項目的治理方式，其實還是比較貼近 Google 風格的，即：重視代碼，重視社區的民主性。
首先，Kubernetes 項目是一個沒有“Maintainer”的項目。這一點非常有意思，Kubernetes 項目里曾經短時間內存在過 Maintainer 這個角色，但是很快就被廢棄了。取而代之的，則是 approver+reviewer 機制。這里具體的原理，是在 Kubernetes 的每一個目錄下，你都可以添加一個 OWNERS 文件，然后在文件里寫入這樣的字段：
approvers: - caesarxuchao reviewers: - lavalamp labels: - sig/api-machinery - area/apiserver
比如，上面這個例子里，approver 的 GitHub ID 就是 caesarxuchao （Xu Chao），reviewer 就是 lavalamp。這就意味著，任何人提交的 Pull Request（PR，代碼修改請求），只要修改了這個目錄下的文件，那么就必須要經過 lavalamp 的 Code Review，然后再經過 caesarxuchao 的 Approve 才可以被合并。當然，在這個文件里，caesarxuchao 的權力是最大的，它可以既做 Code Review，也做最后的 Approve。但， lavalamp 是不能進行 Approve 的。
當然，無論是 Code Review 通過，還是 Approve，這些維護者只需要在 PR 下面 Comment /lgtm 和 /approve，Kubernetes 項目的機器人（k8s-ci-robot）就會自動給該 PR 加上 lgtm 和 approve 標簽，然后進入 Kubernetes 項目 CI 系統的合并隊列，最后被合并。此外，如果你要對這個項目加標簽，或者把它 Assign 給其他人，也都可以通過 Comment 的方式來進行。
可以看到，在上述整個過程中，代碼維護者不需要對 Kubernetes 項目擁有寫權限，就可以完成代碼審核、合并等所有流程。這當然得益于 Kubernetes 社區完善的機器人機制，這也是 GitHub 最吸引人的特性之一。
順便說一句，很多人問我，GitHub 比 GitLab 或者其他代碼托管平臺強在哪里？實際上， GitHub 龐大的 API 和插件生態，才是這個產品最具吸引力的地方。
當然，當你想要將你的想法以代碼的形式提交給 Kubernetes 項目時，除非你的改動是 bugfix 或者很簡單的改動，否則，你直接提交一個 PR 上去，是大概率不會被 Approve 的。這里的流程，一定要按照我下面的講解來進行：
在 Kubernetes 主庫里創建 Issue，詳細地描述你希望解決的問題、方案，以及開發計劃。而如果社區里已經有相關的 Issue 存在，那你就必須要在這里把它們引用過來。而如果社區里已經存在相同的 Issue 了，你就需要確認一下，是不是應該直接轉到原有 issue 上進行討論。
給 Issue 加上與它相關的 SIG 的標簽。比如，你可以直接 Comment /sig node，那么這個 Issue 就會被加上 sig-node 的標簽，這樣 SIG-Node 的成員就會特別留意這個 Issue。
收集社區對這個 Issue 的信息，回復 Comment，與 SIG 成員達成一致。必要的時候，你還需要參加 SIG 的周會，更好地闡述你的想法和計劃
在與 SIG 的大多數成員達成一致后，你就可以開始進行詳細的設計了
如果設計比較復雜的話，你還需要在 Kubernetes 的設計提議目錄（在 Kubernetes Community 庫里）下提交一個 PR，把你的設計文檔加進去。這時候，所有關心這個設計的社區成員，都會來對你的設計進行討論。不過最后，在整個 Kubernetes 社區只有很少一部分成員才有權限來 Review 和 Approve 你的設計文檔。他們當然也被定義在了這個目錄下面的 OWNERS 文件里，如下所示
reviewers: - brendandburns - dchen1107 - jbeda - lavalamp - smarterclayton - thockin - wojtek-t - bgrant0607 approvers: - brendandburns - dchen1107 - jbeda - lavalamp - smarterclayton - thockin - wojtek-t - bgrant0607 labels: - kind/design
這幾位成員，就可以稱為社區里的“大佬”了。不過我在這里要提醒你的是，“大佬”并不一定代表水平高，所以你還是要擦亮眼睛。此外，Kubernetes 項目的幾位創始成員，被稱作 Elders（元老），分別是 jbeda、bgrant0607、brendandburns、dchen1107 和 thockin。
上述 Design Proposal 被合并后，你就可以開始按照設計文檔的內容編寫代碼了。這個流程，才是正常大家所熟知的編寫代碼、提交 PR、通過 CI 測試、進行 Code Review，然后等待合并的流程。
如果你的 feature 是需要要在 Kubernetes 的正式 Release 里發布上線的，那么你還需要在Kubernetes Enhancements這個庫里面提交一個 KEP（即 Kubernetes Enhancement Proposal）。這個 KEP 的主要內容，是詳細地描述你的編碼計劃、測試計劃、發布計劃，以及向后兼容計劃等軟件工程相關的信息，供全社區進行監督和指導。
讀到這里，這篇“kubernetes社區與其他開源項目的區別是什么”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
