这是《Istio Helm Chart 详解》系列的第四篇，对 Gateways Chart 进行一些介绍，并讲解一下使用 Helm 创建 Istio Gateway 的方法。
前言
前面提到过，Istio 的 Helm Chart，除去用于安装之外，还有部分对 Istio 部署进行调整的能力。Gateways 一节内容，就包含了定制 Istio Ingress/Egress Gateway 的能力。
这个 Chart 的文件结构和其他组件类似，不同的在于内容，它通过对 values.yaml 中定义的 Gateways 相关内容的循环遍历，生成不同的 Gateway 单元，下面将会进行讲解和试验。
values.yaml 中的变量定义
gateways:
enabled: true
istio-ingressgateway:
enabled: true
labels:
app: istio-ingressgateway
istio: ingressgateway
replicaCount: 1
autoscaleMin: 1
autoscaleMax: 5
resources: {}
cpu:
targetAverageUtilization: 80
loadBalancerIP: ""
serviceAnnotations: {}
type: LoadBalancer
ports:
- port: 80
targetPort: 80
name: http2
nodePort: 31380
- port: 443
...
其中包含了一个层次结构：Gateways 的下级除了用于 requirements.yaml 使用的 enabled 字段之外，还包含一个数组，数组的每个元素定义了一个网关。
range $key, $spec := .Values：对 gateways 一节的局部变量进行遍历，第一层遍历的值用 $key 和 $spec 两个变量来表示键值对，根据每个键值对的定义，逐个创建资源，下面会提到的 $spec 引用就是相当于每个网关控制器的定义变量，$key 就是每个网关控制器的名称。
Chart.yaml
元数据文件，无需赘述。
autoscale.yaml
首先讲解一下头部的渲染条件：
{{- range $key, $spec := .Values }}
{{- if and (ne $key "global") (ne $key "enabled") }}
{{- if and $spec.enabled $spec.autoscaleMin }}
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: {{ $key }}
namespace: {{ $spec.namespace | default $.Release.Namespace }}
spec:
maxReplicas: {{ $spec.autoscaleMax }}
minReplicas: {{ $spec.autoscaleMin }}
scaleTargetRef:
apiVersion: apps/v1beta1
kind: Deployment
name: {{ $key }}
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: {{ $spec.cpu.targetAverageUtilization }}
---
{{- end }}
{{- end }}
{{- end }}
顾名思义，这个文件是用来创建 HPA 的，但是整个文件的外层由一个 range 语句所包围：
{{- if and (ne $key "global") (ne $key "enabled") }} 将会跳过 global 和 enabled 键。{{- if and $spec.enabled $spec.autoscaleMin }}：如果前面读到的 $spec 变量中的 enabled 和 autoscaleMin 都是 true，才会进行处理。这里条件跟其它几个文件不同：只有设置了 autoscaleMin 的情况下才会渲染 HPA 对象。
引用变量：
$key：也就是网关的名称，例如前面的 istio-ingressgateway。$spec.namespace：可以为这一 Gateway 定义命名空间，如果没有定义，则沿用 Istio 的命名空间，也就是 Release.Namespace。$spec.autoscaleMax 和 $spec.autoscaleMin，Gateway 伸缩的上下限。cpu.targetAverageUtilization：伸缩指标，目标平均 CPU 占用率。
RBAC 资源
同样的，这里定义了每个网关所对应的 ServiceAccount、ClusterRole 以及 ClusterRoleBinding，用于 RBAC。
Gateway 角色需要对 thirdpartyresources、virtualservices、destinationrules 以及 gateways 几种资源进行读写。
看 meta.name 的定义可以看出，每个网关都会有自己的 RBAC 资源，命名规则为 [网关名称]-[Istio 所在的命名空间]。
另外 ServiceAccount 中引用了全局变量 imagePullSecrets。
deployment.yaml
这个模板用于 Deployment 的创建过程。这个部署运行的主要服务进程和 Ingress Chart 一样，是 pilot-agent。
全局变量
- priorityClassName
- hub
- tag
- istioNamespace
- proxy.envoyStatsd
- controlPlaneSecurityEnabled
- defaultResources
- nodeaffinity
变量使用细节
$spec.labels：这里可以看出，我们可以使用在 values.yaml 中定义标签 labels 的方式，为新的 Deployment 指定标签。标签将同时出现在 Deployment 和下面的 Pod 中。，从而定义 Gateway 资源时，可以用标签来指定对应的控制器。$spec.replicaCount：可以指定初始副本数量。$spec.ports：在 ports 中定义的各种端口，会在容器中进行发布。- Gateway 名称在这里还作为
--serviceCluster 的值，这一参数在 Sidecar 中一般取值为 istio-proxy。
- 如果定义了
global.istioNamespace，会使用 [服务名].[命名空间] 的方式定义 zipkin、istio-pilot 的服务地址。
- 根据
global.proxy.envoyStatsd 设置 statsd 地址。
- 如果 Gateway 定义中包含了资源限制的内容，则会在这里进行包含，否则只会使用缺省资源限制。
$spec.additionalContainers 中还可以定义该 Pod 中额外的容器。- 如果有加载额外 tls secret 的需求，可以定义在
$spec.secretVolume 中。
- 如果有加载额外 Configmap 的需求，可以定义在
$spec.configVolumes 中。
service.yaml
- 和其他元素一样，Service 也是使用循环的方式逐个建立的。
- 服务名称同样也是直接使用
$key。
- 端口、命名空间、标签和 Deployment 模板一致。
$spec.serviceAnnotations 用于生成服务注解。selector 的定义也和标签定义一致。- 如果定义了
$spec.loadBalancerIP，这里会给服务的 loadBalancerIP 赋值。
- 如果定义了
.type，则将服务类型进行修改。
测试一下
在 values.yaml 的 gateways 一节加入这样一段：
istio-myingress:
enabled: true
namespace: default
labels:
app: istio-ingressgateway
istio: myingress
replicaCount: 1
autoscaleMax: 5
resources: {}
cpu:
targetAverageUtilization: 80
loadBalancerIP: ""
serviceAnnotations: {}
type: NodePort
ports:
- port: 80
targetPort: 80
name: http-myingress
然后用命令行生成对应的安装文件：
$ helm template istio --name istio -f \
values-new-gateway.yaml --namespace \
istio-system > istio-myingress.yaml
生成的 yaml，用编辑器打开，使用正则表达式 source:.*?gateways 进行搜索，会看到生成的内容符合之前的描述，在 Default 命名空间中出现了新的 ServiceAccount、ClusterRole、ClusterRoleBinding 资源，因为删除了 autoscaleMin，所以不会产生 HPA 对象，同时服务类型也改成了 NodePort。
仔细看看会发现其中有一些问题：
- Pilot、Statsd 等依赖服务的地址还在本命名空间，没有引用
istio-system 中的服务。
- ClusterRoleBinding 引用的 ServiceAccount 还是指向了
istio-system 中的 ServiceAccount，但是很明显，这是不存在的。
这两点结合起来，足够给这个 Gateway 控制器判了死刑，是不可能正常工作的。如果用这一个文件安装 Istio，这个 Gateway 对应的 Pod 日志一定会出现错误。要修正错误，有三个方式：
- 不再定义
namespace。
- 修正 Chart。
- 修改渲染后的 YAML 文件。
所以这里妥协一下，删掉 namespace 一行，使用缺省设置，重新渲染安装。
安装完成以后，按照控制 Ingress 流量一文的介绍，安装 httpbin 服务，并为其设置 Gateway 和 VirtualService（注意替换其中的域名），其中的 Gateway Selector 使用我们新建的网关 myingress：
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: httpbin-gateway
spec:
selector:
istio: myingress
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "httpbin.example.rocks"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- "httpbin.example.rocks"
gateways:
- httpbin-gateway
http:
route:
- destination:
port:
number: 8000
host: httpbin
创建这两个资源之后，使用 curl 访问 Ingress 服务，会看到正确的结果返回，例如：
$ curl httpbin.example.rocks/ip
{
"origin": "10.232.0.37"
}
再来一次
前面的测试我们模拟了从头部署 Istio 的方式，如果是一个现存的 Istio 部署，又应该怎样新建网关？
根据前面的分析，可以得出引用的所有全局变量：
- priorityClassName
- hub
- tag
- istioNamespace
- proxy
- controlPlaneSecurityEnabled
- defaultResources
- nodeaffinity
- imagePullSecrets
如果保证这些变量的完整性，并且和正在运行的 Istio 一致；同时关掉其它的不必要的组件渲染，应该就可以达到效果。这样写一个 values.yaml：
global:
hub: docker.io/istio
tag: 1.0.2
proxy:
envoyStatsd:
enabled: true
host: istio-statsd-prom-bridge
port: 9125
imagePullPolicy: IfNotPresent
controlPlaneSecurityEnabled: false
imagePullSecrets:
defaultResources:
requests:
cpu: 10m
priorityClassName: ""
sidecarInjectorWebhook:
enabled: false
security:
enabled: false
ingress:
enabled: false
mixer:
enabled: false
pilot:
enabled: false
grafana:
enabled: false
prometheus:
enabled: false
servicegraph:
enabled: false
tracing:
enabled: false
galley:
enabled: false
kiali:
enabled: false
certmanager:
enabled: false
gateways:
enabled: true
istio-ingressgateway:
enabled: false
istio-egressgateway:
enabled: false
istio-newingress:
enabled: true
labels:
app: istio-ingressgateway
istio: newingress
replicaCount: 1
autoscaleMax: 5
resources: {}
cpu:
targetAverageUtilization: 80
loadBalancerIP: ""
serviceAnnotations: {}
type: LoadBalancer
ports:
- port: 80
targetPort: 80
name: http-newingress
重新渲染并执行。
修改 httpbin Gateway 定义，将 Selector 变更为 istio: newingress，提交后使用 CURL 进行验证，会发现新的 Gateway 已经生效。
小结
目前的 Gateway 管理还无法让人满意，多命名空间或者按需调度方面的功能还有很大缺憾；但是借用 Helm Chart 进行大块功能管理的方式还是一个有趣而且可能有效的尝试。
