Istio 0.8 的 Helm Chart 解析

Istio 0.8 的 Helm Chart 解析

做者 崔秀龍 | 2300字 | 閱讀大約須要5分鐘 | 歸檔於istio | 發表於 2018-06-04

標籤 #Istio #Helm #Chart，來自 https://servicemesher.github.io/blog/helm-chart-for-istio-0.8/

兒童節期間，拖拉了一個多月的 Istio 0.8 正式發佈了，這多是 Istio 1.0 以前的最後一個 LTS 版本，意義重大。

新版本中，原來的 Kubernetes 安裝文件 install/kubernetes/istio.yaml，變成了 install/kubernetes/istio-demo.yaml，是的，你沒看錯，這個 LTS 的安裝文件名字叫 demo。查看了一下文檔，大概察覺到不靠譜的 Istio 發佈組的意圖了：這個項目的組件相對比較複雜，原有的一些選項是靠 ConfigMap 以及 istioctl 分別調整的，如今經過從新設計的 Helm Chart，安裝選項用 values.yml 或者 helm 命令行的方式來進行集中管理了。下面就由看看 Istio 的 Helm Chart 的安裝部署及其結構。

使用 Helm 安裝 Istio

安裝包內的 Helm 目錄中包含了 Istio 的 Chart，官方提供了兩種方法：

• 用 Helm 生成 istio.yaml，而後自行安裝。
• 用 Tiller 直接安裝。

很明顯，兩種方法並無什麼本質區別。例如第一個命令：

helm template install/kubernetes/helm/istio \
    --name istio --namespace  \
    istio-system > $HOME/istio.yaml

這裏說的是使用 install/kubernetes/helm/istio 目錄中的 Chart 進行渲染，生成的內容保存到 $HOME/istio.yaml 文件之中。而第二個命令

helm template install/kubernetes/helm/istio \
    --name istio --namespace istio-system \
    --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml

只是設置了 Chart 中的一個變量 sidecarInjectorWebhook.enabled 爲 False。從而禁止自動注入屬性生效。

咱們照貓畫虎，看看命令二的結果提交到 Kubernetes 中會發生什麼事情。

helm template install/kubernetes/helm/istio --name istio \
--namespace istio-system --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml

kubectl create namespace istio-system
kubectl create -f $HOME/istio.yaml

根據不一樣的網絡狀況，可能須要幾分鐘的等待，最後會看到這些 Pod 在運行：

istio-citadel-ff5696f6f-h4rdz
istio-cleanup-old-ca-rp5p6
istio-egressgateway-58d98d898c-5jnpz
istio-ingress-6fb78f687f-wsl5q
istio-ingressgateway-6bc7c7c4bc-hhrh7
istio-mixer-post-install-d2kl5
istio-pilot-6c5c6b586c-dqv2w
istio-policy-5c7fbb4b9f-xmv6f
istio-statsd-prom-bridge-6dbb7dcc7f-27tx7
istio-telemetry-54b5bf4847-9gpr7
prometheus-586d95b8d9-gb846

1. 過去的 istio-ca 現已改名 istio-citadel。
2. istio-cleanup-old-ca 是一個 job，用於清理過去的 Istio 遺留下來的 CA 部署（包括 sa、deploy 以及 svc 三個對象）。
3. istio-mixer-post-install 一樣也是一個 job，和上面的 Job 同樣，簡單的調用 kubectl 建立第三方資源，從而避免了以前的 CDR 須要重複建立的尷尬情況。
4. egressgateway、ingress 以及 ingressgateway，能夠看出邊緣部分的變更很大，之後會另行發文。
5. 和從前不一樣，缺省已經打開了監控界面。

Helm Chart 的安裝配置

下面的配置項目，均可以使用 helm 的 --set key=value 來設置，能夠重複使用，用來設置多個值。

選項	說明	缺省值
global.hub	絕大部分鏡像所在的鏡像庫地址	docker.io/istionightly
global.tag	Istio 使用的絕大部分鏡像的 Tag	circleci-nightly
global.proxy.image	指定 Proxy 的鏡像名稱	proxyv2
global.imagePullPolicy	鏡像拉取策略	IfNotPresent
global.controlPlaneSecurityEnabled	控制面是否啓動 mTLS	false
global.mtls.enabled	服務間是否缺省啓用 mTLS	false
global.mtls.mtlsExcludedServices	禁用 mTLS 的 FQDN 列表	- kubernetes.default.svc.cluster.local
global.rbacEnabled	是否建立 RBAC 規則	true
global.refreshInterval	Mesh 發現間隔	10s
global.arch.amd64	amd64 架構中的調度策略，0：never；1: least preferred；2：no preference；3：most preferred	2
global.arch.s390x	amd64 架構中的調度策略，0：never；1: least preferred；2：no preference；3：most preferred	2
global.arch.ppc64le	amd64 架構中的調度策略，0：never；1: least preferred；2：no preference；3：most preferred	2
galley.enabled	是否安裝 Galley 用於進行服務端的配置驗證，須要 1.9 版本以上的 Kubernetes	false

