?譯者 | 布加迪

審校 | 孫淑娟

開源生態(tài)系統(tǒng)已從企業(yè)支持有限的小眾項目迅速變成開發(fā)軟件的默認(rèn)方式。大大小小的組織都在使用開源軟件加快創(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標(biāo)準(zhǔn)可能會導(dǎo)致問題。正如《云計算雜志》特別指出，“如果沒有適當(dāng)?shù)臉?biāo)準(zhǔn)化格式，就很難確?；ゲ僮餍?、可移植性、合規(guī)、信任和安全性?！?/p>

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

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

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

2、什么是Kubernetes的分叉？

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

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

開源Kubernetes分叉改進(jìn)原始代碼后，其他分叉可以利用它，將代碼與各自的分叉結(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個月從上游獲得改進(jìn)和錯誤修復(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)象。最終，維護(hù)這個分叉變得更困難，阻止人們在未對補丁和功能兼容方面進(jì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)致的維護(hù)源代碼的成本。對分叉代碼的變更越多，就意味著讓分叉重新回歸上游項目所需的資金和時間就越多。

4、純粹的上游Kubernetes是出路

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

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

雖然任何人都可以從上游代碼庫復(fù)制、安裝或分發(fā)Kubernetes，但大公司和大組織需要經(jīng)過認(rèn)證、測試和加固的產(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/