大家知道，“服務網格”是當下科技行業的熱門話題 ，Istio就是這一領域最流行的項目之一。Istio 由 IBM、谷歌和 Lyft 聯合開發，用來解決當下微服務架構面臨的眾多問題。容器和 Kubernetes 的流行使微服務架構得到了廣泛應用，但與此同時它們也帶來了一系列全新的問題和挑戰。

如今，我們所有的服務都在使用 HTTP/gRPC API 來互相通信。在傳統的單體架構時代，這些通信只是在單個應用內部傳遞的函數調用而已。相比而言，在微服務體系中不同服務之間存在著大量的交互，更難觀察、保護和監控。

現在，已經有很多資料介紹Istio 的概況及其工作原理，這裡我不再贅述。本文將著重討論一個話題，也就是監控。Istio 的官方文檔談到了這方面的內容，但我花了不少時間才搞清楚它是怎麼回事。所以我會在這篇教程中帶你瀏覽一遍相關內容，這樣你就能更好地理解如何使用 Istio 來監控任務了。

現狀

選擇服務網格（mesh）的主要目的之一是提高可觀察性。直到現在，開發者都需要在自己的應用中插入諸如公共庫或者New Relic或Datalog這樣的代理服務，從而暴露一系列指標數據；這樣一來，運營就能使用監控解決方案來獲取應用的終端節點指標，從而知曉系統的運行狀態。但為此不得不修改代碼實在很麻煩，尤其是改動或新增內容較多時更讓人痛苦不堪。另外多個團隊都使用這種方式做監控時，代碼維護也會變得很困難。

Istio 的做法是在無需改動任何代碼的前提下暴露並追蹤應用行為。這是通過所謂“邊車（sidecar）”的概念實現的，它是一個與我們的應用共同運行，並向中央遙測組件提供數據的容器。邊車能夠識別應用正在使用的協議（redis、mongo、http、grpc 等），從而嗅探出與數據請求相關的大量信息。

混合器，Istio 的“瑞士軍刀”

首先來看混合器（Mixer）組件，談一談它的作用以及它給監控帶來的好處。在我看來，所謂“混合器”最好看作是一種屬性處理器。網格中的代理都會發送一組內容各異的屬性，比如數據請求或環境信息之類，“混合器”會處理所有這些數據並將它們分別路由到正確的適配器上。

“適配器”是附加到“混合器”上的 handler，負責為後端調整屬性數據。後端可以是對這些數據感興趣的外部服務，諸如監控工具（如 Prometheus 或 Stackdriver）、授權後端或日誌堆棧。

概念

入門 Istio 最難的過程之一是熟悉新術語。你剛以為自己好容易搞明白了整個 Kubernetes 詞彙表的時候，卻會發現 Istio 又多出來 50 多個新術語！

在監控這方面，以下是混合器設計中最有趣且有用的一些概念：

• 屬性（Attribute）：指由混合器處理的一段數據。大多數屬性是從邊車發送來的，但適配器也能產生屬性。在實例中會使用屬性將所需數據映射到後端。
• 適配器（Adapter）：嵌入在混合器組件中的邏輯，用來將數據轉發到指定的後端。
• Handler：適配器的配置。由於一個適配器可以服務多個用例，因此將配置解耦就可以讓適配器以多種設置來運行了。
• 實例：將來自 Istio 的數據綁定到適配器模型的實體。 Istio 有一套由邊車容器獲取的統一屬性集，這些數據需要翻譯成後端語言。
• 模板：定義實例模板的通用接口。

創建一個新的監控案例

瞭解過 Istio 相關的定義和概念後，我們要牢記它們的最好方法就是在真實場景中過一遍。

做這個練習時，我推薦大家充分利用 Kubernetes 的標籤元數據，用它來追蹤我們服務的版本迭代。一般來說，轉向微服務架構後你的服務最後都會有很多版本（A/B 測試，API 版本等）。 Istio 的邊車會將你的群集中的所有元數據都發送到混合器。所以在我們這個示例中，我們將利用部署的標籤來識別服務的版本，並觀察每個版本的使用狀況統計信息。

簡單起見我們先來找一個現成的項目，用谷歌微服務演示項目就行了，然後做一些修改以適用我們的方案。這個項目模擬了一個由多個組件組成的微服務架構，用來構建一個電子商務網站。

首先，我們要確保這個項目與 Istio 一起能在我們的集群中正確運行。我們使用自動注入功能在命名空間中部署所有組件，並讓 Istio 自動注入邊車。

複製代碼

$ kubectl label namespace mesh istio-injection=enabled

警告：一定要提前創建 mesh 命名空間，並讓你的 kubectl 上下文指向它。

