Skip to main content

Command Palette

Search for a command to run...

Istio Helm Chart 详解 - SidecarInjectorWebhook

Updated
2 min read

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

前言

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

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

  1. Kubernetes 版本大于 1.9。
  2. 启用了 MutatingAdmissionWebhookValidatingAdmissionWebhook
  3. 还有一点,在 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.yamlclusterrolebinding.yamlclusterrole.yaml 三个文件来进行赋权操作。

serviceaccount.yaml 中,引用变量除了 ChartRelease 两组保留变量之外,还引用到 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.tagglobal.hub:镜像的前后缀
  • global.priorityClassName:Kubernetes PriorityClass 定义。
  • global.imagePullPolicy:镜像拉取策略。
  • replicaCount:Deployment 的副本数量。
  • image:镜像名称,前后缀由全局变量控制,这里不可直接指定完整镜像地址
  • resourcesglobal.defaultResources:优先使用 Chart 资源定义。
  • nodeaffinity:沿用全局节点亲和性定义。

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

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

加载卷:

  • istio ConfigMap:它的内容被加载到 /etc/istio/config,作为 sidecar-injectormeshConfig 参数。
  • 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:可选值包括 enableddisabled,如果选择 enabled,那么缺省情况下会进行注入,除非 Pod 中注解 sidecar.istio.io/injectfalsedisabled 则缺省不注入,除非注解 sidecar.istio.io/injecttrue

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

istio-init

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

如果 global.proxy_init.image 中包含了 /,则直接使用该名称;否则使用 global.hubglobal.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/proxyCPUsidecar.istio.io/proxyMemory 来设置 Sidecar 的 Request Resource,否则会使用 proxy.resources 进行资源申请。

小结

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

参考文档

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts

Istio Helm Chart 详解 - SidecarInjectorWebhook