《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 的相关内容之中。