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

吳德寶AllenWu發表於2018-10-19
元件

[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上報本次請求的基本資訊，如呼叫是否成功、返回狀態碼、耗時資料。

    • 暴露9091、9093、15004、42422埠

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

    • 通過安裝引數--set mixer.enabled=false禁能Mixer元件

  • istio-statsd-prom-bridge

    • 暴露9102、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地址

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

相關文章