参考
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个请求
10m
CPU 资源的值; - 可在各 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 -l
3.1.2 生成部署清单
# --name: 设置生成的部署内容的基础名称;
# --namespace: 设置命名空间;
# -f: 从指定文件获取输入内容。
helm template install/kubernetes/helm/istio --name istio --namespace istio-system -f values-demo.yaml > istio-demo.yaml
3.1.3 部署
# default profile
# helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f -
# 采用生成的部署清单
kubectl apply -f istio-demo.yaml
3.2 Install with Helm and Tiller via helm install
helm install
方式需要Tiller
服务器端,不会生成清单文件;- 如果需要管理
release
,建议使用此方式。 - 参考:helm install
来源:oschina
链接:https://my.oschina.net/u/4313749/blog/3358314