先說結(jié)論我花了一個多月時間把Red Hat開源的企業(yè)Kubernetes發(fā)行版底座OpenShift Origin源碼倉庫整個翻了一遍最終文件總數(shù)停在36669個。這個數(shù)字不是宣傳口徑是我在自己機器上跑find數(shù)出來的。很多人以為OpenShift Origin只是OpenShift Container Platform的一個“開源影子”真正拆開源碼工程之后才會發(fā)現(xiàn)它承載的東西遠比想象中復(fù)雜。這篇評測沒有停留在表面概念而是把它當(dāng)做一個真實的代碼庫來盡調(diào)目錄結(jié)構(gòu)、依賴管理、構(gòu)建體系、測試覆蓋、API演進痕跡以及企業(yè)如果拿這套底座做二次開發(fā)和長期落地到底會踩到什么級別的坑。讀者對象很明確準(zhǔn)備評估Red Hat系平臺底座的技術(shù)負責(zé)人、需要對Kubernetes發(fā)行版做源碼級選型對比的架構(gòu)師以及那些想把OpenShift Origin當(dāng)作學(xué)習(xí)樣本、搞明白“企業(yè)級K8s發(fā)行版內(nèi)部構(gòu)造”的開發(fā)者。普通Kubernetes使用者可以略過這篇文章但如果你的工作涉及私有云底座、容器平臺二次開發(fā)、信創(chuàng)環(huán)境適配這套評測方法可以直接搬走。1. 為什么要把OpenShift Origin源碼翻個底朝天在多數(shù)人的認知里Red Hat公司靠訂閱和服務(wù)賺錢OpenShift的源碼更像是“擺出來證明開源姿態(tài)”的附屬品。但真正開始做企業(yè)級底座選型之后你會發(fā)現(xiàn)評估一個發(fā)行版能不能落地光看官方文檔和宣傳PPT根本不夠。文檔告訴你它能做什么源碼告訴你它實際怎么做的而“實際怎么做”決定了你在運維、排障、二次開發(fā)時到底要付出多少成本。我接這個評測的出發(fā)點也在這里團隊那段時間正在評估一個私有容器平臺底座方案Red Hat系的OpenShift Origin在候選名單里。候選對象不止它一個但OpenShift Origin有個特殊優(yōu)勢——它能作為Red Hat商業(yè)發(fā)行版的代碼級參照物而且倉庫結(jié)構(gòu)相對集中。與其在多個方案之間反復(fù)開會爭論不如直接把源碼拉下來做一次靜態(tài)盡調(diào)用文件數(shù)量、依賴規(guī)模、代碼組織方式這些硬指標(biāo)說話。這次評測采用的方法是純靜態(tài)分析不運行集群不部署組件只看源碼工程本身。靜態(tài)評測能回答的問題很多。比如工程結(jié)構(gòu)是否利于二次開發(fā)、依賴鎖定策略是否可靠、構(gòu)建腳本是否能在離線環(huán)境復(fù)現(xiàn)、測試覆蓋哪些模塊強哪些模塊弱、API版本的演進是否留有兼容路徑。這些問題全部可以在不啟動集群的前提下得到相對明確的答案。等靜態(tài)評測做完再決定要不要投入資源做動態(tài)驗證這個順序比較合理也能避免團隊在沒搞清底座底細的情況下就盲目啟動驗證環(huán)境。評測對象需要說明清楚。這次拉取的是openshift/origin倉庫的源碼快照也就是OpenShift Origin工程本體。它是OpenShift Container Platform的商業(yè)產(chǎn)品的上游來源之一承載了大量Kubernetes底座之上的擴展邏輯。36669個文件是包含vendor目錄在內(nèi)的全量統(tǒng)計這個口徑后面會細說。2. 36669文件全景拆解OpenShift Origin源碼工程結(jié)構(gòu)到底長什么樣2.1 復(fù)現(xiàn)36669這個數(shù)字一次誠實的靜態(tài)統(tǒng)計先把數(shù)字講清楚因為“36669”很容易被誤讀。我在評測報告里看到過有人直接用這個數(shù)說“工程極其龐大”也有人說“其中一半是vendor核心代碼沒多少”。為了準(zhǔn)確我把復(fù)現(xiàn)方法寫在這里。# 克隆倉庫建議使用固定tag git clone --depth1 --branch 某個release tag https://github.com/openshift/origin.git cd origin # 統(tǒng)計全量文件數(shù) find . -type f | wc -l # 排除vendor第三方依賴庫之后再看 find . -path ./vendor -prune -o -type f -print | wc -l # 只看Go源文件 find . -name *.go | wc -l # 統(tǒng)計測試文件占比 find . -name *_test.go | wc -l # 統(tǒng)計vendor占多少 find vendor -type f | wc -l實測下來的分布大致是包含vendor在內(nèi)全量文件數(shù)就是36669排除vendor后項目自身文件數(shù)在一萬上下Go源文件占大頭vendor里又以Kubernetes相關(guān)依賴和各類第三方庫為主。這個數(shù)字說明不了“好不好”但它說明了一個事實這是一個重量級工程復(fù)雜度和普通業(yè)務(wù)系統(tǒng)完全不在一個量級。團隊如果打算從零讀懂整個倉庫那是不現(xiàn)實的但選擇性地讀關(guān)鍵模塊完全可行。2.2 目錄體系從pkg到hack責(zé)任邊界清晰嗎OpenShift Origin的頂層目錄結(jié)構(gòu)很有代表性我列一下核心目錄api/ 對外API對象的定義、類型和版本化目錄 cmd/ 各二進制程序的入口openshift、oc、operator等 pkg/ 核心業(yè)務(wù)邏輯按功能域拆分 tools/ 輔助工具和代碼生成器 hack/ 構(gòu)建、驗證、代碼生成等本地腳本 docs/ 設(shè)計文檔和使用文檔 examples/ 示例應(yīng)用和配置文件 vendor/ 第三方依賴pkg/是整個工程的精髓所在二級目錄基本按照OpenShift的核心能力域劃分auth、build、deploy、image、network、oauth、project、route、security、template、user。隨便挑幾個目錄進去看會發(fā)現(xiàn)每個功能域都是完整的Kubernetes風(fēng)格實現(xiàn)有API類型定義、有策略對象、有控制器邏輯、有校驗函數(shù)。這意味著如果企業(yè)需要針對某個特定能力做定制比如改造Build流程實現(xiàn)自己的鏡像構(gòu)建鏈可以直接定位到pkg/build去改不需要把整個集群跑起來猜代碼位置。hack/目錄值得單獨提一下。這里塞了大量名為verify-*、update-*、gen-*的腳本。比如hack/verify-gofmt.sh這類腳本是Red Hat用來保證代碼風(fēng)格一致性的自動化關(guān)卡。我在做靜態(tài)評測時習(xí)慣先看hack/目錄因為一個工程的自動化成熟度從這些腳本的數(shù)量和細膩程度就能看出七八分。OpenShift Origin這塊做得相當(dāng)扎實最起碼當(dāng)年看起來是有一套成型CI紀律的。2.3 Go代碼之外的拼圖模板、樣例、文檔與自動化腳本很多人評測源碼只盯著.go文件這其實是很大的誤區(qū)。像OpenShift Origin這種企業(yè)級底座真正的工程邊界遠不止Go代碼。模板資源、CRD定義、部署清單、示例應(yīng)用、自動化腳本共同構(gòu)成了這個工程的全貌。examples/目錄里放了各種示例——大到完整的應(yīng)用部署模板小到單個路由配置。這些示例看著不起眼實際是企業(yè)做POC時最實用的參考。官方文檔可以寫得含糊但示例文件可以直接復(fù)制去跑。docs/目錄里則能看到不少設(shè)計提案和架構(gòu)說明對理解組件的設(shè)計意圖特別有幫助。靜態(tài)評測如果只看代碼不看文檔很容易陷入“知其然不知其所以然”的狀態(tài)。另外tools/里有代碼生成器。OpenShift和Kubernetes一樣API對象大量依賴自動生成的client、deepcopy和informer代碼。手寫這些不現(xiàn)實進化靠的是生成邏輯。所以我在評測時專門確認了如果改了API類型定義能否通過工具鏈重新生成代碼。這個問題的答案直接決定二次開發(fā)的效率。3. 工程質(zhì)量六個評估維度一次靜態(tài)盡調(diào)能看出什么3.1 依賴治理vendor目錄里的歷史包袱OpenShift Origin的依賴管理在Go語言社區(qū)里屬于“過渡時代”的代表。早期用Godeps.json這類方式后來演進到glide、dep再后來跟進Go module。但在倉庫快照里vendor目錄仍然占據(jù)極大比重其中包含對Kubernetes各模塊的fork。這帶來兩個直接影響。第一構(gòu)建環(huán)境強依賴vendor一致性。任何go build都必須嚴格關(guān)聯(lián)到vendor版本升級其中的一個核心依賴如果不小心就會把整個編譯鏈路帶崩。第二安全問題排查成本高。像這類巨型vendor目錄漏洞掃描工具跑出來的結(jié)果往往成百上千條但真正有效的是層層過濾之后剩下的小部分這需要專門的團隊人力來跟蹤處理。我的判斷是作為學(xué)習(xí)研究和企業(yè)二次開發(fā)的底座vendor副本能保證快速復(fù)現(xiàn)構(gòu)建這點是好事。但反過來如果企業(yè)計劃長期跟進上游版本依賴同步的負擔(dān)非常重。團隊里至少要有一到兩個人能看懂Kubernetes版本變化對OpenShift擴展層的影響否則升級評估都無從下手。3.2 代碼規(guī)范與靜態(tài)檢查企業(yè)接手前的體檢報告大型開源項目的代碼規(guī)范往往存在“主要模塊嚴格、邊緣模塊散漫”的情況OpenShift Origin也有這個特征。核心模塊如pkg/route、pkg/security的代碼風(fēng)格基本統(tǒng)一注釋完整函數(shù)職責(zé)清楚這和Kubernetes上游代碼庫一脈相承。但一些邊緣工具或測試輔助代碼的注釋就明顯少了屬于能跑就行。用靜態(tài)檢查工具掃描整個倉庫的時候一個比較明顯的問題是代碼重復(fù)和過度抽象并存。OpenShift為了兼容Kubernetes的API風(fēng)格在大量類型定義上重復(fù)了類似的注釋和結(jié)構(gòu)這部分屬于框架成本不是代碼質(zhì)量問題。真正要關(guān)注的是那些和業(yè)務(wù)行為相關(guān)的邏輯比如認證授權(quán)的過濾鏈、資源配額的校驗邏輯這些地方的代碼質(zhì)量直接關(guān)系到生產(chǎn)安全。做靜態(tài)評測時建議大家重點看三個地方錯誤處理方式是層層包裝還是直接panic、日志輸出是否有結(jié)構(gòu)化日志還有對KubernetesAPI的對象操作是否遵循了控制器勞動循環(huán)的規(guī)范。這三個維度基本能判斷出代碼的可維護性。3.3 測試覆蓋單元測試數(shù)量不等于安全感OpenShift Origin的測試文件數(shù)量不算少但分布極不均衡。核心API邏輯和控制器部分的測試相對完善畢竟要保證和Kubernetes生態(tài)兼容但部分擴展功能、網(wǎng)絡(luò)組件、以及一些運維腳本測試覆蓋就比較薄弱了。對于底座型項目更實際的風(fēng)險在于測試文件里的斷言往往和特定的Kubernetes版本綁定。升級Kubernetes依賴版本后原有測試可能大面積失敗而這些失敗未必代表真實功能損壞也可能是API行為變化導(dǎo)致斷言失效。這個現(xiàn)象在靜態(tài)評測中就能通過對比vendor版本和測試代碼里的版本引用看出端倪。所以我建議要用“代碼路徑覆蓋”的視角看待測試不要只看有多少測試文件而是挑幾個核心流程——比如Pod調(diào)度、鏡像拉取、路由更新——手動追蹤代碼路徑看從API入口到控制器執(zhí)行再到狀態(tài)回寫是否都有對應(yīng)的測試保護。那些沒有測試保護的路徑就是落地后最容易冒問題的地方。3.4 文檔與示例看起來全用起來缺O(jiān)penShift Origin的文檔數(shù)量在同類項目里算是豐富的但靜態(tài)評測之后會發(fā)現(xiàn)一個典型落差架構(gòu)級文檔寫得不錯操作級文檔質(zhì)量參差不齊。比如你想搞明白“DeploymentConfig如何觸發(fā)一次滾動更新”代碼里能拼出完整流程但文檔里可能只有一句含糊的說明。這種情況在企業(yè)落地時會造成一個實質(zhì)性問題團隊只能通過讀代碼或者反復(fù)試探來確認某些行為。對時間緊張的交付項目來說這是隱性成本。建議在選型時把文檔評估分成兩個維度一是面向平臺使用者的運維手冊齊全度二是面向開發(fā)者的接口與設(shè)計文檔齊全度。OpenShift Origin在第二類文檔上有一定積累但至今談不上完善。另外examples目錄里的配置有一些會因為API版本演進而失效。這點在靜態(tài)評測時特別明顯同一個示例文件可能同時出現(xiàn)了v1和v1beta1的舊字段。復(fù)制到新環(huán)境里直接執(zhí)行大概率報錯。所以企業(yè)如果想拿示例做POC建議先跑一遍再寫進交付材料。3.5 API與兼容性設(shè)計版本目錄里的演進痕跡OpenShift Origin的API設(shè)計沿用了Kubernetes的多版本機制在代碼里能看到多個版本共存。這既是一種工程智慧也是兼容性負擔(dān)。版本并存的直接好處是平滑升級壞處是代碼里有大量轉(zhuǎn)換函數(shù)和默認值邏輯稍微改錯一個字段映射就會影響跨版本遷移。在源碼里跟蹤API演進是件很有意思的事。你會在注釋里看到類似“Deprecated: use foo instead”的標(biāo)記只需要grep -r Deprecated pkg/api pkg/apis就能拉出一長串列表。這些標(biāo)記就是技術(shù)債的索引。企業(yè)如果在這個底座上做了定制開發(fā)升級之前必須先過一遍Deprecated清單確認自己的定制部分不受影響。我給的實操建議是項目接手后第一周就建一個“廢棄API追蹤清單”從源碼里把Deprecated和TODO相關(guān)注釋提取出來分類歸檔。這項工作看起來瑣碎但它是避免未來升級踩雷最有效的手段。3.6 構(gòu)建工程化Makefile與hack腳本的門道OpenShift Origin的構(gòu)建體系對新手很不友好但仔細讀下來會發(fā)現(xiàn)其中的合理性。根目錄的Makefile只是入口真正的編排邏輯全部集中在hack/目錄里的Python/Bash腳本。對于習(xí)慣了make build make install的人來說第一次看到hack/build-go.sh可能會有點懵。這套腳本體系的優(yōu)勢是靈活、組合性強可以精準(zhǔn)構(gòu)建單個二進制適合紅帽這樣的多組件發(fā)布節(jié)奏。劣勢也很明顯環(huán)境依賴多、腳本鏈長在離線或隔離環(huán)境下復(fù)現(xiàn)構(gòu)建需要額外工作。企業(yè)如果要在內(nèi)網(wǎng)環(huán)境編譯建議先把依賴緩存和基礎(chǔ)鏡像準(zhǔn)備好再按腳本順序調(diào)試不要直接跑全量構(gòu)建腳本。評測構(gòu)建工程化時還有一個關(guān)鍵指標(biāo)有沒有可重復(fù)構(gòu)建的鎖定機制。OpenShift Origin對Go版本、基礎(chǔ)鏡像版本有明確要求但個別組件存在版本鎖定不嚴格的情況。這意味著今天的構(gòu)建產(chǎn)物和三個月后可能不同。對于追求可復(fù)現(xiàn)交付的企業(yè)這塊需要在持續(xù)集成里額外加鎖。4. 底座還是包袱從源碼工程看企業(yè)落地風(fēng)險4.1 底座型項目的第一風(fēng)險跟隨上游Kubernetes的節(jié)奏OpenShift Origin不是獨立軟件它對Kubernetes的依賴不是簡單的“引用了某個庫”而是深度綁定。scpo里大量代碼直接import了Kubernetes的API和控制器邏輯。這種綁定模式帶來一個尖銳問題上游Kubernetes升級節(jié)奏決定了下游平臺的改造窗口。每次Kubernetes大版本更新一組API被移除或行為調(diào)整OpenShift Origin的適配層都要同步跟進。如果企業(yè)在這個底座上做過深度定制那么這個適配工作量將由企業(yè)自己承擔(dān)。靜態(tài)評測能提前看出端倪你只需要統(tǒng)計vendor里Kubernetes的版本再看代碼里顯式兼容這個版本的代碼量就能大體估算出升級一次要付出多少成本。這不是說OpenShift Origin不值得選而是說要清醒認識到它是“跟跑型底座”。Red Hat會把商業(yè)版本的升級調(diào)優(yōu)做好但企業(yè)內(nèi)部若使用開源版本或基于此二次發(fā)行則必須有專門的團隊盯上游版本變化不能指望紅帽替你解決所有更新問題。4.2 Operator化轉(zhuǎn)型帶來的結(jié)構(gòu)斷層OpenShift Origin源碼結(jié)構(gòu)里有大量傳統(tǒng)“單體控制器”時代的遺留代碼尤其集中在pkg/下。如果你去看新版OpenShift的架構(gòu)會發(fā)現(xiàn)Red Hat已經(jīng)在向Operator模式轉(zhuǎn)型把一個個功能組件拆成獨立的Operator。這意味著老的Origin倉庫和現(xiàn)在商業(yè)發(fā)行版的代碼結(jié)構(gòu)有顯著差異。這個轉(zhuǎn)型對企業(yè)選型意味著什么如果團隊拿老的Origin源碼當(dāng)作商業(yè)版直接代碼級參考會發(fā)現(xiàn)在網(wǎng)絡(luò)、存儲、監(jiān)控等組件上兩套架構(gòu)對不上。我的建議是把Origin看作“理解OpenShift API和功能模型的字典”但不要把它當(dāng)“商業(yè)版源碼鏡像”。真正做二次開發(fā)時需要按商業(yè)版對應(yīng)的Operator框架重新適配。靜態(tài)評測的價值在于理解技術(shù)演進方向避免開發(fā)團隊在舊結(jié)構(gòu)上投入過多。4.3 網(wǎng)絡(luò)、存儲、認證這些“落地三件套”復(fù)雜度企業(yè)級Kubernetes落地時最難的部分往往不是Kubernetes本身而是網(wǎng)絡(luò)、存儲、認證這些基礎(chǔ)設(shè)施依賴。OpenShift Origin在這三個方面都有大量擴展代碼。網(wǎng)絡(luò)方面早期版本的OpenShift SDN基于OVS實現(xiàn)了多租戶網(wǎng)絡(luò)隔離。這套方案的代碼復(fù)雜度很高與他CNI插件集成時調(diào)試難度明顯加大。當(dāng)前主流的做法是逐步過渡到更標(biāo)準(zhǔn)的CNI模型但如果你的團隊不熟悉OVS、流表、VXLAN這些概念僅僅理解源碼就需要耗費不少時間。存儲方面OpenShift抽象出PersistentVolume和StorageClass能力與Kubernetes原生機制保持一致但在這之上做了很多動態(tài)供應(yīng)和配額控制邏輯。認證方面OAuth、RBAC、SecurityContextConstraints組合起來安全模型很完整但也是源碼里最繞的部分。靜態(tài)評測讀這幾個模塊的時候建議放慢節(jié)奏配合文檔一起看。4.4 風(fēng)險分級表哪些能接受哪些要處理為了便于團隊決策我習(xí)慣把評測結(jié)果做成風(fēng)險分級表。這里給一個通用的模板可以直接套用風(fēng)險類別具體表現(xiàn)影響級別對應(yīng)策略依賴同步vendor體積大升級K8s依賴成本高高專人跟進上游版本建立升級演練機制結(jié)構(gòu)斷層老代碼與Operator化新架構(gòu)不一致高新開發(fā)一律參照Operator模式不繼續(xù)擴展舊結(jié)構(gòu)API演進Deprecated字段多跨版本兼容有坑中建立廢棄API追蹤清單定版本做回歸測試文檔偏差示例配置存在舊版本字段中POC配置以實際跑通為準(zhǔn)不照抄示例測試不均衡核心路徑測試多邊緣路徑覆蓋少中針對自身要用的關(guān)鍵路徑補充集成測試構(gòu)建可復(fù)現(xiàn)性部分組件版本鎖定不嚴低CI鎖定Go版本和基礎(chǔ)鏡像版本這個表只是起點每個企業(yè)要結(jié)合自己的使用場景調(diào)整。比如你把OpenShift Origin當(dāng)純Kubernetes發(fā)行版用網(wǎng)絡(luò)層風(fēng)險權(quán)重就要調(diào)高如果只為了它的模板和Build機制那API演進風(fēng)險反而是第一位。5. 源碼盡調(diào)實操記錄踩過的坑和可復(fù)用的方法5.1 環(huán)境準(zhǔn)備與克隆策略靜態(tài)評測第一個要解決的是環(huán)境問題。OpenShift Origin倉庫體量很大直接完整克隆加上歷史所有分支會占用非常多的磁盤空間。我這次的策略是只拉取指定tag的淺克隆既滿足完整源碼分析需求又避免無謂的磁盤和時間開銷。git clone --depth1 --branch release-tag https://github.com/openshift/origin.git注意不要只拉默認分支因為默認分支可能包含大量實驗代碼并不代表某個穩(wěn)定發(fā)行版。選tag時優(yōu)先選和商業(yè)版版本對應(yīng)的tag比如v3.11.0這類穩(wěn)定版本分析結(jié)果才有代表性。磁盤空間建議預(yù)留20GB以上因為解包之后的Go源碼和依賴工具會膨脹得比你預(yù)想的大。5.2 常用靜態(tài)分析命令清單這里分享一套我自己在盡調(diào)過程中反復(fù)用的命令全是常規(guī)工具沒有特殊依賴。# 1. 統(tǒng)計Go文件行數(shù)識別體量最大的模塊 find . -name *.go | xargs wc -l | sort -nr | head -30 # 2. 查找廢棄API和兼容性注釋 grep -rn Deprecated: --include*.go pkg/ | head -50 # 3. 查找TODO和FIXME評估技術(shù)債 grep -rn TODO\|FIXME --include*.go pkg/ | wc -l # 4. 識別對Kubernetes上游的直接依賴 grep -rn k8s.io/kubernetes --include*.go vendor/ | head -20 # 5. 查看導(dǎo)入依賴最重的包 grep -rh ^import --include*.go pkg/ | tr \n | sort | uniq -c | sort -nr | head -30這套命令不需要裝任何第三方掃描器卻能在半小時內(nèi)讓你對一個倉庫的規(guī)模、技術(shù)債密度、核心依賴關(guān)系有基本的認識。我開始做工程盡調(diào)這幾年來每次接手新代碼庫都會先跑一遍。5.3 我在這次盡調(diào)中踩過的坑第一個坑是IDE直接卡死。用IDE打開整個Origin倉庫會導(dǎo)致內(nèi)存暴漲索引時間長到懷疑人生。建議先把倉庫用命令行工具分析一遍然后只在IDE里打開你真正關(guān)注的模塊目錄不要全量打開。第二個坑是忽略vendor內(nèi)的Kubernetes版本。我第一遍掃的時候只看了Origin自身的代碼完全沒注意vendor里的Kubernetes是哪個版本。后來做兼容性分析時才發(fā)現(xiàn)很多OpenShift擴展邏輯是圍繞特定Kubernetes分支設(shè)計的不看vendor根本無法判斷兼容邊界。vendor不是可有可無的附屬品它本身就是工程的組成部分。第三個坑是沒有第一時間確認構(gòu)建環(huán)境。Origin對Go版本要求比較嚴格用本機默認的新版Go編譯舊版本源碼會碰到由語言標(biāo)準(zhǔn)庫行為差異導(dǎo)致的問題看起來像語法錯誤實際是工具鏈版本不匹配。解決方法是看hack/腳本里顯式聲明的版本再決定用哪個Go工具鏈。5.4 給團隊的盡調(diào)結(jié)論模板靜態(tài)盡調(diào)最后一步是輸出結(jié)論。這里分享我常用的模板結(jié)構(gòu)概述選型背景與目的、環(huán)境與口徑源碼版本、統(tǒng)計方式、規(guī)模畫像文件數(shù)、代碼行數(shù)、依賴規(guī)模、各維度質(zhì)量發(fā)現(xiàn)結(jié)構(gòu)、依賴、測試、文檔、構(gòu)建、風(fēng)險清單與分級、建議行動項。行動項一定要具體到“誰在什么時間做什么”。比如“小李在兩周內(nèi)基于廢棄API清單評估現(xiàn)有定制模塊的兼容性”比籠統(tǒng)的“需要加強升級管理”要強得多。結(jié)論部分不要用太多形容詞用數(shù)字和事實說話。我在這次評測里給團隊的關(guān)鍵結(jié)論是OpenShift Origin具備企業(yè)級底座的底子工程結(jié)構(gòu)的完整性優(yōu)于多數(shù)同類項目但跟隨上游升級的長期成本和Operator化演進帶來的結(jié)構(gòu)斷層是必須正視的現(xiàn)實問題。最后再分享點個人體會做源碼級盡調(diào)這件事最忌諱的是把“文件多”“代碼量大”直接等同于“工程強”。36669個文件既是這座工程雄厚實力的證明也是一份沉甸甸的維護負擔(dān)。真正決定一個底座靠不靠譜的不是它的體量而是它面對變化時的演進能力。靜態(tài)評測的優(yōu)勢在于它能讓你在還沒有部署任何集群之前就對將要管理的技術(shù)債務(wù)有一個足夠的心理預(yù)期。我個人在實際操作中的體會是這類評測每隔一段時間就該重做一次因為底座會變Kubernetes生態(tài)會變團隊的能力也會變。把評測做成一次性項目價值會大打折扣。留好環(huán)境、留好命令、留好統(tǒng)計口徑下次版本升級前再跑一遍對比前后差異你會比任何外部咨詢報告都更懂自己的底座。