helm | 伪架构师

Helm 和 Kustomize：不只是含谷量的区别

Thu, 08 Aug 2019 00:57:37 +0800

Kustomize 问世的时候，我是比较鄙视的——非要造个谷歌的轮子么？不过最近抽出时间熟悉了一下 Kustomize，发现我还是带了有色眼镜。二者功能虽然有所重叠，但是工作思路的差别还是很大的，下面就简单做一点比较，权当引玉之砖。

Helm

Helm 是 Kubernetes 中的第一个对应用程序进行管理的支撑工具，经常会拿来同 Yum、apt 等工具进行类比。Helm 由几个不同的组件构成：

CLI：客户端工具，有几大功能
- 从 Chart 服务器获取列表、搜索 Chart 项目
- 安装 Chart
- 构建 Chart
- 充当 Chart 服务器
- 和 Tiller 协同管理应用生命周期
- 渲染 Chart 为 Kubernetes 生成 YAML
Tiller：需要用特定授权和 API Server 进行通信，Kubernetes 集群内外部署都可以。
- 它是 Helm 的内鬼，负责接收来自 Cli 的指令，完成对集群内应用生命周期的控制。
- 3.0 中将取消 Tiller。
Repository：
- 是存储 Helm Chart 的仓库，可以被 Cli 工具缓存、检索，CLI 也可以获取 Chart 进行后续操作。
- 和 Tiller 一样，Repository 也不是必要组件，CLI 完全可以仅在本地工作。

Helm Chart

Helm 使用 Chart 对应用程序进行描述，它使用 Go Template 对应用部署所需的 YAML 进行抽象，形成应用部署模板，在需要进行部署时，可以编写 yaml 为模板中的变量进行赋值，也可以在 Helm CLI 的命令行中使用 --set name=value 的方式来对简单变量进行赋值，完成赋值之后，可以选择使用 helm template 指令将 Chart + Value 的组合渲染成为 YAML 供 kubectl 使用，也可以使用 helm install 直接通过 Tiller 进行安装。

Helm 的特色

强大的生命周期管理：有 Tiller 的帮助，可以实现对应用程序实例（Release）的查询、安装、卸载、升级、回滚等复杂操作。
严格的基础版本管控：Chart 是一种模板，Chart 的用户仅能通过对 values 的控制来定制应用的部署行为，模板中没有提供变量的位置，是无法在下游直接进行变更的。
方便的命令行：对于简单变量，可以在部署的同时直接指定内容，方便部署。
插件和工具：Helm 拥趸众多，提供了不少用于 CICD 或者其它方面辅助功能的插件和工具。

Kustomize

Kustomize 是一个新晋选手，只有一个 CLI 工具，在 Kubernetes 1.14 之后，甚至这唯一的工具也成为 kubectl 的一部分，可以说是很轻量级了。

Base + Overlay

在 Kustomize 的文档中明确说明：

kustomize is a command line tool supporting template-free, structured customization of declarative configuration targetted to k8s-style objects.

它放弃了对模板的要求，改用 Base + Overlay 的方式对应用的原始 YAML 进行派生。Overlay，顾名思义，就是覆盖。Kustomize 的 Overlay 可以在 Base 的基础上，通过对 resource、generator、transformer 等的定义，形成新的应用定义，不论 Base 还是 Overlay，都可以通过 kustomize build 生成有效的 YAML。

Kustomize 的特色

功能简单清晰，kubectl 直接支持。
不考虑派生，仅作为应用的 YAML 组织方式也很有帮助。
也有自己的插件系统。例如可以用简单的 YAML 定义，使用文件生成 Configmap/Secret。

比较

Kustomize 自称因为去掉了模板语法，更易使用，对此我保留看法，如果仅就入门使用来看，二者差异并不大。

Tiller 和 Repository 都并非必须，因此在部署上，Kustomize 的优势也不是很大。

我认为他们的区别主要在工作流程上：

Helm 的基础流程比较瀑布：定义 Chart->填充->运行，在 Chart 中没有定义的内容是无法更改的；
Kustomize 的用法比较迭代：Base 和 Overlay 都是可以独立运作的，增加新对象，或者对编写 Base 时未预料的内容进行变更，都不在话下。

例如我们定义了一个很基础的应用，由 Deployment + Service 组成，如果后续部署中需要完成两个变更：

新建 Ingress 对象
修改镜像地址/名称/TAG

在 Helm 中需要：

在 Chart 中加入对 Ingress 的定义
用变量控制 Ingress 是否进行渲染
Ingress 模板应该包含特定的主机名、注解等变量
把镜像也定义成变量
在 Values.yaml 中对这些变量进行赋值。

而在 Kustomize 中：

无需对 Base 进行修改
直接在新的 Overlay 中写入 Ingress Resource
使用内置的 image transformer 替换原有镜像

结论

要公开发布一个较为复杂的应用，例如 Istio，编写良好的 Chart 能给用户很大帮助，用户在缺失一点发挥空间的情况下，通过对 values.yaml 的阅读，就能对这种复杂的部署产生一个较为深入的认识。

如果是常见的业务应用，因为不同部署之间的差异不大，但是未必可以提前做好变化限制，用 Kustomize 可能会是一个更好的选择。

Istio Helm Chart 详解 - Pilot

Sun, 02 Dec 2018 15:44:38 +0800

前言

Pilot 也是 Istio 的核心组件，负责以下任务：

监听注册中心，例如 Kubernetes 中的服务信息变化。
监听 Istio 的路由相关 CRD 资源。
两项内容结合，生成 Envoy 可以理解的配置信息发送给 Envoy。

values.yaml 中的全局变量

  enabled: true
  replicaCount: 1
  autoscaleMin: 1
  autoscaleMax: 5
  image: pilot
  sidecar: true
  traceSampling: 1.0
  # Resources for a small pilot install
  resources:
    requests:
      cpu: 500m
      memory: 2048Mi
  env:
    PILOT_PUSH_THROTTLE_COUNT: 100
    GODEBUG: gctrace=2
  cpu:
    targetAverageUtilization: 80

image 字段使用的镜像名为 pilot。

老生常谈的 HPA 部分和其他组件区别不大，实例数量的上限为 5。

值得注意的是 Pilot 的资源设置，缺省 CPU 500m，内存 2G，比其它组件来说是比较大的。这里还特意注明，这是针对小负载情况的。

sidecar 参数看来可以启用或者关闭 Pilot 组件的 Sidecar 注入。

traceSampling、PILOT_PUSH_THROTTLE_COUNT 和 GODEBUG，目测都是性能向的参数。可以在后面的 Chart 中进行求证。

RBAC 相关

授权部分，Pilot 的 ServiceAccount 为：istio-pilot-service-account，从 clusterrole.yaml 可以看到较多门类的权限：

名称	权限	说明
`config.istio.io/*`	`*`	Mixer 使用此配置对象将数据送入 Adapter。
`rbac.istio.io/*`	只读	RBAC 相关配置。
`networking.istio.io/*`	`*`	流量控制相关配置。
`authentication.istio.io`	`*`	认证策略相关配置。
`apiextensions.k8s.io/customresourcedefinitions`	`*`	Kubernetes CRD。
`extensions/thirdpartyresources`	`*`	Kubernetes TPR，1.8 以后已经弃用。
`extensions/thirdpartyresources.extensions`	`*`	TPR 的扩展资源。
`extensions/ingresses`	`*`	Kubernetes Ingress 资源。
`configmaps`	读写
`endpoints`, `pods`, `services`	`get`, `list`, `watch`
`namespaces`, `nodes`, `secrets`	`get`, `list`, `watch`

gateway.yaml

这个文件中包含了三个 Gateway 对象，用于网格扩展功能。

istio-autogenerated-k8s-ingress：在 80 端口提供 http 边缘监听服务。
meshexpansion-gateway：用于 MeshExpanshion，如果启用了 global.meshExpansion，则创建 Gateway，在边缘提供 15011 的 Pilot 访问，以及 8060 的 citadel 组件访问。
meshexpansion-ilb-gateway：如果启用了 global.meshExpansionILB，则创建该对象，在内部网关中公开 Pilot 和 Citadel 的端口。

istio-autogenerated-k8s-ingress 对象其实是个 Bug，它使用了 global.k8sIngressSelector 作为 Gateway 控制器，也就是说只有在 global.ingress.enabled 为 True 的情况下才有可用的 Gateway 提供服务，这部分应该使用条件判断确定是否包含。

meshexpansion.yaml

这个文件很明显也是用于网格扩展的。事实上这一文件和 gateway.yaml 是一体的，今后可能会做合并。

如果启用了 global.meshExpansion 或者 global.meshExpansionILB，会为 gateway.yaml 中生成的 Gateway 创建 VirtualService：

meshexpansion-pilot：从边缘进入的 Pilot 请求，访问 pilot.istio-system 主机时，如果端口为 15011，则指向 istio-pilot.istio-system.svc.cluster.local。
ilb-meshexpansion-pilot：从内部网管进入的请求，访问主机为 meshexpansionilb.istio-system，将 15011、15010 以及 5353 端口分别转向到 istio-pilot 明文端口、istio-pilot mTLS 端口以及 DNS 服务的 53 端口。

deployment.yaml

主进程为 Pilot Discovery。注解部分要求不进行自动注入。

除了 Chart 和 Release 之外，Pilot 的 Deployment 模板还引用了几个其它的全局变量。

image：和其它核心组件类似，Pilot 中对 image 的值如果包含了 /，则会忽略 hub 的内容，可以方便的替换为内网镜像。
模板 istio.configmap.checksum：来自 templates/_helpers.tpl，Istio chart 中的 /templates/configmap.yaml 文件的校验和。
global.priorityClassName：Pod 优先级。
global.imagePullPolicy：镜像拉取策略。
global.oneNamespace：如果启用了这一参数，则会在主进程参数中加入 -a {{ .Release.Namespace }}。
sidecar：如果为 True，会进行如下操作：
- 在 Pod 中注入 istio-proxy 容器，这一容器会根据 global.controlPlaneSecurityEnabled 设置，决定 controlPlaneAuthPolicy 的值为 MUTUAL_TLS 还是 NONE。
- 注入容器的资源设置来自于 global.proxy.resources 或 global.defaultResources。
sidecar 如果为 False，会进行如下操作：
- 设置启动参数 --secureGrpcAddr 为 15011。
- 开放容器端口 15011。
env：如果设置了 key: value 类型的环境变量，此处会发送给 Pilot 进程。
traceSampling：跟踪取样率，会被设置到 PILOT_TRACE_SAMPLING 环境变量中。
nodeaffinity 模板：来自 templates/_affinity.tpl，用于设置节点亲和性。

