靈雀雲出席騰訊Techo開發者大會，揭祕靈雀雲開源實踐

11月6日，騰訊Techo開發者大會在北京召開，開源做爲與大會緊密關聯的新關鍵詞，貫穿會議始終。靈雀雲DevOps研發負責人Daniel在雲原生技術實踐會場應邀作了「靈雀云云原生產品實踐之路」的主題演講。他結合靈雀雲的發展歷程和產品經驗分享了靈雀雲自身的雲原生之路，尤爲是圍繞Kubernetes管理網絡和Helm分發改進的開源項目實踐。

靈雀雲五年雲原生之路

他總結指出，靈雀雲的代碼交付方式經歷了從以前最先的源代碼、容器鏡像、Kubernetes  yaml，到現在的Chart方式。靈雀雲業務最先以提供公有云容器爲主，前後發展爲提供多集羣、私有PaaS平臺到如今的私有云原生PaaS平臺。交付流程自己也有很大的變化：從最先期的構建，衍變成持續集成、CICD，到目前的DevOps集成。

2016年，靈雀雲開始將整個產品包在容器裏面去部署，交付頻率能達到每週2次部署，每次1小時，迭代過程相較於以前基於單體應用提高50%。此時也是靈雀雲開始普遍接觸企業客戶的起始點，靈雀雲發現客戶維護龐大複雜的單體應用很是困難，發佈、合併代碼等都面臨諸多問題。所以開始容器微服務化自身的產品，同時將產品部署和維護到多個環境中。

2017年Kubernetes技術成爲主流，靈雀雲產品開始微服務化。在測試方面，除了手工測試，持續集成的邏輯出現。Daniel介紹到，部署頻率可以實現每週上線10次，每次10分鐘。此時在業務層面開始作私有部署，產品團隊須要不斷思考此前依賴公有云服務的產品，在私有云環境中如何實現，這些給產品的思路帶來很是大的影響。

2018年隨着數字化轉型的進程，更多的客戶和研發團隊產品迭代過程開始發生變化，須要找到更好的替代產品。同時，迴歸測試佔據了測試人員的大部分時間，須要提高交互能力和速度。並且此時，Kubernetes已成爲容器編排的事實標準，靈雀雲開始深刻了解Kubernetes自己的設計理念和擴張機制，積極重視Istio、Service Mesh服務網格等技術，並研發了獨立的Service Mesh產品。

今年，靈雀雲又進行了產品架構的重大升級，全部產品架構變成基於Kubernetes的原生架構。在交互部分，擁有了很是典型的交互方案。在流程裏面，自動化測試變成須要在研發過程當中完成的一部分。每次發佈一個新的功能，對應的自動化測試也已經存在，合併以後變成迴歸測試的一部分。交付升級到天天發佈50次，每次5分鐘。

要快速迭代，快速驗證自身業務，靈雀雲會提供相關的產品和工具幫助客戶快速落地。

當引入至關的微服務以後，企業一般會面臨另外的問題，即微服務治理。由於微服務架構的本質是以運維的複雜度爲代價來換取敏捷性。微服務治理須要完整的基礎設施去支撐。爲此靈雀雲也會針對不斷出現的客戶需求和問題，開發產品層面的解決方案。今年即新推出了API層面的新產品——企業級API管理平臺Alauda API Management platform（AMP），幫助以穩態業務佔大比例的傳統企業客戶進行雲原生應用架構的落地。

Kube-OVN & Captain  兩大開源項目實踐

隨後Daniel講述了在Kubernetes管理過程當中，靈雀雲踩過的一些坑，及由此引出的相關探索和項目實踐。

 

他表示，Helm是靈雀雲核心的迭代工具，Helm的準確率相當重要。若是自動化多了，任何數據都會變成複雜的問題。升級是開發過程的平常操做，任何新的迭代都須要升級到不一樣的環境裏。靈雀雲在此中遇到的問題是，除更新組件外，不少時候應用自己須要調整，chart改動沒法保證平滑升級，或者chart刪除組件式沒法自動清理。更改時會出現，要麼可能更改失敗，要麼會有垃圾數據存在。

Helm 2 自己存在一些問題，如沒有使用Kubernetes框架、Release 跟 Tiller 綁定、資源容易衝突、CRD/Hook 設計等。所以當Helm 3設計出來後，靈雀雲研發了Captain項目，是一個基於Helm v3標準的Kubernetes Controller，對Helm應用分發進行改進。由此來應對前述Helm存在的問題。

Captain幫助用戶簡化Helm資源描述，更便捷、高效地實現Kubernetes應用的管理和控制，推動Helm項目向原生 Kubernetes邁進的步伐。相較Helm官方，Captain的優點在於：Helm v3 變成 CLI 工具，Captain 除了kubectl插件還提供Kubernetes 的 Controller 模式，相關的資源變成 CRD，能夠在Kubernetes管理。

另外一重要開源項目Kube—OVN，解決的是OVN網絡和Kubernetes集成的問題。做爲私有化雲平臺總會遇到一些特殊的網絡方面的要求。Kube-OVN提供了大量網絡功能，並在原有基礎進行加強。經過將OpenStack領域成熟的網絡功能平移到Kubernetes，來對應企業應用合規性要求。OVN網絡架構支持企業級應用網絡場景和要求：

統一網絡的數據面，包括Pod 網絡，Service，DNS，NetworkPolicy等；覆蓋全部已知開源網絡插件的功能（固定IP，QoS，IP 暴露，網絡加密，UI……）；平移 OpenStack 的網絡設計概念到 Kubernetes（VPC，Subnet，Multi-Tenancy）；儘量的易於使用，安裝條件，默認配置，默認功能，監控工具。

他最後強調，目前兩大開源項目均已展開使用，歡迎你們試用，同時給出您的反饋。