天天看點
傳回

Istio Helm Chart 詳解 - Mixer

前言

Mixer 是 Istio 的核心元件之一，負責服務網格中的遙測和政策兩部分重要功能，是以 Mixer 的部署也分成了 Policy 和 Telemetry 兩部分。

values.yaml 中的全局變量 

mixer:
 enabled: true
 replicaCount: 1
 autoscaleMin: 1
 autoscaleMax: 5
 image: mixer istio-policy:
   autoscaleEnabled: true
   autoscaleMin: 1
   autoscaleMax: 5
   cpu:
     targetAverageUtilization: 80 istio-telemetry:
   autoscaleEnabled: true
   autoscaleMin: 1
   autoscaleMax: 5
   cpu:
     targetAverageUtilization: 80 prometheusStatsdExporter:
   hub: docker.io/prom
   tag: v0.6.0

複制

這裡看到，和我們前面說到的功能分離相同，Policy 和 Telemetry 兩個元件也是分别設定了各自的變量。根據前面幾篇的經驗看，

istio-policy

和

istio-telemetry

兩部分是用于控制兩個部署的自動伸縮。而

prometheusStatsdExporter

部分則是指定了一個鏡像，用于提供 Prometheus 監控使用。而從

enable

位置來看，兩個元件是不推薦單獨啟用的，但是 HPA 是可以分别設定的。

RBAC 相關

這裡可以看到，Mixer 的兩個元件使用的是同一個

istio-mixer-service-account

，根據對

clusterole.yaml

的觀察，可以看到如下權限：

組 資源 權限
config.istio.io * 讀寫
rbac.istio.io * 讀寫
apiextensions.k8s.io customresourcedefinitions 讀
"" "configmaps", "endpoints", "pods", "services", "namespaces", "secrets" 讀
extensions replicasets 讀
config.istio.io replicasets 讀

autoscale.yaml

這裡用了一個循環：

{{- range $key, $spec := .Values }}
{{- if or (eq $key "istio-policy") (eq $key "istio-telemetry") }}
{{- if and $spec.autoscaleEnabled $spec.autoscaleMin }}

複制

分别周遊全局變量中的

mixer.istio-policy

和

mixer.istio-telemetry

，使用各自的 HPA 參數對伸縮過程進行配置。

兩個 HPA 對象的名字來自上面的循環：

istio-policy

和

istio-telemetry

。引用變量包括這兩個分組中的所有變量。

這裡不難發現 Mixer 中的根級變量

autoscaleMin

 、

autoscaleMax

 是無用的，該問題在新版本中已經修正。

service.yaml

和 HPA 的情況類似，這裡用循環的方式生成了兩個 Service，分别為

istio-policy

和

istio-telemetry

。

端口方面，兩個服務都開放了

grpc-mixer

、

grcp-mixer-mtls

以及

http-monitoring

三個端口：

  • grpc-mixer: 9091

     ：用于 Mixer 的 gRPC API 端口。

  • grpc-mixer-mtls: 15004

     ：啟用 mtls 的時候使用的 API 端口。如果啟用了 controlPlaneAuthPolicy，則使用該端口進行 Mixer API 通信。

  • http-monitoring

     ：用于監測 Mixer 存活狀态。

另外如果是

istio-telemetry

，還多定義了一個端口

prometheus

，Prometheus 可以從這一端口擷取遙測資料。

此處僅引用了

Chart

和

Release

的全局變量。

statsdtoprom.yaml

這個元件用來把 Envoy 的 Statsd 名額轉換為 Promtheus 名額。這裡包含了 Service 和 Deployment 兩部分。

Deployment

這裡實際上是引用了 Prom 的一個 Exporter，除了引用了

Chart

和

Release

全局變量之外，還使用了如下幾個變量：

  • prometheusStatsdExporter.hub

     ：鏡像倉庫的位址。

  • prometheusStatsdExporter.tag

     ：鏡像版本。

  • global.imagePullPolicy

     ：鏡像拉取政策。

  • prometheusStatsdExporter.resources

     ：可以定義這一 Pod 的資源使用政策。

  • nodeSelector

     ：可以根據資源情況，為該 Pod 進行節點選擇，避免資源争用。

除去上面的變量之外，還可以看到如下資訊：

  • 該 Pod 不接受自動注入。
  • 開放了 TCP 端口 9102 以及 UDP 端口 9125。
  • 加載一個 ConfigMap：istio-statsd-prom-bridge，用于配置檔案。
上文提到的 Configmap 來自于模闆檔案

configmap.yaml

 ，這一檔案沒有提供任何額外配置。

Service

