從之前的容器到當前熱門的Kubernetes、Serverless、微服務等，新技術的每一次出現，都是一場關于效率提升的革命，而效率通常包括了開發效率、運維效率和運營效率等。如果說Kubernetes專注提升容器集群的運維管理效率，那么Serverless則從根源上擺脫服務器的運維難題，使計算資源作為服務而不是服務器的概念出現，從而將開發人員的效率最大化。為了幫助企業更高效率部署業務，更快實現持續交付、灰度發布、應用編排等訴求，5月28日UCloud TIC（北京站）“云上效率提升”技術專場，來自 UCloud的四位資深技術專家圍繞該主題進行了深入的技術探討和實踐案例分享。

基于Kubernetes構建容器云平臺的實踐

基于Kubernetes自動化部署、彈性伸縮和容器化等特性，UCloud針對內部研發人員和外部用戶分別構建了容器云平臺，UCloud實驗室負責人葉理燈在會上分享了這兩套容器云平臺的技術實踐原理。

?

UCloud內部容器云平臺（簡稱KUN）的底層是基于Kubernetes搭建的，主要的實現方法之一是K8S+Docker，通過Docker提高運維部署效率和運維環境的一致性，通過K8S實現跨可用區容災和AutoScaling能力，從而實現高可用、在線升級、自動擴縮、負載均衡、日志查看、資源監控等多種功能。

圖：內部云平臺的架構圖

葉理燈提到，在構建內部容器云平臺KUN的過程中要解決四個主要問題:1.多租戶隔離的問題，保證業務之間互相不受干擾；2.IPv6的問題，如何保證跟IPv4網絡兼容；3.如何用Operator來管理有狀態的服務；4.監控問題。

對應的解決方案分別是：

1.基于RBAC來實現賬號管理隔離，選擇Token認證方式，通過服務賬號SA（Service Account）模擬普通用戶User，所有模擬賬號的SA放置同?個NS，進行統?管理；定制權限組ClusterRole，通過授予模擬賬號SA的不同權限組，來控制不同User在NS中的不同權限。抽象Project對象給User使用，Project與每個集群的NS??對應，User在每個集群上都有對應模擬賬號用于NS授權。

2.針對IPv6的問題，接入6to4 Tunnel和Bridge網橋，核心基礎網絡無需修改，采用underlay，實現Pod與集群外部互通。Service全網可訪問，ClusterIP在K8S集群外部可以直接訪問，分配一個Ipv4地址，在Kubernetes集群下的所有介入交換機上宣告，該IPv4地址對應的6to4地址作為該Kubernetes集群ServiceIP地址段。Pod返回的包，會先回給Service Gatevay，由于做了SNAT，基于連接追蹤（conntrack），再返回給請求的客戶端。

3.在KUN中使用Operator，為用戶提供可視化 Web 操作頁面，簡化對各類自定義資源的管理操作。 用戶不需要詳細理解具體的 CRD 結構，就可以在Web 頁面上快速創建?個 Redis 集群，并且可以看到集群?步步創建的過程。同時還可以對集群進行配置更新、刪除等操作。

4.監控系統方案基于Prometheus構建，Prometheus部署于K8S集群中，使用HostPath存儲數據、Metrics采集，使用Alert Manager 聚合報警，調用 Monitor Manager 提供的 Web Hook；自研 Monitor Manager：使用Grafana 實現 Web 可視化；

而UK8S是基于Kubernetes的對外部用戶的容器管理服務，用戶可以在UK8S上部署、管理、擴展容器化應用，而無需關心Kubernetes集群自身的搭建及維護等運維類工作。除此之外，UK8S還完全兼容原生的KubernetesAPI、以UCloud私有網絡為基礎，并整合了ULB、UDisk、EIP、VPC等云產品。

?

UK8S集群網絡通過自研CNI插件與VPC網絡深度集成、利用Secondary IP API實現IP管理、無overlay性能與云主機一致、Pod網絡可與物理云托管云直接互通。

最后，葉理燈總結了UK8S管理服務的特點如下：

??? A、完全的容器化和微服務化。

??? B、所有管理服務全部運行在K8S上。

??? C、基于K8S的API對服務模塊進行動態管理。

??? D、一個集群對應生成一個watcher，容易進行橫向擴展。

