参考
1. Istio Chart 目录结构
- PATH:
istio-1.1.7/install/kubernetes/helm
1.1 Chart.yaml
- Chart 的基础信息文件，其中包含版本号，名称，关键字等元数据信息。
1.2 values-*.yaml
- 提供 istio 在各种场景下的关键配置范本，范本文件可以作为 helm 的输入文件，对 istio 进行典型定制；
- 对输入文件改写后，使用
helm template命令生成最终的部署文件。
1.3 requirements.yaml
- 用于管理对子 Chart 的依赖关系，其中定义了一系列开关变量‘
- 在 helm 的输入内容中对相关变量进行定义，就可以对 istio 的部署文件进行修改，来控制对应组件的启用状态。
1.4 templates
1.4.1 _affinity.tpl
- 生成一组节点亲和或互斥元素，供各个组件在渲染 yaml 时使用；
- 在该文件里使用一系列变量，用于控制 istio 组件的节点亲和性，即 istio 在部署时对节点的选择。
- 定义了两个局部模版：
- nodeAffinityRequiredDuringScheduling: 会根据全局变量中的 arch 参数对部署节点进行限制；istio 组件的 pod 会根据 arch 参数中的服务器类型列表来决定是否部署到某一台服务器上，并根据各种服务器类型的权重来决定优先级。
- nodeAffinityPreferredDuringScheduling: 类似
nodeAffinityRequiredDuringScheduling，但是软限制
1.4.2 sidecar-injector-configmap.yaml
- 该文件最终会生成一个
ConfigMap对象，在该对象中保存的配置数据被用于进行Sidecar注入； - istio 完成的手工注入或自动注入，都会引用这个
ConfigMap对象，即如果希望修改 istio 的Sidecar的注入过程及具体行为，可以从该文件或对应的ConfigMap入手。
1.4.3 configmap.yaml
- 生成名为
istio的ConfigMap对象，用于为 Pilot 提供启动配置数据。
1.5 charts
目录中的子目录就是istio组件：
- certmanager: 一个基于 Jetstack Cert-Manager 项目的 ACME 证书客户端，用于自动进行证书的申请，获取与分发。
- galley：istio 利用 galley 进行配置管理工作。
- gateways: 对 gateways chart 进行配置，可以安装多个 gateway controller。
- grafana：图形化的 istio dashboard。
- ingress: 遗留设计，默认关闭，在流量控制协议升级到 network.istio.io/v1alpha3 之后关闭，已建议弃用。
- kiali: 带有分布式跟踪，配置校验等多项功能的 dashboard。
- mixer: istio 的策略实施组件。
- pilot: istio 的流量管理组件。
- prometheus: 监控软件，其中包含 istio 特定的指标抓取设置。
- security: citadel 组件，用于证书自动管理。
- servicegraph：分布式跟踪组件，用于获取和展示服务调用关系图，即将废除。
- sidecarInjectorWebhook：自动注入 Webhook 的相关配置。
- tracing：分布式跟踪组件，使用 Jaeger 实现，替代原 servicegraph 组件。
2. 全局变量
istio chart 分为父子两层，因此变量具有全局与本地两级。
- 全局变量使用保留字
global进行定义； - 子 chart 可以通过 values.global的方式引用全局变量；
- 在主 chart 中也可以用 chart.var 的方式为子 chart 指定变量值。
2.1 hub & tag
- 在多数情况下，这两个变量代表所有镜像的地址，具体名称一般以
{{ .Values.global.hub }}/[component]/:{{ .Values.global.tag }}的形式拼接而成； - 在
proxy_init，Mixer，Grafana与Pilot的 Deployment 模板中 ，一旦在其 image 变量中包含路径符 "/" ，则会弃用global.hub，直接采用 image 的定义。
2.2 ingress.enabled
- 用来控制是否启用 istio 的 ingress controller；
- 设置为 True ，就会启用对 Kubernetes Ingress 资源的支持，这是一个兼容功能，istio 并不推荐 ingress 的使用方式，建议使用 ingress gateway 取代；
- k8sIngressSelector & k8sIngressHttps 两个变量受 ingress.enabled 影响（设置为 True 时，两个变量相关内容才生效）。
2.3 proxy相关参数
在 values.yaml 中定义了一组 proxy 变量，用于对 Sidecar 进行控制。
2.3.1 proxy.resources
- 用于为 Sidecar 分配资源。
2.3.2 proxy.concurrency
- Proxy Worker 的线程数量；
- 如果被设置为
0(default)，则根据 CPU 线程或核的数量进行分配。
2.3.3 proxy.accessLogFile
- Sidecar 的访问日志位置；
- 如果被设置为空字符串，表示关闭访问日志功能；
- 默认值：/dev/stdout 。
2.3.4 proxy.privileged
- istio-init & istio-proxy 的特权模式开关，默认值
false。
2.3.5 proxy.enableCoreDump
- 如果打开，则新注入的 Sidecar 会启动 CoreDump 功能，在 Pod 中加入初始化容器
enable-core-dump； - 默认值
false。
2.3.6 proxy.includeIPRanges
- 劫持 IP 范围的白名单；
- 默认值
*，表示劫持所有流量； - 在
sidecar-injector-configmap.yaml中应用了这个变量，用于生成istio-sidecar-injector这个ConfigMap，此ConfigMap设置了 istio-init 的运行参数，proxy.includeIPRanges通过对 istio-init 的"-i" 参数进行修改来完成这一个任务。
2.3.7 proxy.excludeIPRanges
- 劫持 IP 范围的黑名单；
- 默认值为空字符串，表示劫持该范围以外的IP；
proxy.excludeIPRanges影响 istio-init 的"-x" 参数。
2.3.8 proxy.includeInboundPorts
- 入站流量的端口劫持白名单；
- 所有从范围内的端口进入 Pod 的流量都会被劫持；
proxy.includeInboundPorts影响 istio-init 的"-b" 参数。
2.3.9 proxy.excludeInboundPorts
- 入站流量的端口劫持黑名单；
- 端口范围之外的入站流量会被劫持；
proxy.excludeInboundPorts影响 istio-init 的"-d" 参数。
2.3.10 proxy.autoInject
- 用于控制是否自动完成 Sidecar 的注入工作。
2.3.11 proxy.envoyStatsd
- 默认值如下：
- enabled: true
- host: istio-statsd-prom-bridge
- port: 9125
- 参数会设置 Envoy 的 "--statsdUdpAddress" 参数，在某些参数下（如没有安装 Mixer）可以关闭。
2.4 proxy_init.image
- 用于指定初始化容器镜像。网格中的服务 Pod 在启动之前，首先会运行一个初始化镜像来完成流量劫持工作。
2.5 imagePullPolicy
- 镜像拉取策略；
- 默认值
IfNotPresent。
2.6 controlPlaneSecurityEnabled
- 指定是否在 istio 控制面组件上启用 mTLS 通信；
- 启用之后，Sidecar 与控制面组件之间，以及控制平面组件之间的通信，都会被改成 mTLS 方式；
- 受影响组件包括：Ingress ， Mixer ，Pilot 及 Sidecar。
2.7 disablePloicyChecks
- 设置为
True，则会禁用 Mixer 的预检功能； - 预检功能是一个同步过程，有可能因预检缓慢造成业务应用的阻塞。
2.8 enableTracing
- 是否启用分布式跟踪功能；
- 默认值
true。
2.9 mtls.enabled
- 服务之间是否默认启用 mTLS 连接；
- 如果被设置为
true，那么网格内部所有服务之间的通信都会使用 mTLS 进行安全加固； - 此变量是全局的，对于每个服务还可以单独使用目标规则或通过服务注解的方式，自行决定是否采用 mTLS 加固。
2.10 imagePullSecrets
- 用于为 ServiceAccount 分配在镜像拉取过程中所需要的认证凭据；
- 默认值为空。
2.11 arch
- 在设置 istio 组件的节点亲和性过程中，会使用此变量的列表内容来确定可以用于部署的节点范围，并按照不同的服务器架构设置优先顺序；
默认列表内容如下：
amd64: 2 s390x: 2 ppc64le: 2
2.12 oneNamespace
- 默认值
false，Pilot 会监控所有命名空间内的服务变化； - 如果设置为
true，则会在 Pilot 的服务发现参数中加入 "-a"，此时 Pilot 只会对 istio 组件所在命名空间进行监控。
2.13 configValidation
- 用于配置是否开启服务端的配置验证；
- 默认值
true； - 开启之后，会生成1个 "ValidatingWebhookConfiguration" 对象，并被包含到 Galley 的配置中，从而启用校验功能。
2.14 meshExpansion
- 需要将网格扩展到物理机或虚拟机上时，使用此变量；
- 默认值
false； - 开启之后，会在 Ingress Gateway 上公开 Pilot 与 Citadel 的服务。
2.15 meshExpansionILB
- 是否在内部网关中公开 Pilot 与 Citadel 的端口；
- 默认值
false，仅在网格扩展时会使用此变量。
2.16 defaultResources
- 为所有 istio 组件都提供1个最小资源限制；
- 默认只设置1个请求
10mCPU 资源的值； - 可在各 Chart 的局部变量中分别设置资源需求。
2.17 hyperkube
- 在 istio 的设置过程会使用一个镜像执行一些
Job，如早期版本安装过程中的 CRD 初始化，或现在的清理过期证书等任务； - 镜像默认使用：
quay.io/coreos:v1.7.6_coreos.0。
2.18 priorityClassName
- 在 Kubernetes v1.11.0 以上版本有
priorityClass的概念，具有优先级的 Pod 不会被驱逐或抢占资源； - 默认值为空 ，可选值：
system-cluster-critical与system-node-critical。
2.19 crds
- 该变量用于决定是否包含 CRD 定义；
- 如果使用
heml template命令，或 2.10 以上版本的heml install命令，应将其设置为true； - 否则在安装之前需要执行
kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml，并将该变量设置为false。
3. 自定义安装
3.1 Install with Helm via helm template
根据实际需求定制 values.yaml 文件，包括各子 Chart 的 values.yaml 。如：
- 镜像地址
- 系统资源
- 服务类型
- 可视化组件的服务开放
3.1.1 准备
# 创建 "namespace"
kubectl create namespace istio-system
# 安装 Istio Custom Resource Definitions (CRDs)
helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -
# "CRDs" 部署后，需要等待一些时间(3~5min)，待其完全向 Kubernetes API-servera 注册提交
# "CRDs" 数量默认是 "53"，如果启用 "cert-manager" ，则是 "58"
# istio "CRDs" 以 "istio.io" 或 "certmanager.k8s.io" 结尾
kubectl get crds | grep 'istio.io\|certmanager.k8s.io' | wc -l3.1.2 生成部署清单
# --name: 设置生成的部署内容的基础名称；
# --namespace: 设置命名空间；
# -f: 从指定文件获取输入内容。
helm template install/kubernetes/helm/istio --name istio --namespace istio-system -f values-demo.yaml > istio-demo.yaml3.1.3 部署
# default profile
# helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f -
# 采用生成的部署清单
kubectl apply -f istio-demo.yaml3.2 Install with Helm and Tiller via helm install
helm install方式需要Tiller服务器端，不会生成清单文件；- 如果需要管理
release，建议使用此方式。 - 参考：helm install