這裡聲明了 Exporter 的端口使用：

  • TCP 端口 9102 提供給 Prometheus 進行資料抓取。
  • UDP 端口 9125，Envoy 會發送名額進入 Exporter。

autoscale.yaml

這裡使用

values.yaml

中定義的内容，分别給 Telemetry 和 Policy 兩個元件定義了各自的自動伸縮。

預設情況下，都是最少單副本，最多 5 副本，平均 CPU 用量 80%。

deployment.yaml

這個檔案稍微有點古怪，首先分别定義了

policy_container

和

telemetry_container

兩個模闆，然後在檔案尾部進行合并。

policy_container

這個 Deployment 負責 Mixer 的政策實施功能，其主程序為 mixs，并且注入了 Sidecar。除了 Chart 和 Release 之外，引用全局變量包括：

  • global.priorityClassName

     ：Pod 優先級

  • global.hub

     ：鏡像倉庫。

  • global.tag

     ：鏡像标簽。

  • image

     ：鏡像名稱，如果名稱中包含

    /

     ，則忽略

    global.hub

     和

    global.tag

     。

  • resource

     和

    global.defaultResources

     ：如果沒有特别定義資源限制，則沿用 Chart 設計的預設限制。需要注意的是，Policy 和 Telemtry 的兩個元件，資源設定是共享的同一套值。

  • global.controlPlaneSecurityEnabled

     ：根據這個參數來設定 istio-proxy 的

    --controlPlaneAuthPolicy

     ，在

    MUTUAL_TLS

     和

    NONE

     之間選擇。

  • global.proxy.resources

     和

    global.defaultResources

     ：如果沒有定義全局的 Proxy 資源限制，也會沿用預設限制。

mixs policy

程序使用了

unix:///sock/mixer.socket

進行監聽，這一點在 Envoy 配置中也有對應的處理。

telemetry_container

該容器僅在指令行（

args

）上和

policy

Pod 有差别，就無需介紹了。

config.yaml

這裡包含了 Mixer 初始配置：

  • attributemanifest：
    • istioproxy：定義了 Sidecar 中的屬性清單。
    • kubernetes：Kubernetes 相關的屬性清單。
  • stdio：定義使用 JSON 格式進行輸出的 stdio handler。
  • logentry：定義了兩個不同用途的日志模闆執行個體，用不同屬性組成不同内容，用于記錄通路日志：

    • accesslog

    • tcpaccesslog
  • metric 對象用于定義遙測資料的結構清單：

    • requestcount

    • requestduration

    • requestsize

    • responsesize

    • tcpbytesent

    • tcpbytereceived
  • prometheus Handler：把前面定義的

    metric

     執行個體逐個映射為 Prometheus 的監控名額。
  • kubernetesenv：該 Handler 為 Mixer 提供 Kubernetes 叢集的連接配接。
  • kubernetes：用于生成 Kubernetes 相關的資料。
  • rule：

    • stdio

       ：定義一條規則，将

      http

       和

      grpc

       協定的通路日志，用

      accesslog

       的樣式輸出到

      stdio

       。

    • stdiotcp

       ：定義一條規則，将

      http

       和

      grpc

       協定的通路日志，用

      tcpaccesslog

       的樣式輸出到

      stdio

       。

    • promhttp

       ：将

      http

       和

      grpc

       協定産生的

      requestcount

       、

      requestduration

       、

      requestsize

       以及

      responsesize

       四種名額送入前面建立的 Prometheus handler。

    • promtcp

       ：将

      tcp

       協定産生的

      tcpbytesent

       和

      tcpbytereceived

       名額送入前面建立的 Prometheus handler。

    • kubeattrgenrulerule

       ：将

      kubernetesenv

       生成的資料交由

      kubernetes

       屬性模闆處理。

    • tcpkubeattrgenrulerule

       ：将

      kubernetesenv

       生成的 tcp 通信相關資料交由

      kubernetes

       屬性模闆處理。
  • 目标規則：兩條規則分别定義了到 policy 和

    telemetry

     控制器的連接配接池，如果啟用了

    controlPlaneSecurityEnabled

     ，則加入對 15004 端口的 tls 定義。

總結

在 Istio 中 Mixer 一直是一個備受争議的元件，一方面表達了 Istio 的遠大設計目标，另一方面因為自身結構以及衆多 Adapter 的缺陷，持續遭到使用者诟病，是以上也是目前為止部署體系變化最大的一塊，相信後續版本中，Mixer 還會做出頻繁的好的和壞的變更。

上一篇: 淺談虛拟用戶端裝置（vCPE）
下一篇: 【死磕 Java 集合】— LinkedBlockingQueue源碼分析【死磕 Java 集合】— LinkedBlockingQueue源碼分析