Istio Mixer組件和服務的重要說明

[TOC]

Istio Mixer組件和服務的重要說明

Mixer的Service和Pod

三個Service【statsd、Policy、Telemetry】

Mixer分爲Policy和Telemetry兩個子模塊。Policy用於向Envoy提供准入策略控制，黑白名單控制，速率限制等相關策略；Telemetry爲Envoy提供了數據上報和日誌蒐集服務，以用於監控告警和日誌查詢。

Mixer Policy和Mixer Telemetry很容易成爲整個集羣的性能短板，由於Envoy發起每一個請求前都須要對Policy服務進行Check請求，一方面增長了業務請求自己的延遲，一方面也給做爲單點的Policy增大了負載壓力。若是追求性能，能夠裁剪一些功能如速率限制，全局配額等，禁用Mixer的Policy

Istio 在 UAEK 中的實踐改造之路中有對這個的較多說明。

istio-statsd-prom-bridge 這個服務也是mixer會提供的，經過安裝參數--set mixer.enabled=false就禁能了這個組件，禁能這個組件會致使envoy初始化失敗，報錯日誌error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge

Policy、Telemetry 、statsd詳解

kubectl get svc -n istio-system能夠發現會有兩個和Mixer相關的Service

• istio-policy

  • Mixer相關組件，用於與envoy交互，check須要上報的數據，肯定緩存內容，掛掉會影響check相關功能，除非設置爲不進行check

  • Envoy會在每次請求發送前向Mixer Policy發送Check請求檢查該請求是否收策略限制或者配額限制

  • 不能直接關閉或者說禁能這個策略組件，由於默認請求都是要去policy pods進行check檢測的，若是失敗則會致使請求失敗，詳見

  • 若是要禁能全部的policy策略檢查，須要從新編輯整個服務網格的配置，而且重啓pilot 容器

  • 全局選項--set global.disablePolicyChecks=true能夠禁止策略檢查，而後對應的helm install的value.yaml的配置這裏修改disablePolicyChecks爲true也是OK的。注意這些個策略的更改須要稍等一些時間才能所有生效。修改完須要重啓pilot。

  • 經過安裝參數--set mixer.enabled=false禁能Mixer組件

• istio-telemetry

  • Mixer相關組件的Service，用於採集envoy上報的遙測數據，該組件掛掉將致使各監控運維插件沒法採集到數據，同時，該組件在高併發情境下，會承受較大負荷，建議設置爲多實例，加強可靠性

  • Envoy每次請求接收後會向Mixer Telemetry上報本次請求的基本信息，如調用是否成功、返回狀態碼、耗時數據。

  • 暴露909一、909三、1500四、42422端口

    • 9093端口是Mixer組件自己的prometheus暴露的端口
    • 42422是全部 Mixer 生成的網格指標

  • 經過安裝參數--set mixer.enabled=false禁能Mixer組件

• istio-statsd-prom-bridge

  • 暴露910二、9125端口

  • 這個 statsd是一個轉換爲prometheus的組件，用來統計envoy 生成的數據，這個是必須的

  • 經過安裝參數--set mixer.enabled=false就禁能了這個組件，禁能這個組件會致使ingressgateway的envoy初始化失敗，報錯日誌error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge，由於statsdUdpAddress這個參數指定了地址爲istio-statsd-prom-bridge:9125，所以還須要修改istio這個configmap中的statsdUdpAddress地址

    • 這就須要外部的statsd_exporter支持，關於statsd exporter的更多信息查看這裏

  • 安裝選項global.proxy.envoyStatsd.enabled能夠控制envoy是否直接經過statsd上報，global.proxy.envoyStatsd.host和global.proxy.envoyStatsd.port能夠設置statsd exporter的地址

• 總體而言，徹底禁用Mixer的話，須要配置：

  • envoy的statsd exporter的地址【statsdUdpAddress】
  • set global.disablePolicyChecks=true
  • set mixer.enabled=false

若是直接經過安裝參數--set mixer.enabled=false禁能Mixer組件後，訪問會報錯以下：

[2018-10-12T09:21:17.749Z] "GET /wudebao HTTP/1.1" 503 - 0 33 0 - "192.168.65.3" "curl/7.54.0" "457cf709-2396-953e-b9e0-c405c9c56544" "www.wudebao-web.com" "-"
[libprotobuf ERROR src/istio/mixerclient/report_batch.cc:83] Mixer Report failed with: UNAVAILABLE:Cluster not available
複製代碼

不過，這個異步的report上報不會影響使用，也就是不會影響正常流程。只有同步的check纔會影響到流程和功能使用，設置全局選項不進行check便可解決，可是須要注意envoy的statsdUdpAddress

修改 install/kubernetes/helm/istio/charts/mixer/templates/deployment.yaml 和 service.yaml ，刪除掉policy配置，而後更新就不會再部署policy了 。或者直接將install/kubernetes/helm/istio/charts/mixer/templates/deployment.yaml 和 service.yaml文件移除，就都不會部署istio-telemetry 和 istio-policy，這個作法還會部署istio-statsd-prom-bridge ，其實這正是咱們想要的。

不過問題在於，沒法經過選型參數來禁止istio-telemetry 和 istio-policy，這個後面還須要再研究研究。

Mixer的check和report

須要check的 policy 策略

envoy的每一個前置請求都要到mixer中進行check，這個check必然會致使一些性能的下降，拋開性能不談，先看看這個check的究竟是哪些策略，有些什麼策略能夠check，check完會如何？

首先要說明的是，這些策略的檢測，是人爲控制的，也就是並不是是istio自帶就有會這些策略須要檢測，而是須要人爲去配置一些策略。

envoy發起check請求的時候，會根據收到的請求生成指定的attributes，而後attributes做爲參數之一貫Mixer發起Check rpc請求。Mixer中若是有對應的adapter，則會進行處理而後返回響應結果，而後envoy根據結果決定是否執行請求或拒絕請求。

一些常見的check策略如：白名單檢查、ACL檢查、速率限制等，其實這些功能都是相對來講對業務更爲友好的一些功能，因此，若是性能問題不是一個大的瓶頸下的話，這個組件最好仍是保留較好。

須要report的Telemetry遙測報告

Mixer提供了一個GRPC接口，這個接口負責接收Envoy上報的數據，Envoy會向Mixer上報日誌、監控（log、metrics）等數據，Envoy上報的原始數據都是一些屬性詞彙，而後Mixer會轉換，最終會分發到logentry 和 Metric，Mixer後端的adapter（如prometheus）會基於遙測數據作進一步處理。

Proxy代理（Envoy sidecar）是在執行請求以後才須要Report，調用Mixer進行上報，這個屬於後置上報，是異步的處理流程，模式是fire-and-forget，固然若是後端adapter處理不過來，沒法Response給Envoy的話一樣仍是會影響到Envoy的性能。

從一些Default Metrics中能夠看到提供給外界的一些監控指標是很是重要的，有助於咱們去分析整個系統和後端adapter

遙測相關的後端包含：

• Tracing
• prometheus
• grafana
• serviceGraph
• Metrics
• Fluentd

固然，prometheus、grafana、Tracing等能夠直接經過envoy，而不通過Mixer；通過Mixer能夠查詢到更豐富的數據，固然缺陷就在於多了一層下降性能。

問題 & TODO

沒法經過選項參數來禁止istio-telemetry 和 istio-policy，這個後面還須要再研究研究。能夠將helm install下的相關的Service和Deployment文件移除，而後helm install 或者 upgrade

【"歡迎關注個人微信公衆號：Linux 服務端系統研發，後面會大力經過微信公衆號發送優質文章"】