service.yaml

这里并无特殊设置，开放如下几个端口：

15010：gRPC 的 xDS 端口
15011：mTLS 的 xDS 端口
8080：传统 http 端口
9093：监控端口

总结

对 Pilot 的资源设置较大，同时 1.0.0 之后屡次出现 Pilot 内存消耗巨大的 Issue，其中的跟踪采样、GC 调试以及 Sidecar 注入方面应该都还有挖掘的潜力。但是很可惜 Pilot 的环境变量并无文档，须待日后进一步完善。

Istio Helm Chart 详解 - Mixer

Mon, 05 Nov 2018 16:37:23 +0800

前言

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 和 Telemetry 的两个组件，资源设置是共享的同一套值。
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 还会做出频繁的好的和坏的变更。

Istio Helm Chart 详解 - Galley

Sat, 27 Oct 2018 15:50:59 +0800

前言

Galley 是 Istio 的配置管理组件，根据官方文档的描述：

Galley 代表其他的 Istio 控制平面组件，用来验证用户编写的 Istio API 配置。随着时间的推移，Galley 将接管 Istio 获取配置、处理和分配组件的顶级责任。它将负责将其他的 Istio 组件与从底层平台（例如 Kubernetes）获取用户配置的细节中隔离开来。

values.yaml 中的相关变量

galley:
  enabled: true
  replicaCount: 1
  image: galley

这里看到，Galley 的相关变量只有启用、副本数量以及镜像三个。

enabled：负责在 requirements.yaml 中标识是否启用 Galley 组件。
replicaCount：负责在 deployment.yaml 中定义副本数量。
image：负责在 deployment.yaml 中定义镜像。

RBAC 相关内容

这里可以看到 Galley 使用 Service Account istio-galley-service-account 的身份运行。全局变量中如果定义了 imagePullSecrets，则会在 serviceaccount.yaml 中进行引用。

clusterrole.yaml 模板中定义了 Galley 所需使用的系统资源：

对 admissionregistration.k8s.io 组中的 validatingwebhookconfigurations 类型的完全控制。
config.istio.io： Mixer CRD 的所有资源的读取权限。
对 istio-galley Deployment 和 Endpoint 的读取权限。

clusterrolebinding.yaml 将上面的两个对象连接起来完成授权。

service.yaml

这里看到为 Galley 开放了两个端口：443 是一个 https 端口，用来提供验证服务；而 9093 是一个用来进行 Galley 自身服务监控的 http 端口。

该文件只引用了 Release 内置变量。

deployment.yaml

这里以 Galley 为主进程创建了一个 Deployment 对象。

在 annotation 一节中将 sidecar.istio.io/inject 设置为 false 来防止自动注入 Sidecar。

全局变量

Chart
Release
global.priorityClassName
global.hub
global.tag
global.imagePullPolicy
模板 nodeaffinity
global.defaultResources

变量使用细节

部署在 Istio 所属命名空间中。
使用 _helpers.tpl 中定义的模板给 App 标签赋值。
使用 Chart 和 Release 变量生成 Deployment 标签。
Chart 变量 replicaCount 确定副本数量。
如果定义了 global.priorityClassName，则设置到 Pod 上，提高组件在集群内的优先级。
使用 global.hub + image + global.tag 的方式设置镜像名称。
如果 Chart 变量设置了 resource，则使用独立的资源限制，否则使用缺省的 global.defaultResources。
使用缺省的节点亲和性定义。

加载卷

加载了一个名为 istio.istio-galley-service-account 的 Secret，注意这个资源的类型为 istio.io/key-and-cert，说明是由 Citadel 生成的，其中包含了几个证书，供 --caCertFile、--tlsCertFile 和 --tlsKeyFile 用来提供 https 服务。

另外加载了一个 ConfigMap，其中的配置文件供 --webhook-config-file 参数使用，作为 Webhook 的参数。这个 ConfigMap 是由模板 configmap.yaml 和 validatingwehookconfiguration.yaml.tpl 生成的，后面将会进行讲解。

configmap.yaml 以及 validatingwehookconfiguration.yaml.tpl

configmap.yaml 模板中并没有实质内容，主要内容存在于 validatingwehookconfiguration.yaml.tpl 之中。

这个模板中定义了一个 ValidatingWebhookConfiguration 类型的资源。这种资源用于在不改变资源的情况下，对其进行校验并发出接受或拒绝的决策。

引用全局变量

Chart 和 Release：用于生成标签和命名空间。
global.configValidation：如果这一变量为 True，才会生成后续内容。

Webhook

webhooks 一节定义了两个元素，分别用于 Pilot 和 Mixer 的校验。以 Mixer 部分为例。

clientConfig 一节，定义了这个 Webhook 会调用的校验服务，标准情况下会使用 Istio 所在的命名空间的 istio-galley，URL 相对路径为 /admitmixer，其中的 rules 内容，定义了针对 config.istio.io/v1alpha2 的一系列对象的创建和更新操作进行校验，如果校验失败，则拒绝创建（failurePolicy: Fail）。

结论

Galley 目前的文档非常少，主要在参考和运维指南部分有一点介绍，但 Istio 的配置难度是很著名的，因此推测随着项目的推进和普及，Galley 会持续的增强，并提供更多这方面的文档。

Istio Helm Chart 详解 - SidecarInjectorWebhook

Sun, 21 Oct 2018 19:56:03 +0800

《Istio Helm Chart 详解》系列的第五篇，介绍 Chart SidecarInjectorWebhook，负责对工作负载进行自动注入。

前言

这个 Chart 负责 Istio Sidecar 的自动注入操作相关配置。

关于自动注入操作的相关内容，可以参考官方文档中的相应章节，简单说来自动注入的两个先决条件：

Kubernetes 版本大于 1.9。
启用了 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。
还有一点，在 Kubernetes 1.10 版本中的 AlwaysPullImage 会和自动注入功能冲突

代码中可以看到，这一 Chart 生成了自动注入所需的 Deployment、Service，运行依赖的 RBAC 资源，以及自定义资源。

这个 Chart 会生成 MutatingWebhookConfiguration 类型的自定义资源，根据对命名空间以及 Pod 注解的监控对新生成的 Pod 进行注入。可以通过对这一自定义资源的修改，结合 ConfigMap istio-sidecar-injector 的内容对注入行为进行控制，后面将会进行讲解。

`values.yaml` 中的变量定义

sidecarInjectorWebhook:
  enabled: true
  replicaCount: 1
  image: sidecar_injector
  enableNamespacesByDefault: false

Chart.yaml 和 _helpers.tpl

都是标准的 Helm Chart 文件，无需说明。

RBAC 相关内容

类似其它 Chart，这里也使用 serviceaccount.yaml、clusterrolebinding.yaml 和 clusterrole.yaml 三个文件来进行赋权操作。

serviceaccount.yaml 中，引用变量除了 Chart 和 Release 两组保留变量之外，还引用到 global.imagePullSecrets，用于 ServiceAccount 的镜像拉取授权。

而 clusterrole.yaml 文件中的 rules 则表明，这个功能运行需要读取 ConfigMap，以及对前面提到的 MutatingWebhookConfiguration 资源的读写。

service.yaml

这里创建了一个开放 443 端口的服务。

depoyment.yaml

该文件所生成的 Deployment 是自动注入 Web hook 的主体。

引用变量大致如下：

Release.Namespace：Istio 所在命名空间。
template "sidecar-injector.name" .：定义在 _helpers.tpl 中，命名规则基本等同于 Release。
Chart 以及 Release 变量：Helm 内置。
global.tag 和 global.hub：镜像的前后缀
global.priorityClassName：Kubernetes PriorityClass 定义。
global.imagePullPolicy：镜像拉取策略。
replicaCount：Deployment 的副本数量。
image：镜像名称，前后缀由全局变量控制，这里不可直接指定完整镜像地址。
resources 和 global.defaultResources：优先使用 Chart 资源定义。
nodeaffinity：沿用全局节点亲和性定义。

这里会看到 Pod 模板中带有一个新的注解：sidecar.istio.io/inject: "false"，该注解用于告知 Webhook，这个 Pod 无需进行注入，具体配置方式会在后面的 ConfigMap 部分解释。

其中运行的主进程为 sidecar-injector，官方有提供详细的使用参考。对比一下会发现，除了显示的 args 之外，这一命令有一个默认的 443 端口，和前面 Service 的定义一致。

加载卷：

istio ConfigMap：它的内容被加载到 /etc/istio/config，作为 sidecar-injector 的 meshConfig 参数。
istio-sidecar-injector ConfigMap：被加载到路径 /etc/istio/inject，它代表的注入配置，用作 injectConfig 参数。
istio.istio-sidecar-injector-service-account Secret：来自于前面渲染的 ServiceAccount，会被加载到 /etc/istio/certs，用作证书使用。

mutatingwebhook.yaml

这一文件的渲染所生成的资源会对 MutatingWebhook 的执行产生一些影响。

应用变量除了 Helm 的保留变量之外，使用了本地的 enableNamespacesByDefault，来确定是否缺省为命名空间启用自动注入。如果启用了缺省注入，那么所有命名空间除非定义了 istio-injection: disabled 的标签，否则都会进行注入；如果没有启用，则只有被标签 istio-injection: enabled 的命名空间才会进行自动注入。

渲染结果是一个 MutatingWebhookConfiguration 类型的资源，该资源包含了一系列的 webhook 元素，这里用一个 sidecar-injector.istio.io webhook 定义了注入过程的触发时机为 Pod 的创建期间，命名空间则用了上面说到的表达式来进行选择。

这一配置的具体格式可以参考 OKD 官方文档。

sidecar-injector-configmap.yaml

这个模板的内容，是 Istio Sidecar 自动注入过程中的主要配置。

首先要查看 global.omitSidecarInjectorConfigMap 变量，如果这一变量为 true，则不会生成该配置。