如果啟用了一個 pod 安全策略，則需要為 init 容器配置一些權限，以使其能正確配置 iptables。出於測試目的你可以使用：

複製代碼

$ kubectl create clusterrolebinding mesh --clusterrole cluster-admin --serviceaccount=mesh:default

這會將默認服務帳戶綁定到群集管理員角色。現在我們可以使用全資源 YAML 文檔來部署所有組件了。

複製代碼

$ kubectl apply -f release/kubernetes-manifests.yaml

現在你應該能看到 pod 在 mesh 命名空間中開始運行了。其中一些 pod 會出錯，因為 Istio 資源還沒添加進去。例如，出口流量會被阻止，currency 組件也會出錯。用下面這些資源來解決問題，並通過 Istio ingress 暴露前端組件。

複製代碼

$ kubectl apply -f release/istio-manifests.yaml

現在我們就可以查看正在使用你的雲服務商提供的 IP 或域工作的前端了（frontend-external 服務通過雲服務商的負載均衡器暴露）。

現在我們的微服務應用開始工作了，下面再進一步，將其中一個組件配置為多個版本。正像你在微服務 YAML 中看到的那樣，部署會有帶著應用名稱的單個標籤。如果我們要管理 canary 部署或運行我們應用的多個版本，我們可以添加另一個版本標籤。

複製代碼

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: currencyservice
spec:
 template:
 metadata:
 labels:
 app: currencyservice
 version: v1

將更改應用於我們的集群后，我們可以用其他名稱複製部署並更改版本。

複製代碼

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: currencyservice2
spec:
 template:
 metadata:
 labels:
 app: currencyservice
 version: v2

現在再次將其提交給 API。

複製代碼

$ kubectl apply -f release/kubernetes-manifests.yaml

注意：雖然我們又一次應用了所有的清單，但只有已更改的清單才會由 API 更新。

一位熱心讀者注意到我們用了一個技巧，就是讓服務選擇器只指向 app 標籤。這樣一來流量就會在不同版本之間平等分配了。

進階之路

現在輪到重頭戲了。我們需要創建三份資源來將版本暴露為 prometheus 中的新指標。

首先，我們創建一個實例。在這裡我們使用 metric 實例模板來將邊車提供的值提供程序映射到適配器的輸入端。我們只看負載的名稱（源）和版本。

複製代碼

apiVersion: "config.istio.io/v1alpha2"
kind: metric
metadata:
 name: versioncount
 namespace: mesh
spec:
 value: "1"
 dimensions:
 source: source.workload.name | "unknown"
 version: destination.labels["version"] | "unknown"
 monitored_resource_type: '"UNSPECIFIED"'
 

現在該配置適配器了。在這個示例中我們希望將指標連接到一個 Prometheus 後端。所以我們要在 handler 配置中定義指標名稱，以及指標會為後端（Prometheus DSL）提供的數值類型，此外還有維度標識所需的標籤名稱。

複製代碼

apiVersion: "config.istio.io/v1alpha2"
kind: prometheus
metadata:
 name: versionhandler
 namespace: mesh
spec:
 metrics:
 - name: version_count # Prometheus metric name
 instance_name: versioncount.metric.mesh # Mixer instance name (fully-qualified)
 kind: COUNTER
 label_names:
 - source
 
 - version

最後，我們需要將這個 handler 與指定的實例（指標）鏈接起來。

複製代碼

apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
 name: versionprom
 namespace: mesh
spec:
 match: destination.service == "currencyservice
.mesh.svc.cluster.local" 
 actions:
 - handler: versionhandler.prometheus
 
 instances:
 - versioncount.metric.mesh
 

一旦應用了這些定義，Istio 將指示 prometheus 適配器開始收集並提供新指標。如果我們看一下 prometheus 用戶界面，會發現它現在正在搜索新指標，內容類似於：

結論

微服務架構中獲得良好的可觀察性並不容易。 Istio 有助於簡化開發者的工作，並將工作交給運營商。

一開始，處理服務網格帶來的各種複雜問題可能很難。但是一旦你馴服了它，就能讓監控配置標準化和自動化，並在極短時間內構建一個出色的可觀察系統。

更多資料

• 如何在集群中安裝 Istio
• 官方https://istio.io/docs/](https://istio.io/docs/">文檔與示例

Fernando Ripoll

Giant Swarm 的解決方案工程師，以豐富的經驗幫助客戶使他們的 Kubernetes 走上正軌。

查看英文原文：https://blog.giantswarm.io/Istio-monitoring-explained/

閱讀更多 InfoQ 的文章

關鍵字: IBM 服務 通信