??? E、基于watcher+redis緩存的方式，保證用戶在控制臺獲取集群信息的速度足夠快。

利用StepFlow快速可視化的構建新業務

開發人員在構建應用服務的時候通常會寫很多業務邏輯，還需要調用大量API或者服務接口，這個過程會出現很多問題，比如要寫很多代碼才能要調用這些API、某個功能開發完成后還需要后期維護。開發完成之后還要進行發布，除了本地去編寫代碼、調試，發布上線還要申請物理資源，中間可能還需要各個團隊的協作，整個流程非常長。

?

UCloud技術總監蒙曉凈說到：“以上這些問題其實都屬于在研發過程中產生的隱性成本，那么有沒有一種產品能夠讓我們解決上面的這些問題？用可視化的頁面，比如畫一個流程圖把我的想法表達出來，把流程圖轉換后立刻實現所要的業務功能。”答案是StepFlow產品，它是一個通過可視化的方式去編排API和微服務的服務平臺，應用開發的時候可以在不寫代碼的情況下完成新的功能的組裝、新的服務接口的發布。

?

為幫助大家進一步了解StepFlow如何快速構建業務，蒙曉凈介紹了四個應用場景：

1.? 實現一個串行流程。這個場景的案例來自于愛普新媒體，在使用USQL進行數據分析之后，希望把這個分析結果導入到數據庫里面進行二次保存，在導入完成后可以發一個短信給相關的人員通知任務完成或者失敗。在這個過程中愛普新媒體用到了很多USQL、UFile、StepFlow、UDTS、短信包、數據庫等產品，而StepFlow在這里相當于起到中樞的作用，把各個產品關聯到一起。

2.? 實現一個并行的流程，這里舉一個UMedia媒體工廠的產品使用場景，它的功能是對視頻做各種處理，通常需要在一個視頻文件上傳到UFile之后，對它做多個視頻處理任務，例如多種格式轉換、打水印、截圖等等。在這個場景中StepFlow把UFile、UMedia關聯到了一起，更關鍵的是它不僅局限于UCloud的產品，StepFlow還能夠與用戶自己的業務服務進行交互關聯，調用第三方的Http，提供了極大的業務想象空間。

3.? 實現調用子工作流，已創建的工作流能夠變成子工作流，被其他工作流調用。類似于各種編程語言中標準庫提供的公共函數，或是業務框架自行封裝的函數；可以提前構造常用的公共流程，方便使用。

4.如何更新業務&快速發布？這里StepFlow是通過多版本管理的方式來解決這個問題。例如當前正式業務使用的是版本V1，如果要對V1進行修改，我們可以基于V1新增一個步驟NewStep并保存，只要是僅保存不發布，正常的流量是不會流入的。通過這樣的方式也可以確保流程編輯不會影響正式的業務。然后通過指定版本的方式進行調試，最后確認無誤后再進行發布。以這樣的多版本功能還可以實現類似灰度控制的方案。

圖：傳統研發路徑和StepFlow流程對比

大家可以看到，在以上四個場景實現的整個過程中我們并沒有申請任何物理資源，甚至也不需要關心底下的物理資源使用情況怎么樣，這充分表明了StepFlow本質上是一個Serverless的服務，這些事情都是StepFlow服務在后端進行動態的管理和調度的。同時，在這樣的前提下，用戶就可以集中更多精力在自己的業務上，優化自己的產品，從而獲得更大的價值。

基于Serverless的數據湖分析引擎USQL實戰

“我曾經作為一線的大數據開發工程師，經歷過很多諸如組件版本沖突、維度膨脹、硬件故障、臟數據、集群更換、數據丟失等問題，經常半夜三四點爬起來加班進行數據排測的工作。為了解決這些困擾，我加入UCloud之后希望做出的大數據產品具備成本低、分析簡單、無需運維三大特點。”UCloud產品總監張曉康說到。用戶都希望數據創造的價值越大越好，而相關的成本投入能夠趨于收斂，因此2018年10月份UCloud發布了一款基于Serverless的SQL分析計算引擎USQL(數據湖分析)，企業無需數據庫管理員和運維人員即可完成面向海量數據的數據建模、SQL數據查詢分析等工作。