policy 字段来自 global.proxy.autoInject：可选值包括 enabled 和 disabled，如果选择 enabled，那么缺省情况下会进行注入，除非 Pod 中注解 sidecar.istio.io/inject 为 false；disabled 则缺省不注入，除非注解 sidecar.istio.io/inject 为 true。

template 部分对 istio-init、enable-core-dump 以及 istio-proxy 三个待注入容器进行了渲染。

`istio-init`

这个镜像会完成 Istio 的流量劫持过程，其主体进程是一个用于操作 iptables 的 Shell 脚本。

如果 global.proxy_init.image 中包含了 /，则直接使用该名称；否则使用 global.hub 和 global.tag 进行拼装。

ObjectMeta 和 Spec 都来自于 Pod。ProxyConfig 和 MeshConfig 来自 istio-system 命名空间中的 istio ConfigMap。模板可以使用这些数据，对将要注入的容器和卷进行定义。

global.imagePullPolicy 则定义了镜像的拉取策略。

global.proxy.privileged 定义了初始化容器的特权模式。

`enable-core-dump`

如果 global.proxy.enableCoreDump 设置为 true，则会生成这一容器。

容器名称固定为 {{ .Values.global.hub }}/proxy_init:{{ .Values.global.tag }}。

`istio-proxy`

这一容器的镜像可以在 Pod 注解 sidecar.istio.io/proxyImage 中进行优先声明。如果没有该注解，则会使用 {{ .Values.global.hub }}/{{ .Values.global.proxy.image }}:{{ .Values.global.tag }}。

主进程为 pilot-agent，官方提供了详细的命令文档。

引用 Helm 变量包括：

global.imagePullPolicy：镜像拉取策略。
global.proxy.privileged：Sidecar 特权模式。
global.envoyStatsd：监控指标上报相关配置。

关于资源限制：

可以在容器注解中加入 sidecar.istio.io/proxyCPU 和 sidecar.istio.io/proxyMemory 来设置 Sidecar 的 Request Resource，否则会使用 proxy.resources 进行资源申请。

小结

可以看到，Sidecar 的自动配置过程有很多相关内容，包括命名空间和 Pod 的注解、标签，以及 Helm 中跨越几段的配置数据；而具体的 Sidecar 工作内容，则基本上是由 istio 这一 ConfigMap 决定的。这部分内容将会延续到 Pilot、Mixer 的相关内容之中。

参考文档

Istio Helm Chart 详解 - Ingress

Tue, 09 Oct 2018 14:25:42 +0800

这是《Istio Helm Chart 详解》系列的第三篇。开始逐个 Chart 进行阅读。

前言

全局变量之后，接下来就是 Ingress 一节了，这个 Chart 只是个兼容选项，为 Istio 提供了传统 Kubernetes Ingress 的功能。ingress.enabled 变量用于在 requirements.yaml 中控制该 Chart 是否启用。

Chart.yaml

元数据文件，无需赘述。

autoscale.yaml

该文件用于处理该模块的 HPA 对象。引用变量如下：

ingress.autoscaleMin：水平伸缩的 Pod 数量下限，另外该变量被赋值的情况下才会渲染 HPA 对象。
ingress.autoscaleMax：水平伸缩的 Pod 数量上限。
Release.Namespace：HPA 对象所在的命名空间，使用 Istio 同一值。Release 是 Helm 的保留字，用于标识该 Release 所在的命名空间。

代码中我们看到，targetAverageUtilization 设置为固定值 80。

serviceaccount.yaml

这个模板用于为 Pod 生成 Service Account——istio-ingress-service-account。

其中引用变量：

global.imagePullSecrets：全局变量定义的数组，提供给 Service Account，在拉取镜像时使用。
Chart 和 Release 都是 Helm 的内置对象。

clusterrole.yaml 和 clusterrolebinding.yaml

Kubernetes RBAC 系统使用，这是一个集群范围内生效的 ClusterRole，声明了 Ingress 中需要的两组权限，并最终和 Service Account 进行绑定：

对于 extensions.thirdpartyresources 和 extensions.ingresses 对象的读写权限。
对 configmaps、pods、endpoints 和 services 对象的读取权限。

其中引用变量：

istio.name：定义在 istio 的 _helpers.tpl 中，如果没有使用 nameOverride 进行覆盖的话，会使用 Chart 名称。
Chart 和 Release 都是 Helm 的内置对象。

deployment.yaml

这一模板用于生成 Deployment，主体部分和 Ingress Gateway 类似，使用的都是 istio/proxyv2 镜像，参数稍有区别：

istio-proxy：proxy sidecar
ingress：proxy ingress
gateways：proxy router

其中引用变量：

istio.name：定义在 istio 的 _helpers.tpl 中，如果没有使用 nameOverride 进行覆盖的话，会使用 Chart 名称。
使用 Chart 和 Release 数据生成标签。这里可以看到，固定使用 istio: ingress 提供给 Gateway Selector 进行选择。
global.hub 和 global.tag：生成镜像地址。
replicaCount：控制 Pod 数量。
global.imagePullPolicy：拉取策略。
global.priorityClassName：PriorityClass
global.proxy.envoyStatsd.enabled：如果启用，则加入 --statsdUdpAddress 参数。

global.controlPlaneSecurityEnabled：根据这一设置确定 controlPlaneAuthPolicy 设置：

# 如果启用
- --controlPlaneAuthPolicy
- MUTUAL_TLS
- --discoveryAddress
- istio-pilot:15005
# 如果没启用
- --controlPlaneAuthPolicy
- NONE
- --discoveryAddress
- istio-pilot:8080

resources 和 globale.defaultResources：优先使用 Chart 自身的资源定义，如果没有则使用缺省定义。
nodeaffinity：包含节点亲和性定义模板。

另外这里还包含了对两个 secret 的可选加载：

istio.istio-ingress-service-account：用于 RBAC 的 Service Account 证书。
istio-ingress-certs：提供 https 服务时使用这一组证书。

service.yaml

这个模板用来为 Ingress 生成服务。

引用变量包括：

istio.name：定义在 istio 的 _helpers.tpl 中，如果没有使用 nameOverride 进行覆盖的话，会使用 Chart 名称。
使用 Chart 和 Release 数据生成标签。
service.loadBalancerIP：如果指定了 IP，则使用指定 IP。
service.type：如果没有负载均衡支持，可以考虑采用 NodePort 方式。
service.annotations：可以设置一系列的键值对，通过遍历的形式为 Service 对象生成注解。
service.ports：可以定义其它的非标准端口，以数组形式供 Helm 进行遍历，例如：
```
- port: 80
name: http
nodePort: 32000
- port: 443
name: https
```

常用链接

Helm 内置对象：https://docs.helm.sh/chart_template_guide/#built-in-objects

Istio Helm Chart 详解 - 全局变量

Sun, 07 Oct 2018 10:40:16 +0800

这是《Istio Helm Chart 详解》系列的第二篇。

前言

我们在使用现有 Chart 的时候，通常都不会修改 Chart 的本体，仅通过对变量的控制来实现对部署过程的定制。Istio Helm Chart 提供了大量的变量来帮助用户进行定制。

第一篇中我们提到过，Istio Chart 分为父子两层，因此变量也具有全局和本地两级，全局变量使用保留字 global 来进行定义，子 Chart 可以通过 .Values.global 的方式引用全局变量，而主 Chart 中也可以用 chart.var 的方式为子 Chart 指定变量值，本篇会首先讲解一下 values.yaml 中涉及到的全局变量，也就是 global 一节；各个 Chart 涉及到的专属变量会留在各个 Chart 的章节中。

hub 和 tag

缺省值分别为 docker.io/istio 和 1.0.2。

这里看到版本的控制主要是在镜像层面的，Chart 自身的版本控制并不是很规矩，差评。

多数情况下，这一配置代表所有镜像的地址，具体名称一般由 {{ .Values.global.hub }}/[component]/:{{ .Values.global.tag }} 的形式拼接而成。proxy_init、Mixer、Grafana 和 Pilot 中，一旦其 image 变量中包含了路径符 /，则会弃用 global.hub，直接采用 image 的定义。

影响范围