上面的內容來自官方文檔，其實這是不符合實際狀況的（Istio 用戶的平常）。在 install/kubernetes/helm/istio/values.yaml 中，包含這一發行版本中的全部的缺省值。能夠直接修改或者新建 values.yaml，並在 helm 命令行使用 -f my-values.yaml 參數來生成自行定製的 istio.yaml

解讀 Istio Helm Chart 中的模塊

打開 Istio 的 Chart 以後，發現其中並無任何組件的內容，只有兩個 Configmap 對象的模板。其安裝主體再次很非主流的經過依賴 Chart 的方式實現了徹底的模塊化。所以這個 Chart 的主體，其實是 requirements.yaml，打開這個文件，會看到規規矩矩的列出不少模塊，例如：

- name: sidecarInjectorWebhook
    version: 0.8.0
    # repository: file://../sidecarInjectorWebhook
    condition: sidecarInjectorWebhook.enabled

這代表在 sidecarInjectorWebhook 取值爲 enabled 的時候，就渲染這一模板。所以這裏能夠看作是模塊的啓用停用的控制點。這裏列出的模塊包括：

模塊	描述
egressgateway	外發流量網關
galley	在 K8S 服務端驗證 Istio 的 CRD 資源的合法性
grafana	Dashboard
ingress	Ingress Controller
ingressgateway	Ingress Gateway
mixer	Mixer
pilot	Pilot
prometheus	Prometheus
security	安全相關內容
servicegraph	調用關係圖
sidecarInjectorWebhook	自動注入
tracing	Zipkin Jeager 的跟蹤服務

下面逐一作一下簡要說明

egressgateway

外發通訊的網關。

他的設置保存在 values.yaml 的 egressgateway 一節中（都是保存在同名分支下，後面再也不重複）。部署內容包括：

• Deployment 和 Service：一個 proxy。
• HPA
• RBAC 相關內容

可定製項目包括：

• 服務端口和類型
• HPA 實例數量上下限
• 資源限制

galley

以前的 istio 版本中，只能經過 istioctl 驗證 Istio 相關 CRD 的有效性，這個模塊提供一個在服務端驗證 CRD 的方法，他的部署內容包含：

• Deployement 和 Service。
• RBAC 相關
• 用於 CRD 校驗的 ValidatingWebhookConfiguration 對象。

校驗目標包含 Pilot（例如 destinationpolicies 和 routerules） 和 Mixer（例如 memquotas 和 prometheuses） 兩類 CRD。

grafana

一個帶有 Istio 定製 Dashboard 的 Grafana 封裝。

實際上將其鏡像中的 Dashboard 複製出來就能夠在其餘 Grafana 實例上運行了。

定製內容的 grafana.ingress.* 中包含 Ingress 的配置，用於外網訪問。

ingress

Istio 的 Ingress Controller

具體部署內容和 egresscontroller 基本一致。

ingressgateway

0.8.0 新增功能，爲 Ingress 通訊提供 Istio rules/destination 等特性。

部署內容和 ingress 相似。

mixer

Mixer 負責的是遙測和前置檢查，他的 Chart 相對比較複雜，部署內容包括：

• 和前面的版本不一樣，Mixer 的部署分紅了兩個部分，分別是 Policy 和 Telemetry 兩個 Deployment 對象。
• Service 也一樣分紅兩個，其中 telemetry service 多了一個 prometheus 端口
• crds.yaml 中包含了 mixer 所支持的全部 crd 定義（例如 memquotas 和 prometheuses）。
• create-custom-resources-job.yaml 中包含了用於建立 crd 的 Job 對象。

pilot

Pilot 承上啓下，負責服務發現和向 Proxy 下發配置。除了常規的 Deployment 和 Service 以外，還包含了 crds.yaml，用於聲明 CRD 資源類型（例如 destinationpolicies 和 routerules）。

prometheus

這個組件跟前面的 Grafana 相似，也是一個預約義的鏡像。這個模板中的 Configmap 就是 Prometheus 的抓取配置，能夠直接用到其餘的 Prometheus 實例之中。

security

舊版本中的 Istio-ca

Security 部分的部署內容包括：

• RBAC
• Job：使用 kubectl 清理舊版本 istio-ca 實例。
• Deployment，原 CA。
• Service：開放兩個端口，分別服務於 http 和 gRPC。

servicegraph

Service Graph 支持，和 Grafana 基本一致。

sidecarInjectorWebhook

這一部分的功能是自動爲 K8S 對象注入 Envoy。主要包含：

• Deployment 和 Service
• RBAC 相關
• 一個 MutatingWebhookConfiguration 對象，會監聽 Pod 的建立事件，用於自動注入。

tracing

Jeager 的跟蹤支持，整體狀況跟 Prometheus 和 Grafana 等監控組件相似，配置項和暴露服務方面稍有區別：

• 配置中包含 Jaeger 的環境變量的控制。
• 開啓 jaeger 開關，會啓用 Jaeger 的幾個服務端口。