開發者故事：基於 KubeSphere LuBan 架構打造下一代雲交付平臺

kubesphere發表於2024-10-16

前言

在 KubeSphere Marketplace，個人開發者的創意和才能正在逐漸嶄露頭角。今日，我們榮幸地向大家介紹 Shipper 雲交付平臺的開發者——凌波，一位雲原生領域的資深專家。

凌波巧妙融合 KubeSphere 平臺的特性，透過原生適配的精湛技藝，匠心獨運地打造了 Shipper 平臺。現在，讓我們一同走進凌波的開發世界，聆聽他在開發過程中的寶貴心得與獨特體會。我們期待，凌波的故事能夠激勵更多開發者在 KubeSphere 平臺上展現才華，共同推動雲原生技術的創新與發展。

開發者簡介

暱稱：凌波（lingbohome）
郵箱：lingbo@lingbohome.com
部落格: https://www.lingbohome.com/
GitHub 主頁：https://github.com/lingbohome
簡介: 曾在 HIT 公司負責容器雲平臺設計研發及信創適配工作，對雲原生相關領域技術懷有濃厚的興趣，同時也會沉澱一些自己的思考和想法，有多年的雲原生 devops 平臺設計開發經驗，K8s 容器雲平臺設計開發經驗。

創作背景

雲交付（Shipper），這一面向未來的雲原生構建與交付平臺，是我多年雲原生 DevOps 經驗與獨到思考的結晶。它最初以 K8s 為基礎，構建了一個功能強大的容器雲平臺。然而，當 KubeSphere v4 這一全新版本釋出，其分散式雲原生可擴充套件開放架構，尤其是 KubeSphere LuBan 架構所展現的雲原生微核心與可熱插拔擴充套件元件理念，瞬間吸引了我的注意。這一架構不僅與我在雲原生領域的諸多思考不謀而合，更激發了我將理論付諸實踐的強烈願望。

在深入瞭解了 KubeSphere v4 後，我意識到，這不僅僅是一個堆砌功能的容器雲平臺，而是一個具有革命性意義的架構創新。因此，我決定將雲交付（Shipper）以擴充套件元件的形式，適配到 KubeSphere LuBan 架構上，並透過 KubeSphere Marketplace，讓更多使用者能夠輕鬆體驗與使用它。

在適配過程中，我最初考慮採用 iframe 嵌入的方式，以節省開發時間。然而，在仔細研究了幾個以 iframe 整合的元件後，我發現這種方式雖然簡單，但擴充套件元件與 KubeSphere 主體之間的割裂感卻十分明顯，不利於後續的可持續迭代和推廣。

為了追求更好的融合效果和使用者沉浸式體驗，我最終決定採用原生適配的方式，將雲交付（Shipper）的設計基於 KubeSphere LuBan 架構重新開發。雖然這一決定意味著更大的工作量，但我相信，只有透過這樣的方式，才能真正實現雲交付（Shipper）與 KubeSphere 的完美融合，為使用者帶來更加出色的體驗。在未來的日子裡，我會持續迭代分多個版本完成適配，並不斷改進和實現更好的想法和設計。

雲交付（Shipper）簡介

雲交付（Shipper），是面向未來的雲原生構建與交付平臺，基於平臺工程理念自助式、開箱即用的雲原生 DevOps 平臺，致力於讓雲原生應用的構建與交付，變得更簡單、更高效，同時賦能產研、交付運維一體化高效協作，助力企業產品的業務價值快速高質量的交付給客戶。

主要特性：

高度靈活易用易擴充套件的構建器，開箱即用，無需任何配置
社群驅動共建豐富生態，共享可重用、功能多樣性的模板
平臺內建預設模板倉庫，由平臺驅動維護，不定期更新和上線更多實用模板
高效協作，關注點分離，產研團隊使用模板完成自己的需求，運維架構團隊提供不同自定義模板功能的支援
支援觸發器，輕鬆與第三方系統整合及構建器之間的聯動，支援 cron 表示式定時執行
多型別製品管理，支援文字型別製品線上預覽
基於平臺工程理念的自服務式應用全生命週期管理，包括但不限於（版本化，釋出，部署、運維，監控，打包交付），無需瞭解底層技術細節，即可輕鬆交付業務價值，減輕使用者的使用負擔
基於 KubeSphere 天生的多雲多租戶能力，團隊之間資源隔離，互不干擾
管理端全域性效能洞察看板，提供分析各維度效能度量資料、成本分析資料
支援面向 toB 行業的交付能力，解決 toB 產品交付痛點，降低 toB 產品交付成本
信創支援能力，助力企業高效高質量交付信創應用