文件	对象	备注
`charts/certmanager/templates/deployment.yaml`	Deployment：`certmanager`
`charts/galley/templates/deployment.yaml`	Deployment：`istio-galley`
`charts/gateways/templates/deployment.yaml`	所有 Gateway 的 Deployment	Container：`istio-proxy`
`charts/grafana/templates/create-custom-resources-job.yaml`	Job：`istio-grafana-post-install`
`charts/grafana/templates/deployment.yaml`	Deployment：`grafana`
`charts/ingress/templates/deployment.yaml`	Deployment：`istio-ingress`
`charts/kiali/templates/deployment.yaml`	Deployment：`kiali`
`charts/mixer/templates/deployment.yaml`	Deployment：`istio-policy`/`istio-telemetry`	Container：`istio-proxy`/`mixer`
`charts/mixer/templates/statsdtoprom.yaml`	Deployment：`istio-statsd-prom-bridge`
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`
`charts/prometheus/templates/deployment.yaml`	Deployment：`prometheus`
`charts/security/templates/cleanup-secrets.yaml`	Job：`istio-cleanup-secrets`
`charts/security/templates/create-custom-resources-job.yaml`	Job：`istio-security-post-install`
`charts/security/templates/deployment.yaml`	Deployment：`istio-citadel`
`charts/servicegraph/templates/deployment.yaml`	Deployment：`servicegraph`
`charts/sidecarInjectorWebhook/templates/deployment.yaml`	Deployment：`istio-sidecar-injector`
`charts/tracing/templates/deployment.yaml`	Deployment：`istio-tracing`
`templates/sidecar-injector-configmap.yaml`	ConfigMap：`istio-sidecar-injector`	`istio-init`、`enable-core-dump`、`istio-proxy`

k8sIngressSelector

缺省值为 ingress。

这一变量比较 Buggy。原则上讲，他仅在 ingress.enabled 为 true 的时候生效。

影响范围

`charts/pilot/templates/gateway.yaml`

这个文件中定义了一个 Gateway - istio-autogenerated-k8s-ingress，其中的 spec.selector 是这样设计的：istio: {{ .Values.global.k8sIngressSelector }}，实际上该文件中并没有针对 ingress.enabled 开关做出是否生成网关的判断，该网关一定会创建，但是只有在 Ingress Chart 中才会创建符合该条件的 Deployment，因此在 Ingress Chart 没有创建的情况下，该网关的 Selector 就无法匹配成功，也就无法生效了。

`templates/configmap.yaml`

这里会引用 ingress.enabled 进行判断，如果判断成功，则在 istio ConfigMap 对象中写入 ingressService: istio-{{ .Values.global.k8sIngressSelector }}。

k8sIngressHttps

缺省值为 false。

影响范围

`charts/pilot/templates/gateway.yaml`

如果启用该字段，会给 Gateway 定义中加入 443 端口及其 TLS 配置。

这段配置中对 /etc/istio/ingress/certs/ 下面的证书文件有依赖，因此需要启用这一选项，首先要启用 ingress.enabled，从而能够成功创建 ingress Chart 的 Deployment；另外还需要创建一个命名为 ingress-certs 的 tls secret，给 istio-ingress Deployment 进行加载。这些条件如果没有满足，LDS 会拒绝服务，从而无法提供 Ingress 功能。

proxy.image

缺省值为 proxyv2。

影响范围

`istio/templates/sidecar-injector-configmap.yaml`

其中的 ConfigMap istio-sidecar-injector 中的注入部分会使用该值作为 istio-proxy 的镜像名。

image: {{ "[[ if (isset .ObjectMeta.Annotations \"sidecar.istio.io/proxyImage\") -]]" }}
{{ "\"[[ index .ObjectMeta.Annotations \"sidecar.istio.io/proxyImage\" ]]\"" }}
{{ "[[ else -]]" }}
{{ .Values.global.hub }}/{{ .Values.global.proxy.image }}:{{ .Values.global.tag }}
{{ "[[ end -]]" }}

这段代码表明，首先会判断 Pod 的 sidecar.istio.io/proxyImage 注解，如果注解不存在，才会使用这一变量，拼接方式为：{{ .Values.global.hub }}/{{ .Values.global.proxy.image }}:{{ .Values.global.tag }}。

proxy.resources

这里为 Sidecar 定义了资源分配的方案。根据官方的伸缩性和规模调整指南：

开启访问日志（默认开启）时，为 Sidecar 每分配 1 个 vCPU 能够负担 1000 qps 的访问峰值，没有开启则 0.5 vCPU 即可负担同样峰值，节点上的 fluentd 由于需要捕获和上传日志，是主要的性能消耗者。

影响范围

文件	对象	备注
`charts/mixer/templates/deployment.yaml`	Deployment：`istio-policy`/`istio-telemetry` Container：`istio-proxy`/`mixer`
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`
`templates/sidecar-injector-configmap.yaml`	ConfigMap：`istio-sidecar-injector`	会注入到所有 Pod

proxy.concurrency

缺省值为 0。

Proxy worker 线程数量，如果设置为 0，则根据 CPU 线程/核的数量进行分配。

影响范围

文件	对象
`istio/templates/configmap.yaml`	ConfigMap：`istio`

proxy.accessLogFile

缺省值为 /dev/stdout。

Sidecar 的访问日志位置，如果设置为空字符串，则关闭访问日志功能。

影响范围

文件	对象
`templates/configmap.yaml`	ConfigMap：`istio`

proxy.privileged

缺省值为 false。

istio-init、istio-proxy 的特权模式开关。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

proxy.enableCoreDump

缺省值为 false。

如果打开，新注入的 Sidecar 会启动 CoreDump 功能，加入初始化容器 enable-core-dump。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

proxy.includeIPRanges

缺省值为 "*"。

劫持白名单，仅劫持该 CIDR 范围内的 IP。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

修改 istio-init 的 -i 参数，等价的 Pod Annotation 为 traffic.sidecar.istio.io/includeOutboundIPRanges。

proxy.excludeIPRanges

缺省值为 ""。

CIDR 范围之外的所有 IP 都会被劫持。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

修改 istio-init 的 -x 参数，等价的 Pod Annotation 为 traffic.sidecar.istio.io/excludeOutboundIPRanges。

proxy.includeInboundPorts

缺省值为 "*"。

进入端口的劫持白名单，所有从范围内端口进入 Pod 的流量会被劫持。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

修改 istio-init 的 -b 参数，等价的 Pod Annotation 为 traffic.sidecar.istio.io/includeInboundPorts。

proxy.excludeInboundPorts

缺省值为 ""。

进入端口的劫持黑名单，所有从范围外端口进入 Pod 的流量会被劫持。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

修改 istio-init 的 -d 参数，等价的 Pod Annotation 为 traffic.sidecar.istio.io/excludeOutboundIPRanges。

proxy.autoInject

缺省值为 enabled。用于指定 Sidecar 注入器的策略。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

proxy.envoyStatsd

缺省值为：

enabled: true
host: istio-statsd-prom-bridge
port: 9125

设置 Envoy 的 statsd 目标，也就是 Envoy 的 "--statsdUdpAddress 参数。某些情况下（例如没有安装 Mixer）可以关闭。

影响范围

文件	对象	备注
`charts/ingress/templates/deployment.yaml`	Deployment：`istio-ingress`
`templates/configmap.yaml`	ConfigMap：`istio`
`templates/sidecar-injector-configmap.yaml`	ConfigMap：`istio-sidecar-injector`	`istio-init`、`enable-core-dump`、`istio-proxy` 三个容器的镜像

proxy_init.image

缺省值为 proxy_init，指定初始化镜像。

前面提到过，如果这里使用一个带有路径符号 / 的镜像名称，会忽略前面的 global.hub/tag 的设置。

影响范围

文件	对象
`templates/sidecar-injector-configmap.yaml`	ConfigMap `istio-sidecar-injector`

imagePullPolicy

缺省值为 IfNotPresent。镜像的拉取策略。

影响范围

文件	对象	说明
`charts/certmanager/templates/deployment.yaml`	Deployment：`certmanager`
`charts/galley/templates/deployment.yaml`	Deployment：`istio-galley`
`charts/gateways/templates/deployment.yaml`	所有 Gateway 的 Deployment	Container：`istio-proxy`
`charts/grafana/templates/deployment.yaml`	Deployment：`grafana`
`charts/ingress/templates/deployment.yaml`	Deployment：`istio-ingress`
`charts/mixer/templates/deployment.yaml`	Deployment：`istio-policy/istio-telemetry`	Container：`istio-proxy`/`mixer`
`charts/mixer/templates/statsdtoprom.yaml`	Deployment：`istio-statsd-prom-bridge`
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`
`charts/prometheus/templates/deployment.yaml`	Deployment：`prometheus`
`charts/security/templates/deployment.yaml`	Deployment：`istio-citadel`
`charts/servicegraph/templates/deployment.yaml`	Deployment：`servicegraph`
`charts/sidecarInjectorWebhook/templates/deployment.yaml`	Deployment：`istio-sidecar-injector`
`charts/tracing/templates/deployment.yaml`	Deployment：`istio-tracing`
`templates/sidecar-injector-configmap.yaml`	ConfigMap：`istio-sidecar-injector`	Container：`istio-init`，`istio-proxy`，`enable-core-dump` 未受影响

controlPlaneSecurityEnabled

缺省值为 false。控制面是否启用 mTLS。

影响范围

文件	对象	说明
`charts/ingress/templates/deployment.yaml`	Deployment：`istio-ingress`	控制 Ingress 参数 `--controlPlaneAuthPolicy` 的取值，`MUTUAL_TLS` 或者 `NONE`
`charts/mixer/templates/config.yaml`	DestinationRule: `istio-policy` 和 DestinationRule: `istio-telemetry`	为端口 `15004` 启用 `ISTIO_MUTUAL`
`charts/mixer/templates/deployment.yaml`	Deployment：`istio-policy`/`istio-telemetry`	控制 Sidecar `istio-proxy` 参数 `--controlPlaneAuthPolicy` 的值，可选 `MUTUAL_TLS` 或者 `NONE`
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`	控制 Sidecar `istio-proxy` 参数 `--controlPlaneAuthPolicy` 的值，可选 `MUTUAL_TLS` 或者 `NONE`
`templates/configmap.yaml`	ConfigMap：`istio`	控制 Sidecar `istio-proxy` 参数 `--controlPlaneAuthPolicy` 的值，可选 `MUTUAL_TLS` 或者 `NONE`

disablePolicyChecks

缺省值 false。

禁用 Mixer 策略检查。

影响范围

文件	对象
`templates/configmap.yaml`	ConfigMap `istio`

enableTracing

缺省值 true。

设置请求跟踪。

文件	对象
`templates/configmap.yaml`	ConfigMap `istio`

影响范围

文件	对象
`templates/configmap.yaml`	ConfigMap `istio`

mtls.enabled

缺省值 false。服务间 mTLS 的缺省设置，可以使用目标规则或者服务注解进行覆盖。这一开关会控制生成一系列的 Job、ConfigMap 以及 Kubernetes RBAC 的相关内容，详情将会在 Security Chart 中讲解。

影响范围

文件	对象	说明
`charts/security/templates/configmap.yaml`	ConfigMap：`istio-security-custom-resources`
`charts/security/templates/create-custom-resources-job.yaml`	ServiceAccount: `istio-security-post-install-account` ClusterRole: `istio-security-post-install-istio-system` ClusterRoleBinding: `istio-security-post-install-role-binding-istio-system` Job：`istio-security-post-install`	这几个对象都需要启动这一开关才会创建

imagePullSecrets

缺省为空。

用于为 ServiceAccount 分配镜像拉取过程所需的凭证。

影响范围

文件	对象
`charts/certmanager/templates/serviceaccount.yaml`	ServiceAccount: `certmanager`
`charts/galley/templates/serviceaccount.yaml`	ServiceAccount: `istio-galley-service-account`
`charts/gateways/templates/serviceaccount.yaml`	所有 Gateways 自动生成的 ServiceAccount
`charts/ingress/templates/serviceaccount.yaml`	ServiceAccount: `istio-ingress-service-account`
`charts/kiali/templates/serviceaccount.yaml`	ServiceAccount: `kiali-service-account`
`charts/mixer/templates/serviceaccount.yaml`	ServiceAccount: `istio-mixer-service-account`
`charts/pilot/templates/serviceaccount.yaml`	ServiceAccount: `istio-pilot-service-account`
`charts/prometheus/templates/serviceaccount.yaml`	ServiceAccount: `prometheus`
`charts/security/templates/serviceaccount.yaml`	ServiceAccount: `istio-citadel-service-account`
`charts/sidecarInjectorWebhook/templates/serviceaccount.yaml`	ServiceAccount: `istio-sidecar-injector-service-account`

