?譯者 | 布加迪

審校 | 孫淑娟

開源生態(tài)系統(tǒng)已從企業(yè)支持有限的小眾項目迅速變成開發(fā)軟件的默認方式。大大小小的組織都在使用開源軟件加快創(chuàng)新和產(chǎn)品開發(fā)。

企業(yè)開源現(xiàn)狀調(diào)查發(fā)現(xiàn)，95%的企業(yè)都很重視開源；75%的企業(yè)聲稱開源軟件對IT戰(zhàn)略極其重要；77%的企業(yè)計劃在來年加大使用開源的力度。

與此同時，71%的英國政府技術(shù)員工表示，他們使用的開源軟件比五年前更多。美國國防部甚至發(fā)布了一份備忘錄，表明其首選是開源軟件，而不是專有軟件。

Kubernetes趨于成熟后，市場已出現(xiàn)了合并，許多Kubernetes產(chǎn)品提供不同的架構(gòu)、功能和接口——有些產(chǎn)品不如另一些開放、靈活，附有不同的限制、依賴項和許可條款。

偏離開放的Kubernetes標準可能會導(dǎo)致問題。正如《云計算雜志》特別指出，“如果沒有適當?shù)臉藴驶袷剑秃茈y確保互操作性、可移植性、合規(guī)、信任和安全性。”

1、什么是純粹的上游開源Kubernetes？

上游Kubernetes是Kubernetes的開源版本，由云原生計算基金會托管和維護，該基金會開發(fā)代碼、編制文檔，并貢獻代碼。它由核心的“普通”Kubernetes組成，用于編排容器，無需附加應(yīng)用程序，一切都可以公開訪問，用于檢查、修改和重新分發(fā)。

免費開源軟件項目都出于美好的初衷——創(chuàng)造有助于整個社區(qū)的技術(shù)。任何人都可以訪問代碼，進行協(xié)作以快速修復(fù)錯誤、添加補丁和優(yōu)化性能。但是項目發(fā)展會導(dǎo)致目標和觀點出現(xiàn)分歧，即代碼中的“分叉”（fork）。

2、什么是Kubernetes的分叉？

Kubernetes的分叉是獨立于主工作流開發(fā)的開源項目版本。當開發(fā)社區(qū)的一部分人或第三方供應(yīng)商復(fù)制上游項目，但作了若干修改，以啟動完全獨立的開發(fā)路線時，就出現(xiàn)分叉。

分叉Kubernetes的原因可能是意見不同（技術(shù)上的或個人上的）、上游項目的開發(fā)停滯不前，或者想要不同的功能。這可能發(fā)生在開源環(huán)境或?qū)Ｓ协h(huán)境中。

開源Kubernetes分叉改進原始代碼后，其他分叉可以利用它，將代碼與各自的分叉結(jié)合起來，更好地滿足開發(fā)人員和最終用戶的需求。

但是就專有環(huán)境中的Kubernetes分叉而言，供應(yīng)商或云公司將改變源代碼以滿足自己的需求，重新打包軟件，并將其作為專有發(fā)行版提供給客戶。它們可能會改變在生產(chǎn)環(huán)境中運行Kubernetes所需的附加組件。

這使得解決方案的管理變得很復(fù)雜，還存在供應(yīng)商鎖定風(fēng)險。

3、分叉Kubernetes的問題

大規(guī)模部署和管理Kubernetes很困難。許多組織使用專有發(fā)行版來獲得對容器平臺的企業(yè)支持，但這導(dǎo)致了Kubernetes明顯分叉的版本。

一些挑戰(zhàn)包括如下：

（1）補丁、錯誤修復(fù)、升級和新功能方面很復(fù)雜

每一次新的更新都會使變更更難與自定義發(fā)行版兼容。這是一個緩慢而燒錢的過程。分叉Kubernetes的供應(yīng)商常常使用較舊版本的集群API，因為它們需要花費至少6個月從上游獲得改進和錯誤修復(fù)。

（2）供應(yīng)商鎖定

Kubernetes中的分叉會造成鎖定，即客戶無法輕松替換或遷移解決方案。它消除了在公共、私有和內(nèi)部服務(wù)之間無縫移動應(yīng)用程序和數(shù)據(jù)的靈活性。貴公司發(fā)展壯大后，鎖定問題也無法為貴公司提供多種選擇。即使源代碼是開源的，供應(yīng)商也可以用一些特性包裝Kubernetes，這些特性防止客戶遷移到其他平臺。

（3）缺乏功能

Kubernetes的分叉版本可能會破壞應(yīng)用程序的功能。一些自定義發(fā)行版依賴專有的API和CLI來獲得完整功能，這導(dǎo)致了鎖定現(xiàn)象。如果自定義發(fā)行版只在供應(yīng)商的自定義Linux內(nèi)核上運行，它也導(dǎo)致鎖定現(xiàn)象。最終，維護這個分叉變得更困難，阻止人們在未對補丁和功能兼容方面進行重大工作的情況下將最新的上游補丁合并到分叉中。如果一種產(chǎn)品關(guān)停，您可能就不走運了。

（4）不太安全

Kubernetes的分叉可能會運行不太安全的代碼。如果在開源代碼中發(fā)現(xiàn)了一個漏洞，并由上游社區(qū)修復(fù)，分叉版本的代碼可能不會受益，因為它與上游代碼不一樣。

（5）缺乏互操作性

供應(yīng)商可以針對其自定義發(fā)行版或讓Kubernetes在生產(chǎn)環(huán)境中運行所需的支撐性應(yīng)用程序修改代碼。雖然Kubernetes的修改版可以與特定供應(yīng)商的應(yīng)用程序堆棧和管理工具協(xié)同運行，但這些專有的修改會導(dǎo)致您被定制的組件構(gòu)建束縛，讓您無法與其他上游開源項目集成。如果他們的堆棧包含多個產(chǎn)品，很難實現(xiàn)互操作性，這可能會在您擴展規(guī)模時導(dǎo)致許多下游問題。

（6）技術(shù)債務(wù)

很難將一個與上游發(fā)生了巨大變化的分叉合并回去。我們稱之為技術(shù)債務(wù)，即偏離聯(lián)合開發(fā)的主分支導(dǎo)致的維護源代碼的成本。對分叉代碼的變更越多，就意味著讓分叉重新回歸上游項目所需的資金和時間就越多。

4、純粹的上游Kubernetes是出路

純粹的上游開源Kubernetes是決策制定的焦點，是貢獻代碼的地方，帶有一個內(nèi)置的社區(qū)，不斷改進源代碼。

純粹的上游解決方案允許與更大的社區(qū)分享想法，并獲得上游接受的新功能和新版本。每個基于上游的項目和產(chǎn)品在選擇未來版本或合并最近（或所有）的上游補丁時，都受益于 以前的工作。

雖然任何人都可以從上游代碼庫復(fù)制、安裝或分發(fā)Kubernetes，但大公司和大組織需要經(jīng)過認證、測試和加固的產(chǎn)品供企業(yè)環(huán)境使用。因此，組織依賴供應(yīng)商將上游Kubernetes變成滿足其業(yè)務(wù)需求的下游產(chǎn)品。

原文鏈接：https://www.cncf.io/blog/2023/01/30/pure-upstream-kubernetes-is-the-best-kubernetes/