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

[TOC]

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

Mixer的Service和Pod

三個Service【statsd、Policy、Telemetry】

Mixer分為Policy和Telemetry兩個子模塊。Policy用于向Envoy提供準入策略控制，黑白名單控制，速率限制等相關策略；Telemetry為Envoy提供了數(shù)據上報和日志搜集服務，以用于監(jiān)控告警和日志查詢。

Mixer Policy和Mixer Telemetry很容易成為整個集群的性能短板，因為Envoy發(fā)起每個請求前都需要對Policy服務進行Check請求，一方面增加了業(yè)務請求本身的延遲，一方面也給作為單點的Policy增大了負載壓力。如果追求性能，可以裁剪一些功能如速率限制，全局配額等，禁用Mixer的Policy

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

istio-statsd-prom-bridge 這個服務也是mixer會提供的，通過安裝參數(shù)--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可以發(fā)現(xiàn)會有兩個和Mixer相關的Service

  • istio-policy

    • Mixer相關組件，用于與envoy交互，check需要上報的數(shù)據，確定緩存內容，掛掉會影響check相關功能，除非設置為不進行check

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

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

    • 如果要禁能所有的policy策略檢查，需要重新編輯整個服務網格的配置，并且重啟pilot 容器

    • 全局選項--set global.disablePolicyChecks=true可以禁止策略檢查，然后對應的helm install的value.yaml的配置這里修改disablePolicyChecks為true也是OK的。注意這些個策略的更改需要稍等一些時間才能全部生效。修改完需要重啟pilot。

    • 通過安裝參數(shù)--set mixer.enabled=false禁能Mixer組件

  • istio-telemetry

    • Mixer相關組件的Service，用于采集envoy上報的遙測數(shù)據，該組件掛掉將導致各監(jiān)控運維插件無法采集到數(shù)據，同時，該組件在高并發(fā)情境下，會承受較大負荷，建議設置為多實例，增強可靠性

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

    • 暴露9091、9093、15004、42422端口

      • 9093端口是Mixer組件本身的prometheus暴露的端口
      • 42422是所有 Mixer 生成的網格指標

    • 通過安裝參數(shù)--set mixer.enabled=false禁能Mixer組件

  • istio-statsd-prom-bridge

    • 暴露9102、9125端口

    • 這個 statsd是一個轉換為prometheus的組件，用來統(tǒng)計envoy 生成的數(shù)據，這個是必須的

    • 通過安裝參數(shù)--set mixer.enabled=false就禁能了這個組件，禁能這個組件會導致ingressgateway的envoy初始化失敗，報錯日志error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge，因為statsdUdpAddress這個參數(shù)指定了地址為istio-statsd-prom-bridge:9125，因此還需要修改istio這個configmap中的statsdUdpAddress地址

    • 安裝選項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

如果直接通過安裝參數(shù)--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了 ?；蛘咧苯訉nstall/kubernetes/helm/istio/charts/mixer/templates/deployment.yaml 和 service.yaml文件移除，就都不會部署istio-telemetry 和 istio-policy，這個做法還會部署istio-statsd-prom-bridge ，其實這正是我們想要的。

不過問題在于，無法通過選型參數(shù)來禁止istio-telemetry 和 istio-policy，這個后面還需要再研究研究。

Mixer的check和report

需要check的 policy 策略

envoy的每個前置請求都要到mixer中進行check，這個check必然會導致一些性能的降低，拋開性能不談，先看看這個check的到底是哪些策略，有些什么策略可以check，check完會如何？

首先要說明的是，這些策略的檢測，是人為控制的，也就是并非是istio自帶就有會這些策略需要檢測，而是需要人為去配置一些策略。

envoy發(fā)起check請求的時候，會根據收到的請求生成指定的attributes，然后attributes作為參數(shù)之一向Mixer發(fā)起Check rpc請求。Mixer中如果有對應的adapter，則會進行處理然后返回響應結果，然后envoy根據結果決定是否執(zhí)行請求或拒絕請求。

一些常見的check策略如：白名單檢查、ACL檢查、速率限制等，其實這些功能都是相對來說對業(yè)務更為友好的一些功能，所以，如果性能問題不是一個大的瓶頸下的話，這個組件最好還是保留較好。

需要report的Telemetry遙測報告

Mixer提供了一個GRPC接口，這個接口負責接收Envoy上報的數(shù)據，Envoy會向Mixer上報日志、監(jiān)控（log、metrics）等數(shù)據，Envoy上報的原始數(shù)據都是一些屬性詞匯，然后Mixer會轉換，最終會分發(fā)到logentry 和 Metric，Mixer后端的adapter（如prometheus）會基于遙測數(shù)據做進一步處理。

Proxy代理（Envoy sidecar）是在執(zhí)行請求之后才需要Report，調用Mixer進行上報，這個屬于后置上報，是異步的處理流程，模式是fire-and-forget，當然如果后端adapter處理不過來，無法Response給Envoy的話同樣還是會影響到Envoy的性能。

從一些Default Metrics中可以看到提供給外界的一些監(jiān)控指標是非常重要的，有助于我們去分析整個系統(tǒng)和后端adapter

遙測相關的后端包含：

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

當然，prometheus、grafana、Tracing等可以直接通過envoy，而不經過Mixer；經過Mixer可以查詢到更豐富的數(shù)據，當然缺陷就在于多了一層降低性能。

問題 & TODO

無法通過選項參數(shù)來禁止istio-telemetry 和 istio-policy，這個后面還需要再研究研究?？梢詫elm install下的相關的Service和Deployment文件移除，然后helm install 或者 upgrade

【"歡迎關注我的微信公眾號：Linux 服務端系統(tǒng)研發(fā)，后面會大力通過微信公眾號發(fā)送優(yōu)質文章"】

image.png
最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容