Istio 0.8 的 Helm Chart 解析
儿童节期间，拖拉了一个多月的 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
- 过去的 istio-ca 现已更名 istio-citadel。
- istio-cleanup-old-ca 是一个 job，用于清理过去的 Istio 遗留下来的 CA 部署（包括 sa、deploy 以及 svc 三个对象）。
- istio-mixer-post-install 同样也是一个 job，和上面的 Job 一样，简单的调用 kubectl 创建第三方资源，从而避免了之前的 CDR 需要重复创建的尴尬状况。
- egressgateway、ingress 以及 ingressgateway，可以看出边缘部分的变动很大，以后会另行发文。
- 和从前不同，缺省已经打开了监控界面。
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 的几个服务端口。