微軟開源Kubernetes服務網格專案Open Service Mesh
阿新 • • 發佈：2020-08-18
儘管微服務環境提供可移植性，允許更快更頻繁的部署週期，甚至還能讓組織建立關注於特定領域的團隊，但這也伴隨著對於流量管理、安全以及可觀測性等需求的增長。在整個生態系統中，針對這些需求的服務網格模式的實現方法不計其數。微軟一直活躍在 Service Mesh Interface (https://smi-spec.io/) (SMI) 社群中，協助定義一組標準可移植的 API 規範，能夠實現橫跨在不同服務網格之上的通用服務網格功能。供應商可以應用 SMI 來確保生態系統工具能夠在不同的網格上工作，同時也允許客戶選擇網格提供方。
今天我們很高興推出一個新的開源專案--Open Service Mesh (https://openservicemesh.io
我們要讓Kubernetes(www.alauda.cn)運維人員們能夠毫不費力的安裝、維護和執行 OSM；與此同時，也要讓 OSM 足夠簡單，讓整個社群都能夠理解並做出貢獻。
這些目標根植於客戶需求之中，也將我們引向三個基本的設計準則。首先，OSM 提供一個與SMI規範相容的控制平面，以此來保留使用者的選擇。其次，我們使用 Envoy 作為資料平面，因為 Envoy 具有很強的社群動力。最後，OSM 背後最重要的理念是“非陡峭（no cliffs）”設計，能夠讓 OSM 足夠靈活，在簡單或複雜的場景下都可以直接使用 SMI 和編寫 Envoy xDS API 來處理。
“很高興 OSM 能夠加入 Envoy 家族，為 Kubernetes 構建一個供應商中立的服務網格方案，並強調簡便性”。--Envoy創始人Matt Klein
OSM 簡化了許多工，諸如為通用部署方案的配置流量轉移，使用 mLTS 來保護服務到服務間通訊的安全，為服務實施細粒度的訪問控制策略，觀察用於除錯和監視服務的指標，整合本地或外部證書管理解決方案，以及使用自動的 sidecar 注入將應用載入到網格中。
很高興能與社群一起改進、開發 、學習 OSM，並與廣大 SMI 社群一同釋出 SMI 規範的進展。我們將在 KubeCon EU Virtual 2020 (https://events.linuxfoundation ... urope/) ，以及8月14日舉辦的 CNCF Webinar(https://www.cncf.io/webinars/c ... ystem/) 上展示 OSM。
1 瞭解微軟 Open Service Mesh
微軟已經發布了它的開源服務網格實現。這對 Azure 上的 Kubernetes 來說意味著什麼？
僅僅在幾年前，當我們提到基礎架構時，我們指的是物理上的基礎設施：伺服器、記憶體、磁碟、網路交換機以及所有連線它們所必須的線纜。我曾經有一些電子表格，當我構建一個可以支援成千上萬使用者的 Web 應用時，我需要向表格中鍵入某個數字，先得到我所需要的硬體規範，然後才去實施。
現在一切都改變了。首先到來的是虛擬基礎設施，它們位於那些物理機架的伺服器上。通過一組虛擬機器管理程式和軟體定義的網路與儲存，可以指定應用程式的計算要求，並在別人為我管理的物理硬體上配置應用程式及其虛擬網路。今天，在超大規模的公有云上，我們將在自動管理擴充套件(包括縱向和橫向)的編排框架上構建分散式應用。
2使用分散式網格來管理分散式應用架構
新的應用基礎設施需要屬於它們自己的基礎設施層，它必須足夠智慧，能夠響應自動擴充套件、處理負載均衡和服務發現，並仍能支援策略驅動的安全性。在微服務容器之外，你的應用基礎設施被實現為一個服務網格，每一個容器都被連結到作為 sidecar 執行的代理上。這些代理管理容器之間的通訊，允許開發團隊專注於他們的服務和託管的 API，而所有連線這些服務的服務網格由應用操作團隊管理。
一個人在應用服務網格時，或許面臨的最大問題是選擇困難症：谷歌的出名的 Istio、開源的 Linkerd、HashiCorp 的 Consul，抑或是更多的實驗性工具如 F5 的 Aspen Mesh。選擇一個已經很難，而更難的是在整個組織中標準化一個實現。
當下，如果你想通過 Azure Kubernetes Service 來使用服務網格(https://docs.microsoft.com/en- ... -about)，你得到的建議是使用 Istio、Linkerd 或是 Consul，在 AKS 文件中都有它們的相關說明。這並不是最簡單的方法，因為你需要一個獨立的虛擬機器來管理服務網格，同時還需要一個執行在 AKS 上的 Kubernetes 叢集。然而，另一個還在開發中的方法是 Service Mesh Interface (https://smi-spec.io/) (SMI), 它提供一組連線 Kubernetes 到服務網格的標準介面。Azure 已經支援 SMI 有一段時間了，因為其Kubernetes團隊一直領導著 SMI 的開發。
3 SMI: 一組通用服務網格 API
和 Kuebernetes (www.alauda.cn)一樣, SMI 也是一個 CNCF 專案，儘管當前只是一個sandbox專案。處於沙箱意味著它尚未被視為穩定，隨著 CNCF 開發計劃的各個階段，它的前景將發生重大變化。當然，雲廠商和 Kubernetes 供應商以及贊助其開發的其他服務網格專案也提供了大量支援。SMI 旨在為 Kubernetes 提供一組基本 API，以便連線到符合 SMI 的服務網格。因此你的指令碼和運維人員可以使用任何的服務網格；沒有必要被鎖定在單個提供方。
作為一組自定義的資源定義和擴充套件 API 伺服器，SMI 可安裝在任何經過認證的 Kubernetes 發行版上，如 AKS。一旦應用到位，你可以使用熟悉的工具和技術來定義應用程式和服務網格之間的連線。SMI 會使應用程式具有可移植性；你可以使用 SMI 在本地的 Kubernetes 例項上開發，並可以將任何應用程式轉移到一個託管有符合 SMI 規範的服務網格的 Kubernetes 上，且無需擔心相容性。
有一點很重要，SMI 本身並不是一個服務網格；它是一個規範，服務網格需要實現它來獲得一組通用的功能特性。沒有什麼能阻止服務網格新增屬於自己的擴充套件和介面，但是它們需要足夠引人注目才會被應用程式和應用運維團隊使用。SMI 背後的開發者們也聲稱他們並不反感將新的功能遷移到 SMI 規範中，因為服務網格的定義在不斷髮展，那些預期功能也在不斷改變。
4 Open Service Mesh：微軟開發的 SMI 實現
微軟最近釋出了它的第一個 Kubernetes 服務網格 (https://openservicemesh.io/)，它基於微軟在 SMI 社群的成果之上。Open Service Mesh 是一個符合 SMI 規範的、輕量的服務網格，它是一個託管於 Github (https://github.com/openservicemesh/osm) 的開源專案。微軟希望 OSM 成為一個社群主導的專案，並打算儘早將其捐贈給 CNCF。你可以視 OSM 為一個基於現有服務網格元件和概念的 SMI 參考實現。
儘管微軟並沒有明確表態，但在 OSM 的宣告和文件中，有一條它在Azure上使用服務網格的經驗，它們重點關注的是與運維相關的東西 (https://github.com/openservice ... IGN.md)。在最初的部落格 (https://openservicemesh.io/blo ... -mesh/)中， Michelle Noorali 描述 OSM 為 “讓Kubernetes 運營人員毫不費力的安裝、維護和執行”。那是一個明智的決定。OSM 是供應商中立的，但是它很有可能成為 AKS 的眾多服務網格選項之一，因此易於安裝和管理將是推動人們接受它的一個重要因素。
OSM 基於其他服務網格專案的成果之上。儘管它擁有自己的控制平面，但是它的資料平面基於 Envoy。同樣，這是一個務實且明智的辦法。SMI 是關於如何控制和管理服務網格例項的，因此使用大家熟悉的 Envoy 來處理策略將允許 OSM 在現有的功能上構建，這減少了學習曲線，同時也讓應用程式運營人員能跨過有限的 SMI 功能集，在必要的情況下使用更復雜的 Envoy 的特性。
目前 OSM 實現了一組通用服務網格特性。這些包括支援流量轉移、保護服務到服務的連線、應用訪問控制策略和處理服務的可觀測性。通過自動部署 Envoy sidecar 代理，OSM 會自動新增新的應用和服務到網格中。
5 部署和使用 OSM
想要開始嘗試 OSM alpha 版本 (https://github.com/openservice ... ide.md)，可以在專案的 Github Release (https://github.com/openservicemesh/osm/releases) 頁面上下載它的命令列工具
osm。當執行osm install時，它會以預設的名稱空間和網格名稱把 OSM 控制平面新增到 Kubernetes 叢集中。你可以在安裝過程中進行修改。安裝並執行 OSM 後，可以向網格中新增服務 (https://github.com/openservice ... ces.md)，使用策略定義來新增 Kubernetes 名稱空間，以及自動將 sidecar 代理新增到託管的名稱空間下的所有pod中。這些步驟將實現你選擇的策略，因此在開始部署前就設計好一組 SMI 策略將會是一個不錯的主意。OSM Github repo 上的策略樣例將會給你幫助。OSM 中包含了 Prometheus 監控工具包和 Grafana 視覺化工具 (https://github.com/openservice ... ity.md)，因此你可以快速檢視服務網格和 Kubernetes 應用的執行情況。
Kubernetes(www.alauda.cn)在現代雲原生應用中是一個重要的基礎設施元素，因此我們要開始重視它。這要求你將它同執行在它之上的應用獨立開來進行管理。AKS、OSM、Git 和 Azure Arc 的組合成為管理 Kubernetes 應用環境的基礎配置。應用基礎架構團隊管理 AKS 和 OSM，為應用和服務設定策略，與此同時， Git 和 Arc 將通過 OSM 的視覺化工具傳遞的實時應用指標來控制應用的開發和部署。
這些元素完全融合還需要一段時間，但很明確微軟正在為分散式應用管理及其必要的工具做出重要的承諾。現在就動手吧，使用這個套件的基礎元素 AKS，並新增上 OSM 和 Arc。你現在就可以在 Azure 上構建和部署 Kubernetes，使用 Envoy 作為服務網格，同時在實驗室中使用 OSM 和 Arc 進行原型設計，為適合生產的時機做好準備。這不會需要等待很久。