搭建環境

我的開發環境搭建相對還是比較輕鬆的，因為在騰訊雲上有一臺測試用的單機 K8s 環境，直接透過官方文件中的 helmchart 命令一鍵部署了 KubeSphere，然後還需要在本地安裝 create-ks-project
和 ksbuilder,分別用於初始化擴充套件元件前端工程目錄和打包、釋出擴充套件元件，後端擴充套件的話，就比較靈活了，不需要安裝 KubeSphere 特定的相關開發工具，我這裡後端是以 APIService 和 crd 的形式擴充套件的，最後打包擴充套件元件的時候，將後端註冊到相應的 APIService 中就可以了，其它的額外的開發工具，按照平常的開發需求，按需安裝即可。

如果你也在尋找一個高效、便捷的開發環境搭建方案，那麼我強烈推薦你試試 KubeSphere Cloud 的輕量級叢集。它能夠秒級拉起整個叢集環境和 KubeSphere，讓你輕鬆享受省時省力的開發體驗。

開發過程

KubeSphere 的擴充套件元件開發跟平時的開發流程和方式沒什麼太大區別，只是前端按照 KubeSphere 提供的一套元件庫（Kube Design）來開發，同時 KubeSphere 還提供了許多擴充套件元件開發示例，可以參考官方給的這個 extension-samples 這個程式碼倉庫，有了這些例子後，上手也就更快了，可以減輕不少開發負擔。

前面提到，我的本地開發環境是連線的雲上面的遠端叢集，這對本地前後端聯調不是很友好，為了解決這個痛點，我這裡使用了一個比較簡單且不用額外工具的方案，大家可以視自己的實際情況參考：

透過 SSH 配置本地隧道埠轉發，來進行本地聯調，具體如下：

# 語法
ssh -NfR ${公網埠}:${本地地址}:${本地埠} ${公網伺服器使用者名稱}@${公網伺服器地址}
# 示例
# 假設需要將本地localhost的5000埠對映到遠端主機的5300埠,則使用下面的命令
ssh -NfR 5300:localhost:5000 user@10.13.0.6
# 然後就可以在遠端伺服器上透過127.0.0.1:5300訪問到本地的localhost:5000後端服務了

這樣配置後還不夠，還需要將你的後端服務透過 APIService 註冊到 KubeSphere ，具體如下：

apiVersion: extensions.kubesphere.io/v1alpha1
kind: APIService
metadata:
  name: v1alpha1.resource.lingbohome.com
spec:
  group: resource.lingbohome.com
  version: v1alpha1                                      
  url: http://10.0.16.3:7500
status:
  state: Available

最後再遠端主機上啟動一個監聽在 7500 埠的 nginx 服務，來反代到 127.0.0.1:5300。


    server {
        listen 7500 default backlog=8192;

        location / {
            proxy_pass http://127.0.0.1:5300/;
            client_max_body_size 2050m;
            proxy_buffer_size 128k;
            proxy_buffers 4 256k;
        }
    }

現在就可以透過 KubeSphere 控制檯本地前端聯調，訪問到本地的 localhost:5000 後端了。

建議

前端擴充套件打包後，會在擴充套件元件原始碼目錄 extensions/<extensionName>/dist 下會生成 index.js 檔案，KubeSphere 提供了多種方式來託管index.js 檔案，有 configmap、secret、service，因為打包後index.js 檔案內容比較長且格式是緊湊的，將其儲存到 configmap 和 secret 中，很容易因為格式問題導致錯誤，而且 index.js內容有更新時再次修改 configmap 或者 secret 也麻煩，所以這裡強烈推薦使用 service 的方式，將其index.js 檔案打包到容器映象中，最後透過 deployment 部署起來，後續有更新改映象 tag 或者覆蓋之前的映象就行了。