最近的幾次關於容器使用情況的調研都得到了相似的結果，開發團隊不僅採用而且開始擁抱容器技術。大多數人並沒有像超大型組織那樣大規模的使用容器。在一項思科贊助的調研中發現有超過8000家企業在生產環境中使用容器。這聽起來令人印象深刻，但他們使用容器的規模有限。在[戴爾EMC，英特爾和紅帽委託的Forrester報告]()中，63％使用容器的企業執行的例項超過100個，82％預計到2019年會達到這一規模。這與超大型技術公司使用的數十萬的規模相距甚遠。
雖然採用率很高，這並不是說組織使用容器的道路就是一帆風順的。採納任何一樣新技術都是存在挑戰的。人們使用容器時最關心的是：網路和管理。其次才去關注安全性和不一致性。
網路挑戰是由於Kubernetes等流行的容器編排軟體所帶來的。Kubernetes構建的就是要支援微服務架構。這允許開發和運維人員將功能抽象成一組pod，並將其作為“service”暴露出來，並通過定義好的API進行訪問。Kubernetes支援DNS和基於TCP的L4負載均衡。
基於TCP L4負載均衡的問題是它無法與L7(應用程式和API層）互動。對於任何L4負載均衡都是如此；它不是容器和Kubernetes獨有的東西。L4負載均衡提供了對連線級別（TCP）協議和指標的可見性，但僅此而已。這使得很難（真的不可能）解決高階問題，例如每秒請求數或事務等L7指標以及基於路徑分割流量（路由請求）。這也意味著您無法在API層進行速率限制或支援重試和斷路等關鍵功能。
因為缺乏這些功能，開發人員就不得不將它們編碼到每個微服務中。這導致運維程式碼包含在業務邏輯中。這明顯不太合適，因為它顯然違反了微服務設計的原則。因為它為微服務增加了構建和技術債。
雖然Kubernetes特別擅長處理容器化應用程式的構建和部署，但是它缺乏在執行時監控基於微服務的應用程式所需的關鍵功能。Kubernetes只能提供基本的健康檢查存活探針和就緒探針，不能為開發和運維人員提供在執行期間快速有效地診斷問題所需的度量和追溯微服務的呼叫。讓開發人員使用微服務來生成一致的指標可能是一項重大挑戰，尤其是當他們要在限定時間內完成客戶所需功能時，這會給他們帶來很大的壓力。
而Service Mesh是解決kubernetes在網路和管理方面問題的完美解決方案。
Service Mesh如何應對挑戰
Service Mesh通過在Kubernetes的一些列pod中注入sidecar代理能夠很好的解決這些問題。通過直接注入到容器環境，sidecar代理能夠透明化網路和一致度量指標。由於所有流量都通過sidecar代理進行有效路由，因此它可以自動生成並將所需的指標提供給網格的其它部分。對於在容器環境中部署傳統應用程式的組織而言，這非常有價值。傳統應用程式不太可能適用於現代環境。使用Service Mesh及其sidecar代理基本使這些應用程式能夠產生正確的指標，而無需或很少需要新增/修改程式碼。
這也意味著您不必花時間協調由各種執行時代理生成的不同指標。您可以依靠服務網格在所有應用程式和微服務中生成一致的度量標準集合。
這些指標包含提供給網格的更高階資料點，並啟用更高階的網路以確保對請求的最快可用響應。在Service Mesh中重試和斷路器由sidecar代理處理，這減輕了開發人員將運維程式碼引入其微服務的負擔。由於sidecar代理不受限於L4負載均衡（TCP），所以靠L7負載均衡（應用程式和API層）它支援更高階別的訊息路由技術。
容器編排是一個很好的基礎設施，但企業組織需要的不僅僅是一個良好的基礎設施。他們需要能夠與堆疊上層的服務進行互動的能力，這需要使用指標和現代架構去實現。
服務網格可以很好的提供這兩種服務。當您需要超越容器編排時，請使用服務網格。
原文地址：www.servicemesher.com/blog/going-…