arch

缺省值：

amd64: 2
s390x: 2
ppc64le: 2

用于 Kubernetes 的节点亲和性调度过程。

这里列出了几种支持的服务器架构，并给出了优先级。详情请参看本文系列第一篇。

oneNamespace

缺省值 false。

如果设置为 true，会对控制面管理的应用命名空间进行限制。如果没有设置，则监控所有命名空间。

影响范围

文件	对象
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`

设置 Pilot discovery 的 -a 参数。这一参数取值为监控的命名空间名称，目前会选用 Istio 所在的命名空间。

configValidation

缺省值 ture。用于配置是否开启服务端的配置验证。该选项开启之后，会生成一个 ValidatingWebhookConfiguration 对象，并被包含到 Galley 的配置之中，从而启用校验功能。

影响范围

文件	说明
`charts/galley/templates/validatingwehookconfiguration.yaml.tpl`	ValidatingWebhookConfiguration: `istio-galley`

meshExpansion

缺省值为 false。如果启用，Pilot 和 Citadel 会在 Ingress Gateway 上公开服务。

影响范围

文件	对象	说明
`charts/pilot/templates/gateway.yaml`	Gateway：`meshexpansion-gateway`	用于公开服务的 Gateway
`charts/pilot/templates/meshexpansion.yaml`	VirtualService：`meshexpansion-pilot`	Pilot 的 VirtualService
`charts/security/templates/meshexpansion.yaml`	VirtualService：`meshexpansion-citadel`	Citadel 的的 VirtualService

meshExpansionILB

缺省值为 false。Pilot 和 Citadel 的 mTLS 和明文端口会在内部网关进行公开。

影响范围

文件	对象	说明
`charts/pilot/templates/gateway.yaml`	Gateway：`meshexpansion-ilb-gateway`	用于公开服务的 Gateway
`charts/pilot/templates/meshexpansion.yaml`	VirtualService：`ilb-meshexpansion-pilot`	Pilot 的 VirtualService
`charts/security/templates/meshexpansion.yaml`	VirtualService：`meshexpansion-ilb-citadel`	Citadel 的的 VirtualService

defaultResources

缺省值：

requests:
  cpu: 10m

为 Istio 组件提供一个最小的资源定义，以便 HPA 工作方便，每个组件可以定义自己的资源定义进行覆盖。

影响范围

文件	对象	说明
`charts/galley/templates/deployment.yaml`	Deployment：`istio-galley`
`charts/gateways/templates/deployment.yaml`	所有网关创建的 Deployment
`charts/grafana/templates/deployment.yaml`	Deployment：`grafana`
`charts/ingress/templates/deployment.yaml`	Deployment：`istio-ingress`
`charts/kiali/templates/deployment.yaml`	Deployment：`kiali`
`charts/mixer/templates/deployment.yaml`	Deployment：`istio-policy`/`istio-telemetry`	Container：`istio-proxy`/`mixer`
`charts/mixer/templates/statsdtoprom.yaml`	Deployment：`istio-statsd-prom-bridge`
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`	Container：`istio-proxy`/`discovery`
`charts/prometheus/templates/deployment.yaml`	Deployment：`prometheus`
`charts/security/templates/deployment.yaml`	Deployment：`istio-citadel`
`charts/servicegraph/templates/deployment.yaml`	Deployment：`servicegraph`
`charts/sidecarInjectorWebhook/templates/deployment.yaml`	Deploymet: `istio-sidecar-injector`
`charts/tracing/templates/deployment.yaml`	Deployment：`istio-tracing`

hyperkube

缺省值：

hub: quay.io/coreos
tag: v1.7.6_coreos.0

用于创建 CRD 的容器镜像。

影响范围

文件	对象
`charts/grafana/templates/create-custom-resources-job.yaml`	Job：`istio-grafana-post-install`
`charts/security/templates/cleanup-secrets.yaml`	Job：`istio-cleanup-secrets`
`charts/security/templates/create-custom-resources-job.yaml`	Job：`istio-security-post-install`

priorityClassName

Kubernetes 1.11.0 以上有两个 PriorityClass，用这种方式创建 Istio 组件 Pod，可以防止因较低的优先级被杀掉。

影响范围

