吳明宜思科開原專案 讓 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），以及多種服務選項，並按存取網路提供優先性排序，當然也支援來源和目的地之間的各種路徑。