舉一個案例：愛普新媒體每天的數據日增量是300G、總量120T，每天運行50個Hive SQL實例， 大數據團隊4-5個人，每年150萬的人力投入。設備上的成本每年折舊下來大概是60萬，托管費用大概每年30萬，最終計算下來的結果是131.5元/SQL。針對這個場景，UCloud幫助用戶利用對象存儲UFile優化存儲成本，再通過USQL節省計算成本。“我們將Kafka存儲規模龐大的全量原始廣告日志數據放到UFile，無需加載數據，直接通過SQL分析UFile數據再交給USQL，研發人力投入為0,大數據消費降低了92.85%，需求完成周期從原來的43.2小時降低到2小時。”愛普新媒體CTO牛德恒總結到。

在數據探索場景，普遍存在的問題有數據格式不固定、數據規模大、沒有元數據、分析目標不明確等，USQL由于支持豐富的數據格式、計算與存儲分離、元數據與數據分離、快速SQL分析等特性占據了絕對的優勢。未來，UQSL產品將持續完善新的功能，例如支持JDBC的驅動、數據加密——協同UKMS（密鑰管理服務）、CREATETABLE AS SELECT（CTAS）等。

云主機并發創建優化實例及用戶價值

不同行業的客戶可能對云主機并發創建都有需求，最常見的場景有電商大促、動畫渲染、營銷活動、教育培訓等。在這些場景下，用戶往往需要用盡可能短的時間創建上百臺甚至上萬臺云主機來應對業務的高峰期。UCloud資深研發工程師齊良在現場分享了云主機并發創建的后臺優化實踐方案。

?

針對本地盤主機，虛擬機鏡像從鏡像倉庫復制到宿主機再拷貝到虛擬機大概需要300秒，如果我們將鏡像文件提前部署到宿主機上，那么從宿主機上拷貝鏡像到虛擬機的時間就只需要30秒，這個方案在UCloud早期機房規模不是很大的時候還能適用。但到后期顯然不行，因此UCloud開發了BlockStreaming技術，從而使單臺云主機的創建時間小于10秒。

?

針對云盤主機的開機需要鏡像完全復制、復制時間長、鏡像倉庫帶寬瓶頸問題，UCloud研發了Koala鏡像系統，實現了鏡像分片存儲、并發拷貝，有效的解決了由于復制導致開機時間長的問題，最終使得單臺云主機創建時間小于15秒。如果要進行批量創建，我們采取的方案是鏡像分片在UDisk內部進行P2P分發、同?個鏡像只從Koala復制?次 、UDisk只緩存熱門鏡像，最后的效果是平均單臺創建時間6s秒100臺耗時10分鐘。然而這個時間還是不能夠滿足很多用戶的需求，于是我們進一步優化的手段是異步返回、并發申請資源、優化IP地址申請，最后100臺耗時約5分鐘；如果在批量創建100臺云主機的代碼中采用批量創建API接口可能耗時只需要2分鐘，用戶看到的可能只是改了API接口，但這只是背后復雜邏輯的冰山一角。

?

由于Koala鏡像系統的限制是24臺物理機、1000M網口、云主機拉取鏡像20Mbps，我們經過計算這個系統最大只能支持150臺并發創建。如果要實現同時創建1萬臺云主機，就需要提前預約資源、利用空閑資源加速創建 、突破Koala系統?網絡瓶頸，基于這個想法我們又開發了鏡像Cache系統。鏡像Cache系統里面的空閑資源是成千上萬的，可以假設這種帶寬是沒有限制的，基本就可以解決Koala鏡像系統的帶寬問題。

齊良最后補充說：“后臺做了這么多的優化之后，導致最終的系統也非常復雜，出問題的概率會比較大。為了保證系統的穩定性，我們需要對系統進行改造，要把這個系統做的足夠簡單，包括建造周期要短，調度和鏡像拉取的邏輯也要更簡單。最終體現在架構上就是關鍵路徑要短、核心邏輯要簡單、非核心服務可插拔以及兜底策略。”

?

關于本次技術專場的更多演講內容，歡迎關注“UCloud技術”公眾號回復“TIC”獲取講師PPT。

總結

以上是生活随笔為你收集整理的云上效率提升指南 | K8S和Serverless还能这么玩的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。