文件	对象
`charts/certmanager/templates/deployment.yaml`	Deployment：`certmanager`
`charts/galley/templates/deployment.yaml`	Deployment：`istio-galley`
`charts/gateways/templates/deployment.yaml`	所有网管创建的 Deployment
`charts/grafana/templates/deployment.yaml`	Deployment：`grafana`
`charts/ingress/templates/deployment.yaml`	Deployment：`istio-ingress`
`charts/kiali/templates/deployment.yaml`	Deployment：`kiali`
`charts/mixer/templates/deployment.yaml`	Deployment：`istio-policy/istio-telemetry`
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`
`charts/prometheus/templates/deployment.yaml`	Deployment：`prometheus`
`charts/security/templates/deployment.yaml`	Deployment：`istio-citadel`
`charts/servicegraph/templates/deployment.yaml`	Deployment：`servicegraph`
`charts/sidecarInjectorWebhook/templates/deployment.yaml`	Deployment：`istio-sidecar-injector`
`charts/tracing/templates/deployment.yaml`	Deployment：`istio-tracing`

crds

缺省值 true。

如果使用的是 Helm 2.10 以上的 helm install，或者是 helm template 方式的安装，应该设置为 true；如果 Helm 版本小于 2.9，必须设置为 false，并手工执行 kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml 来首先创建 CRD。

影响范围

文件	说明
`templates/crds.yaml`	随这一开关确定是否创建所有 CRD

小结

本节中很多涉及到下层 Chart 的内容并未深入，会在子 Chart 的相关章节中尝试进一步说明。

Istio Helm Chart 详解 - 概述

Sat, 06 Oct 2018 12:55:00 +0800

前言

Helm 是目前 Istio 官方推荐的安装方式，除去安装之外，还可以利用对输入值的一些调整，完成对 Istio 的部分配置工作。官方提供了 Istio 的 Helm 部署方式，侧重于快速启动，而这一组文章将会采用由上至下的顺序，基于 Istio 1.0.2 版本的 Helm Chart 做一系列的讲解。

Istio 的 Helm Chart 分为两个大分支：istio 和 istio-remote，后者为多集群部署方式，这里暂不涉及，后面的内容围绕 istio 展开。

总体结构

Istio Chart 是一个总分结构，其分级结构和设计结构是一致的，这里做一个简单的说明。

Chart.yaml

Chart 的基础信息，这里看到 1.0.2 的 Release 中，version 的值还是 1.0.1；要求的 Tiller 版本要大于等于 2.7.2-0。

values-*.yaml

这里提供了一组 values 文件，提供 Istio 在各种场景下的关键配置范本。对 Istio 的定制可以从 values.yaml 的改写开始，完成后可以使用 helm template 命令来生成最终的部署文件供 kubectl 使用。values.yaml 文件的一些细节可以参考官方文档。

values-istio-auth-galley.yaml：启用控制面 mTLS；缺省打开网格内的 mTLS；启用 Galley。
values-istio-auth-multicluster.yaml：多集群配置；启用控制面 mTLS；缺省打开网格内的 mTLS；禁用自签署证书。
values-istio-auth.yaml：启用控制面 mTLS；缺省打开网格内的 mTLS。
values-istio-demo-auth.yaml：启用控制面 mTLS；缺省打开网格内的 mTLS；激活 Grafana、Jaeger、ServiceGraph 以及 Galley；允许自动注入。
values-istio-demo.yaml：激活 Grafana、Jaeger、ServiceGraph 以及 Galley；允许自动注入。
values-istio-galley.yaml：启用 Galley 和 Prometheus。
values-istio-gateways.yaml：这是一个样例，可以用这种形式定义新的 Gateway。
values-istio-multicluster.yaml：多集群配置，禁用自签发证书。
values-istio-one-namespace-auth.yaml：
values-istio-one-namespace.yaml：启用控制面 mTLS；缺省打开网格内的 mTLS；
values-istio.yaml：oneNameSpace 设置为 True，让 Pilot 只监控单一的 Namespace，目前的情况是只监控 Istio 的部署命名空间。此处的 istiotesting 似乎是个 Issue。
values.yaml：罗列了（可能）所有变量，也是我们做定制的基础。

requiremtens.yaml

这个文件用于管理 Chart 的依赖关系，Istio 的各个组件就是在这里定义的，并且可以通过变量进行控制。

templates

_affinity.tpl

该文件会生成一组节点亲和/互斥元素，供各个组件在渲染 YAML 时候使用。

nodeAffinityRequiredDuringScheduling：仅在本文件中使用。这里规定了对节点的要求，values.yaml 中的 global.arch 变量中列出了一系列的主机架构，只有出现在这一列表中，且对应值大于 0 的节点，才会将 Pod 调度到该节点上。
nodeAffinityPreferredDuringScheduling：仅在本文件中使用。这里规定了调度优先级，为各种架构的节点分配了权重。

nodeaffinity：包含了上面谈到的两个模板，合成为一个节点亲和性的代码段，供外部文件使用，影响范围包括：

文件名	涉及对象
`charts/galley/templates/deployment.yaml`	Deployment：`istio-galley`。
`charts/gateways/templates/deployment.yaml`	所有 gateways Chart 生成的 Deployment。
`charts/grafana/templates/deployment.yaml`	Deployment：`grafana`。
`charts/ingress/templates/deployment.yaml`	Deployment：`istio-ingress`。
`charts/mixer/templates/deployment.yaml`	Deployment：`istio-policy`
`charts/pilot/templates/deployment.yaml`	Deployment：`istio-pilot`
`charts/prometheus/templates/deployment.yaml`	Deployment：`prometheus`
`charts/security/templates/deployment.yaml`	Deployment：`istio-citadel`
`charts/servicegraph/templates/deployment.yaml`	Deployment：`servicegraph`
`charts/sidecarInjectorWebhook/templates/deployment.yaml`	Deployment：`istio-sidecar-injector`
`charts/tracing/templates/deployment.yaml`	Deployment：`istio-tracing`

_helpers.tpl

这个文件并不特别，创建了四个变量，供 Helm 使用。

sidecar-injector-configmap.yaml

这里定义了 ConfigMap 对象 istio-sidecar-injector，为 sidecarInjectorWebhook 提供配置支持，在全局变量 omitSidecarInjectorConfigMap 为 False 的时候进行渲染，这一参数会用在生成新的 Gateway 之类的调整功能上，防止创建多余的 ConfigMap。这里可以看到使用各种变量拼装而成的注入模板，用于为被注入 Pod 提供初始化和 Sidecar 容器的支持。其中涉及的变量会在后文中进行讲解。

configmap.yaml

这个文件定义了 ConfigMap 对象 istio，该对象会随 Pilot 一同创建，也就是说它是 Pilot 的依赖项。其中所涉变量也同样会在其他文章中进行讲解。

charts

certmanager：一个基于 Jetstack Cert-Manager 项目的 ACME 证书客户端，用于自动进行证书的申请、获取以及分发
galley：Istio 利用 Galley 进行配置管理工作。
gateways：使用 Gateways 一节的配置，可以实现多个 Gateway Controller
grafana：图形化的 Istio Dashboard。
ingress：一个遗留设计，缺省关闭，v1alpha3 之后建议弃用。
kiali：带有分布式跟踪、配置校验等多项功能的 Dashboard。
mixer：
pilot：
prometheus：
security：
servicegraph：
sidecarInjectorWebhook：自动注入 Webhook 的相关配置
tracing：Jaeger 的分布式跟踪相关配置。

小结

本篇主要讲述的是整体结构以及顶层对象的一些内容。后面将会分几篇文章讲讲各种变量的应用以及各个 Chart 的配置。

换马甲：十分钟 Helm 变 Operator

Thu, 30 Aug 2018 10:41:42 +0800

Operator 是一种将传统运维思路转换为 Kubernetes CRD 控制的方法，利用 CRD 对软件部署和配置进行定义，整个部署和管理过程在 Kubernetes 角度上来看，都是一个可见、可审计的行为，这无疑对运维工作是大有裨益的。CoreOS 也提供了 Operator Framwork 用于进行 Operator 的开发，不过门槛还是稍高的。如果放低要求，是否能有一个折衷方案？

CoreOS 为最近加入 CNCF 的 Helm 提供了一个小工具，可以无需编程操作，较为方便的将 Helm Chart 转换为 Operator，并将原有的 values.yaml 更替为 CR 资源进行操作，对于无状态应用的部署流程，可以说是比较便利了。下面就随便举个例子，看看这马甲是怎么换的。

目前版本相当幼稚，看看就好了。

准备工作

首先是一个可操作的 Kubernetes 集群，要求版本为 1.9+。接下来要有一个可操作的 Helm 客户端（无需 Tiller 部署），用于下载 Chart。

使用 git 获取 Helm app operator kit：

$ git clone https://github.com/operator-framework/helm-app-operator-kit.git
Cloning into 'helm-app-operator-kit'...
...
Resolving deltas: 100% (58/58), done.

镜像构建

下载一个实验 Chart 并解压：

$ helm fetch stable/memcached
$ tar xf memcached-2.2.0.tgz
$ ls -la
...
-rw-r--r--   1 dustise  wheel    680  8 30 11:50 Dockerfile
...
drwxr-xr-x  10 dustise  wheel    320  8 30 11:50 helm-app-operator
drwxr-xr-x   7 dustise  wheel    224  8 30 11:52 memcached
...

这里的 Dockerfile 可以略微关注一下：

FROM golang:1.10 as builder
...
RUN curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
...
RUN CGO_ENABLED=0 GOOS=linux go build -o bin/operator cmd/helm-app-operator/main.go
...
FROM alpine:3.6
...
COPY --from=builder /go/src/github.com/operator-framework/helm-app-operator-kit/helm-app-operator/bin/operator /operator
...
CMD ["/operator"]

一个典型的分段构建过程。在 Go 环境中生成可执行文件用于最终镜像的执行。

使用 Dockerfile 进行构建：

docker build -t your-repo:25000/helm/memcached-operator \
    --build-arg HELM_CHART=memcached \
    --build-arg API_VERSION=anywhere.io/v1alpha1 \
    --build-arg KIND=memcached .

HELM_CHART：我们之前解压的 Chart 目录。
API_VERSION：即将用到的自定义资源的 API 组和版本。
KIND：自定义资源名称。

Docker 构建完成之后，将新镜像 Push 到 Kubernetes 可访问的镜像库中。

Operator 部署

构建成功之后，进入 helm-app-operator/deploy 目录，要部署 Operator，首先要修改几个文件。

rbac.yaml

这是 Operator 运行所需的权限设置文件，根据前面的配置，我们需要给他加入两个权限：namespace 以及新建的 CRD 的操作权限。

这里的 RoleBinding 只是绑定到了 default 命名空间的 default ServiceAccount，如果要给 Operator Pod 单独赋权，就要对 subject 进行修改。

文件编辑结束后，就可以使用 kubectl apply 提交到集群运行。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: helm-app-operator
rules:
...
  - secrets
  - namespaces
  verbs:
  - "*"
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  verbs:
  - "*"
...
- apiGroups:
  - anywhere.io
  resources:
  - "*"
  verbs:
  - "*"

crd.yaml

接下来就是自定义资源的定义了。这里需要和前面我们制定的 API 结构相吻合

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: memcacheds.anywhere.io # 资源名 + 组名
spec:
  group: anywhere.io # 组
  names:
    kind: memcached # 对象
    listKind: memcachedList #列表
    plural: memcacheds # 复数形式
    singular: memcached # 单数形式
  scope: Namespaced
  version: v1alpha1 # 版本

同样的，使用 kubectl apply 提交这一定义给 Kubernetes 集群。

operator.yaml

这个文件很简单，是一个 Deployment 对象定义，修改一下镜像名即可，如果 rbac.yaml 中修改了绑定账号，这里也需要修改 Operator 的运行账号。

最后，用 kubectl apply deploy/operator.yaml，即可启动 Operator 的运行了。可以使用 kubectl get po -w 获取运行状况。

创建应用实例

deploy 目录中还有另外一个文件：cr.yaml，就是我们的自定义资源实例文件。过去需要在 Chart 的 values.yaml 中编写的内容，现在需要在这里完成了。通过 helm inspect stable/memcached 命令，可以看到其中支持的参数列表。这里我们可以设置一下，用来创建一个 3 实例的集群：

apiVersion: anywhere.io/v1alpha1
kind: memcached
metadata:
  name: memcached-yy
  labels:
    app: example-app
spec:
  replicaCount: 3

使用 kubectl apply 提交之后，可以看到集群上开始创建这一实例：

$ kubectl get po
...
helm-app-operator-memcached-yy-0      1/1       Running            0          10h
helm-app-operator-memcached-yy-1      1/1       Running            0          10h
helm-app-operator-memcached-yy-2      1/1       Running            0          10h
...

这里 Operator Pod 可能会崩溃，删除即可正常工作😄。

查询实例情况：

$ kubectl get memcached
NAME           CREATED AT
memcached-r    10h
memcached-yy   10h

删除实例

$ kubectl delete memcached memcached-yy
memcached.anywhere.io "memcached-yy" deleted

再次使用 kubectl get po，会发现对应 Pod 已经删除。

结语

CoreOS 再次提供了一个有趣的方向，有效的降低了 Operator 的入门门槛。但是这一方案除了成熟度相当不足之外，Helm 本身对运维的支持其实也是非常弱的，对有状态应用是无论如何不能使用这种方式来进行运维的。——马甲，只是马甲。

Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold

Tue, 26 Jun 2018 11:29:18 +0800

原文：Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold

作者：Shahidh K Muhammed

TL;DR

Draft

向 K8S 集群部署代码（自动“构建-推送-部署”）。
使用 Draft 打包支持的语言的代码可以不编写 Dockerfile 或者 K8S 元数据文件直接进行部署。
需要 draft 以及 helm 客户端，集群要部署 tiller，本地 Docker，Docker 仓库。

Gitkube

向 K8S 集群部署代码（自动“构建-推送-部署”）。
Git 推送触发部署，本机无依赖。
Git 仓库中需要提供 Dockerfile 以及 K8S 元数据文件，集群中需部署 gitkube。

Helm

在 K8S 集群上对 Chart（其中包含一个应用的所有 K8S 资源定义文件）进行部署和管理。
提供了很多通用应用（例如 MySQL、Mediawiki 等）的 Chart。
客户端需要 Helm，服务端需要 Tiller，Chart 定义可以在本地也可以在仓库中保存。

Ksonnet

在 jsonnet 上定义 K8S 元数据文件，然后进行部署。
可以对通用模式（例如 Deployment + Service）和应用栈（例如 Redis）进行复用。
需要 jsonnet 知识，安装 ksonnet 客户端。

Metaparticle

使用 Metaparticle 支持的语言编写代码，然后部署到 K8S 集群（自动“构建-推送-部署”）
在应用的代码中直接定义容器化和 K8S 相关内容，傻瓜化的编写过程，无需编写 Dockerfile 或者 Yaml。
需要本地 Docker 部署，需要相关语言的库。

Skaffold

向 K8S 集群部署代码（自动“构建-推送-部署”）。
监控源代码变更，变更发生后就会触发“构建-推送-部署”过程，Pipeline 可配置。
需要 Skaffold 客户端、Dockerfile、K8S 元数据文件、Skaffold 元数据文件，本地 Docker 以及私库。

下面进入一点细节。

当今的 Kubernetes 炙手可热，用户们寻求更多的方式和流程来进行 Kubernetes 集群上的应用部署。kubectl 已经成为底层工具，用户需要更易用的流程。Draft、Gitkube、Helm、Ksonnet、MetaParticle 以及 Skaffold 都是用来帮助开发人员在 Kubernetes 上进行应用构建和部署的工具。

Draft、Gitkube 和 Skaffold 减轻了开发人员的负担，在构建应用的过程中，能够更快的在 Kubernetes 上运行起来。Helm 和 Ksonnet 提供了定义应用、更新版本、选择不同集群等功能，在应用构建完成，进入发布就绪状态之后，这两个工具可以提高部署能力。Metaparticle 是比较独特的一个，他把包含 yaml、dockerfile 这些东西集成到业务代码之中。

所以用户自身的用例中如何进行选择？

正文

Draft

在任何 Kubernetes 集群上简化应用的开发和部署。

顾名思义，Draft 让面向 Kubernetes 的应用开发变得简单。官方宣称，对于运行在 Kubernetes 上的应用，Draft 这一工具是帮助开发过程而非部署的。Draft 文档中推荐使用 Helm 进行应用部署。

他的目标是：开发人员还在开发调试之中的本地的代码，不经提交到版本控制系统，直接运行到 Kubernetes 集群上。开发人员对 Draft 发布的应用变更满意之后，才提交给版本控制系统。

Draft 不是用来在生产环境上进行部署的，他的用意就是在于快速推进面向 Kubernetes 环境的开发过程。他内部使用 Helm 来进行变更，因此他和 Helm 的集成是非常紧密的。

架构

如上图所示，Draft 客户端是一个关键组件。它感知代码的变化，然后从 Repo 中获取对应的 Pack。Pack 是一个 Dockerfile 和 Helm chart 的合体，他们一起定义了应用的运行环境。Pack 定义之后保存在 Repo 中。用户可以定义自己的 Pack 和 Repo，这两个对象可以保存在本地，也可以在 Git 仓库之中。

只要有对应的 Pack，任何一个包含源码的目录都可以进行部署。使用 draft create 处理目录之后，会在目录中添加 Dockerfile、Helm chart 以及 draft.toml 文件，draft up 能够构建 Docker 镜像，推送到私库，然后使用 Helm Chart 部署应用。每次代码变更之后，再次执行这一命令，就会产生一个新的部署。

draft connect 命令能够进行端口转发，以此在本地获取容器的日志。他还能够和 nginx-ingress 集成，为上面部署的应用提供域名。

从 0 到 Kubernetes

下面是一个用 Draft 把 Python 应用运行到 K8S 集群上的步骤。可以从官方文档获得更详细的指导。

先决条件

Kubernetes 集群（包括 kubectl）
Helm 客户端
Draft 客户端
Docker

Docker 镜像库

$ helm init
$ draft init
$ draft config set registry docker.io/myusername
$ git clone https://github.com/Azure/draft
$ cd draft/examples/example-python
$ draft create
$ draft up
## 代码修改
$ draft up

用例

开发运行在 Kubernetes 上的应用。
用于在提交到版本控制之前的“内部流程”。
预 CI：应用完成 Draft 过程之后，可以由 CI/CD 接管。
不应该用在生产环境部署环节。

Gitkube

使用 git push 构建 Docker 镜像并在 Kubernetes 上进行部署。

Gitkube 是一个用来构建 Docker 镜像并向 Kubernetes 上部署的工具，他的起点就是 git push，不像 Draft，他不需要客户端，只需在集群上独立运行。

任何带有 Dockerfile 的代码仓库，都可以使用 gitkube 进行部署。Gitkube 安装和部署在集群之上，开发人员可以获取一个包含 git URL 的 CRD。开发人员推送到仓库的代码，会触发集群一端的 Docker Build 以及 Kubectl 发布流程。可以使用 kubectl 或 helm 等类似工具给应用创建应用元数据。

Gitkube 的重点是即插即用的安装过程，以及沿用既有的知名工具（git 以及 kubectl）。对需要部署的仓库没有什么假设。Docker build 的上下文以及 Dockerfile 所在路径，都可以进行配置。Git 连接认证是通过 SSH 公钥进行的。任何时候代码发生变更、提交和推送，都会触发后面的构建和部署过程。

架构

集群侧有三个组件，一个远程 CRD 可以定义针对一个远端 URL 发生 Push 的时候如何应对，gitkubed 构建 Docker 镜像并更新部署，gitkube-controller 会监控 CRD，随变化更新 gitkubed。

在集群上创建这些对象之后，开发者就可以使用 kubectl 来创建应用的定义了。创建一个 remote 对象，告诉 gitkube，当 git push 发生时该做什么。Gitkube 把远程 url 写回到 remote 对象的状态字段中。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群（包括 kubectl）。
- git。
- 集群上安装好 gitkube （kubectl create）。

下面是将应用提交到 Kubernetes 的步骤，也包含了 gitkube 的安装过程。

已经过时

$ git clone https://github.com/hasura/gitkube-example
$ cd gitkube-example
$ kubectl create -f k8s.yaml
$ cat ~/.ssh/id_rsa.pub | awk '$0="  - "$0' >> "remote.yaml"
$ kubectl create -f remote.yaml
$ kubectl get remote example -o json | jq -r '.status.remoteUrl'
$ git remote add example [remoteUrl]
$ git push example master
## 编辑代码
## 提交和推送

用例

使用 Git 进行简单的部署，无需 Docker Build。
在 Kubernetes 上开发应用。
开发过程中，WIP 分支可以多次提交，迅速反馈。

Helm

Kubernetes 的包管理系统。

Helm 使用一种称为 Chart 的形式，来管理 Kubernetes 上的应用。Helm 为应用创建 YAML 并进行版本化操作，这样可以对包含 Deployment 在内的所有对象进行回滚。Chart 可以包含 Deployment、Service 以及 Configmap 等。Chart 的模板允许用户方便的修改部署细节，另外还支持带有依赖关系的复杂应用。

Helm 的主要目标是在生产环境中部署和管理应用程序。对比 Draft 和 Gitkube，Helm 不是用来开发的，而是用来部署的。另外现在有大量的预构建 Chart 可以供 Helm 使用。

架构

首先看看 Chart。我们之前说过，Chart 之中包含一系列的信息，这些信息是部署应用到 Kubernetes 中的必要条件。其中可能包含 Deployment、Service、Configmap、Secret 以及 Ingress 等。所有的定义都是以 Yaml 文件模板的形式出现，另外还包含嵌套的依赖 Chart。Chart 可以在 Chart 仓库中发布。

Helm 有两个主要组件，分别是 Helm 客户端和 Tiller 服务器。客户端用于管理 Chart 和仓库，并且和 Tiller 服务器进行通信，来完成对 Chart 的部署和管理。

Tiller 组件运行在集群上，和 Kubernetes API 服务器打交道，进行对象的实际操作。

Helm 不处理源码，用户需要使用 CI/CD 系统来构建镜像，然后用 Helm 来部署合适的镜像。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群
- Helm 客户端

接下来是一个在 Kubernetes 集群上使用 Helm 部署 Wordpress 博客的例子：

$ helm init
$ helm repo update
$ helm install stable/wordpress
## 更新版本
$ helm upgrade [release-name] [chart-name]

用例

打包：包含多个 Kubernetes 对象的复杂应用可以集中在一起。
可复用的 Chart 仓库。
可以轻易部署在多个环境上。
可嵌套的结构，能够解决依赖关系。
参数化的模板。
容易复用。
持续交付的最后一公里。
只能部署已经构建完成的镜像。
具备生命周期管理能力，可以管理多个 Kubernetes 对象的升级和回滚。

Ksonnet

一个支持客户按操作的框架，提供可扩展的 Kubernetes 配置。

Ksonnet 是为 Kubernetes 定义应用配置的另一种方法。它并没有使用 Kubernetes 世界中常用的 YAML 语言，改用一种称为 Jsonnet 的 JSON 模板语言。Ksonnet 客户端最终会渲染出 YAML 文件并提交给集群。

这一系统的主要功能就是定义可复用的组件，并利用该工具渐进式的进行程序构建。

架构

基础的构建单位被称为 part，part 可以协作构成 prototype。一个 prototype 配合参数之后，就成为了一个 component，component 可以聚合在一起，成为一个 application。application 可以部署到多个 environment 之中。

最基础的流程就是使用 ks init 命令创建一个应用目录，使用 ks generate 生成（或者也可以自行编写）component 的元数据文件，使用 ks apply <env> 命令可以把应用部署到集群/环境之中。可以用 ks env 命令来管理不同的环境。

简而言之，Ksonnet 帮助用户定义和管理应用，他把应用视作一系列使用 Jsonnet 的组件进行管理，并部署在不同的 Kubernetes 集群上。

跟 Helm 类似，Ksonnet 不和源码发生关系，他是一个使用 Jsonnet 为 Kubernetes 定义应用的工具。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群
- ksonnet 客户端

接下来是一个留言板例子：

$ ks init
$ ks generate deployed-service guestbook-ui \
     --image gcr.io/heptio-images/ks-guestbook-demo:0.1 \
     --type ClusterIP
$ ks apply default
## 变更
$ ks apply default

用例

使用 Jsonnet 编写配置很有弹性。
打包：复杂配置可以用匹配组件的方式集成起来。
可复用的组件和原型库：避免重复。
方便的多环境部署。
CD 的最后一步。

Metaparticle

为容器和 Kubernetes 而生的云原生标准库。

Metaparticle 将自己定位于云原生应用的标准库，他内置了经过验证的分布式系统模式，而开发人员可以用习惯的编程语言通过原语的方式方便的采用这些先进模式。

他提供了简易的语言接口，帮助用户构建可以容器化并部署到 Kubernetes 上的应用，这些应用会直接兼容负载均衡等基础设施。无需自行编写 Dockerfile 或者 Kubernetes 元数据文件，所有相关内容都在代码中的用原语来体现。

例如一个 Python Web 应用，可以给 main 函数加入一个叫做 containerize 的 Decorator（从 metaparticle 中 import）。当执行这段 Python 代码的时候，会构建 Docker 镜像并部署到 Decorator 参数中提到的 Kubernetes 集群上。缺省集群定义来自 kubectl 上下文。所以切换环境就和切换当前上下文是等价的。

在 NodeJS、Java 以及 .NET 上也提供了类似的原语。另外还正在开发更多的语言支持。

架构

各种语言的 metaparticle 库都包含所需的原语，绑定了构建 Docker 镜像、推送到私库、创建 Kubenretes yaml 文件并在集群上部署的代码。

Metaparticle 包中内置了各种语言用来构建容器的支持。而 Metaparticle Sync 则包含了在不同机器上运行的不同容器进行同步的能力。

目前支持的语言包括：JavaScript/NodeJS、Python、Java 以及 .NET。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群。
- 特定语言的 Metaparticle 库。
- Docker。
- Docker 私库。

一个只包含相关内容的 Python 例子，可以使用这些代码构建 Docker 镜像，并在 Kubernetes 上进行部署。

@containerize(
    'docker.io/your-docker-user-goes-here',
    options={
        'ports': [8080],
        'replicas': 4,
        'runner': 'metaparticle',
        'name': 'my-image',
        'publish': True
    })
def main():
    Handler = MyHandler
    httpd = SocketServer.TCPServer(("", port), Handler)
    httpd.serve_forever()

用例

只想开发应用，不想担心 Kubernetes YAML 或者 Dockerfile。
不想掌握多种工具和文件格式，又想搭上容器和 Kubernetes 快车的开发人员。
快速开发可复制可负载均衡的服务。
在多个分布式副本之间进行同步，例如加锁、或者选举操作。
简单开发云原生模式的应用，例如分片系统。

Skaffold

简单可重复的 Kubernetes 开发。

Skaffold 能够处理构建镜像、推送镜像以及在 Kubernetes 上进行部署。跟 Gitkube 类似，任何包含 Dockerfile 的目录都可以用 Skaffold 部署到 kubernetes 集群上。

Skaffold 会在本地构建 Docker 镜像，推送到私库，然后使用 skaffold 客户端进行部署。他还会监测目录，如此一来，目录中的代码一旦发生变化，就会触发重新构建和部署。这个过程还会从容器中获取日志。

可以使用 YAML 文件来构建、推送、部署的 Pipeline，所以开发者可以混合使用合适的工具，例如 Docker build 和 Google Container Builder，Kubectl 和 Helm 等。

架构

Skaffold 客户端做了所有的工作。他会查找一个叫做 skaffold.yaml 的文件，其中包含了必须完成的任务。一个典型的例子就是在 skaffold dev 运行的目录中查找 Dockerfile 构建 Docker 镜像，并使用 sha256 进行标记，推送镜像，把镜像设置到 Kubernetes 元数据文件之中，最后发布到集群上。这一系列动作会被目录中的变更所触发。来自部署容器的日志会出现在同一个 Watch 窗口中。

Skaffold 和 Draft 和 Gitkube 很像，但是更具弹性，如上图所示，他能管理不同的“构建-推送-部署”流程。

从 0 到 Kubernetes

先决条件
- Kubernetes 集群
- Skaffold 客户端
- Docker
- Docker 镜像库

下面的步骤，部署一个 Go 编写的 Hello World 应用：

$ git clone https://github.com/GoogleCloudPlatform/skaffold
$ cd examples/getting-started
## 编辑 skaffold.yaml，加入 Docker 仓库
$ skaffold dev
## 打开新终端: 编辑代码

用例

方便部署。
迭代构建——持续的构建-发布流程。
为 Kubernetes 开发应用。
在 CICD 流程中定义“构建-推送-部署”流程。

Istio 0.8 的 Helm Chart 解析

Mon, 04 Jun 2018 09:39:10 +0800

儿童节期间，拖拉了一个多月的 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 的几个服务端口。

Helm 简介

Thu, 30 Mar 2017 08:47:48 +0800

概念

Chart：一个 Helm 包，其中包含了运行一个应用所需要的工具、资源定义等，还可能包含 Kubernetes 集群中的服务定义，类似 Homebrew 中的 formula，APT 的 dpkg 或者 Yum 的 RPM 文件，
Release: 在 Kubernetes 集群上运行的 Chart 的一个实例。在同一个集群上，一个 Chart 可以安装很多次。每次安装都会创建一个新的 release。例如一个 MySQL Chart，如果想在服务器上运行两个数据库，就可以把这个 Chart 安装两次。每次安装都会生成自己的 Release，会有自己的 Release 名称。
Repository：用于存放和共享 Chart 的仓库。

简单说来，Helm 整个系统的主要任务就是，在仓库中查找需要的 Chart，然后把 Chart 以 Release 的形式安装到 Kubernetes 之中

组件

Helm Client：客户端，具有对 Repository、Chart、Release 等对象的管理能力。
Tiller Server：负责客户端指令和 Kubernetes 集群之间的沟通，根据 Chart 定义，生成和管理各种相对应的 API Object。
Repository：Chart 的仓库，基本上就是索引文件 + Chart 压缩包的一个存储托管。

安装

环境要求

可用的 Kubernetes 集群
正确的可用的 kubectl config

简单做法

只要一个简单的 helm init 命令，就可以自动完成 Tiller 的安装，以及 Helm 本地设置。

手工做法

在一个网络不通，或者受控网络里面，init 可能无法正常工作，所以我们需要手工完成 Init 工作。

客户端：helm init -c，会跳过 Tiller 部分，仅进行客户端的安装。
- ~/.helm 中保存了对 Repository 的定义，各个 Repository 的索引的缓存，以及 Chart 压缩包的缓存。

Tiller：下面是 Tiller 的运行 YML：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
generation: 1
labels:
app: helm
name: tiller
name: tiller-deploy
namespace: kube-system
spec:
replicas: 1
selector:
matchLabels:
  app: helm
  name: tiller
strategy:
rollingUpdate:
  maxSurge: 1
  maxUnavailable: 1
type: RollingUpdate
template:
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
spec:
  containers:
  - env:
    - name: TILLER_NAMESPACE
      value: kube-system
    image: gcr.io/kubernetes-helm/tiller:v2.2.3
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /liveness
        port: 44135
        scheme: HTTP
      initialDelaySeconds: 1
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1
    name: tiller
    ports:
    - containerPort: 44134
      name: tiller
      protocol: TCP
    readinessProbe:
      failureThreshold: 3
      httpGet:
        path: /readiness
        port: 44135
        scheme: HTTP
      initialDelaySeconds: 1
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 1
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  securityContext: {}
  terminationGracePeriodSeconds: 30

Service

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2017-03-27T15:06:49Z
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  clusterIP: 10.3.251.197
  ports:
  - name: tiller
    port: 44134
    protocol: TCP
    targetPort: tiller
  selector:
    app: helm
    name: tiller
  sessionAffinity: None
  type: ClusterIP

注意楼上的 Service 代码表明 Tiller 并没有用 NodePort 或者 Ingress/Loadbalancer 等方式暴露端口，因此这里推测 Helm 同 Tiller 的通信可能是利用 kubectl proxy 完成的。

常用操作

下面列举了一个简单的安装数据库的操作过程：

helm search mysql #搜索
helm inspect stable/mariadb #查看
helm install stable/mariadb #安装

很明显，上面的命令没有对 Chart 的而运行做任何指导，实际上没什么用，我们可以利用 --set 或者 --value 参数，来指定在我们 Inspect 命令中看到的变量的值，就可以完成对变量的设置了。

除了利用简单的模板功能来生成和控制 pvc/secret 等各种对象之外， Chart 还具有很重要的依赖管理功能。

自建 Chart

简单的一个 helm create 命令就可以初始化一个 chart。

├── Chart.yaml # Chart 的文件主要信息
├── charts # 依赖的 Chart
├── templates # 模板目录，用 gotpl 编写 Kubernetes 运行 App 所需的各种对象定义
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml # 缺省值定义

编写完成之后，使用 helm package 命令可以将 chart 打包为 tgz 格式。

最后可以运行 helm install ./some.chart.tgz 来运行本地的 Chart。

自建 Repository

很明显的，我们需要一个自建仓库，不过幸运的是，Helm 仓库并不像 Docker Image Registry 之类的东西那么麻烦。只要一个能相应 GET 请求并提供 YAML 和 TAR 文件的 HTTP 服务器就可以了。

最简单的，可以用 helm serve 命令就可以了：

首先创建一个文件夹用于保存 Chart
把上面我们 helm package 生成的压缩包复制进去
helm serve --repo-path repo 就会运行一个简单的 HTTP Server 提供 Helm chart 仓库的服务了。
运行helm repo add some-repo http://repo-url 命令，添加仓库到系统中。

另外可以利用 github 以及各种 HTTP 服务器来提供这一服务。

helm | 伪架构师

Helm 和 Kustomize：不只是含谷量的区别

Helm

Helm Chart

Helm 的特色

Kustomize

Base + Overlay

Kustomize 的特色

比较

结论

相关链接

Istio Helm Chart 详解 - Pilot

前言

values.yaml 中的全局变量

RBAC 相关

gateway.yaml

meshexpansion.yaml

deployment.yaml

service.yaml

总结

Istio Helm Chart 详解 - Mixer

前言

values.yaml 中的全局变量

RBAC 相关

autoscale.yaml

service.yaml

statsdtoprom.yaml

Deployment

Service

autoscale.yaml

deployment.yaml

policy_container

telemetry_container

config.yaml

总结

Istio Helm Chart 详解 - Galley

前言

values.yaml 中的相关变量

RBAC 相关内容

service.yaml

deployment.yaml

全局变量

变量使用细节

加载卷

configmap.yaml 以及 validatingwehookconfiguration.yaml.tpl

引用全局变量

Webhook

结论

Istio Helm Chart 详解 - SidecarInjectorWebhook

前言

values.yaml 中的变量定义

Chart.yaml 和 _helpers.tpl

RBAC 相关内容

service.yaml

depoyment.yaml

mutatingwebhook.yaml

sidecar-injector-configmap.yaml

istio-init

enable-core-dump

istio-proxy

小结

参考文档

Istio Helm Chart 详解 - Ingress

前言

Chart.yaml

autoscale.yaml

serviceaccount.yaml

clusterrole.yaml 和 clusterrolebinding.yaml

deployment.yaml

service.yaml

常用链接

Istio Helm Chart 详解 - 全局变量

前言

hub 和 tag

影响范围

k8sIngressSelector

影响范围

charts/pilot/templates/gateway.yaml

templates/configmap.yaml

k8sIngressHttps

`autoscale.yaml`

`service.yaml`

`statsdtoprom.yaml`

`autoscale.yaml`

`deployment.yaml`

`config.yaml`

`values.yaml` 中的变量定义

`istio-init`

`enable-core-dump`

`istio-proxy`

`charts/pilot/templates/gateway.yaml`

`templates/configmap.yaml`

`charts/pilot/templates/gateway.yaml`

`istio/templates/sidecar-injector-configmap.yaml`