思科開原專案 讓 K8s 應用在 SD-WAN 上跑得更快
思科本周啟動一項 Cloud-Native SD-WAN 開原碼專案,旨在最佳化 SD-WAN 上 Kubernetes 應用程式的執行效能。思科指出,這項專案可示範如何將 Kubernetes 應用程式自動化對應到 SD-WAN 上,產出比 WAN 上更優異的應用效能。
K8s 應用如同在 SD-WAN 海洋上摸黑行船
思科意圖網路事業群副總裁暨技術長 John Apostolopoulos 指出,企業經常為了支援雲端原生應用而部署 SD-WAN 連向 Kubernetes 叢集。一般企業的 NetOps 部門運用其網路的了解來規劃 SD-WAN 政策,以最佳化代管 Kubernetes 應用的連線速度,希望能降低延遲性及封包遺失的狀況。另一方面則要 DevOps 團隊維護和最佳化 Kubernetes 基礎架構。但是即便 DevOps 和 NetOps 團隊再努力,今天 Kubernetes 和 SD-WAN 的運行好像在夜裏行船,都看不見對方。而 SD-WAN 和 Kubernetes 的整合需要兩個團隊花很多時間磨合與合作。
現今 SD-WAN 提供 API 讓客戶得以決定 WAN 上如何管理流量,為自動化和應用最佳化提供很好的契機,思科相信這是統合 Kubernetes 宣告本質和現代 SD-WAN 程式化本質的好機會。
CN-WAN 讓 K8s 看得見 SD-WAN
而這就需要 Cloud Native WAN(CN-WAN),因為它定義可用於整合 SD-WAN 套件(如思科 Viptela SD-WAN)的一組元件。而 Kubernetes 則讓 DevOps 團隊表達在 Kubernetes 叢集上部署微服務時的 WAN 需求,同時又讓 NetOps 團隊自動描繪 (render) 微服務需求,達到在 WAN 上最佳化應用效能的目的。
Apostolopoulos 解釋,CN-WAN 包含 Kubernetes Operator、Reader 及 Adaptor。其運作如下:CN-WAN Operator 跑在 Kubernetes 叢集內,負責管理部署好的服務。DevOps 團隊可利用服務上的標準化 Kubernetes 註解 (annotation) 來定義 WAN 相關的 metadata,例如應用程式的流量描述 (profile)。之後由 CN-WAN Operator 自動將服務連同 metadata 登錄到服務儲存庫 (service registry)。本周在 KubCon EU 大會上的示範中,思科是以 Google Service Directory 作為服務儲存庫。
今年 4 月思科和 Google 強化合作,聯合開發一個 turnkey package,稱為 Cisco SD-WAN Cloud Hub with Google Cloud,讓客戶可協調管理 SD-WAN 和資料中心、Google Cloud、其他公有雲的應用、或是 SaaS。這個平台也可整合 Google 軟體定義的骨幹和思科的 SD-WAN 政策、遙測資料 (telemetry) 和安全設定,確保應用的 SLA、安全及政策遵循,擴大到整個網路。
回到 CN-WAN 上。CN-WAN Reader 可連到服務儲存庫以了解 Kubernetes 如何向 WAN 曝露服務,相關的 WAN metadata 又如何由 CN-WAN operator 蒐集。當偵測到新或更新的服務,或是有 metadata 時,CN-WAN Reader 就會傳送訊息給 CN-WAN Adaptor,由此更新 SD-WAN 政策。
最後,CN-WAN Adaptor 會將服務相關的 metadata 比對到 SD-WAN 控制器中,由 NetOps 撰寫的 SD-WAN 政策。SD-WAN 控制器會按照不同 metadata 型態自動描繪 (render) SD-WAN 政策,以實現服務的 SD-WAN 資料平面 (data-plane) 最佳化。
Apostolopoulos 指出,SD-WAN 可支援多種型態的傳送和接收存取連線(有線網路、MPLS、4G 或 5G),以及多種服務選項,並按存取網路提供優先性排序,當然也支援來源和目的地之間的各種路徑。