Istio边车自动注入靠MutatingWebhook在Pod创建时插入代理

[[通信可靠性保障的五阶段演进从业务代码耦合到服务网格]]里边车代理要真正 “对应用透明”，注入这一步就不能靠人工操作。服务网格接入应用有三种方式： 基座模式（Chassis，靠SDK接管通信，对代码有侵入性，如华为的ServiceComb Mesher，非主流）；手动注入模式（对使用者不透明但对程序透明——边车本就 是与应用共享网络名称空间的辅助容器，天然契合Pod的设定，在Kubernetes里 手动给Pod加一个容器即可，用istioctl kube-inject命令能直接看到注入 前后的Manifest差异）；自动注入模式（对使用者和程序都透明，Istio推荐 的方式）。自动注入靠Kubernetes的”动态准入控制”（Dynamic Admission Control）中的Mutating Webhook控制器实现：Istio预先注册一个 MutatingWebhookConfiguration资源，声明”对带有istio-injection: enabled 标签的名称空间，只要有Pod发生CREATE操作，就先自动调用istio-system 名称空间下的istio-sidecar-injector服务的/inject接口”——Kubernetes会 把新建Pod的元数据作为参数传给这个HTTP Endpoint，再拿返回结果里已经 注入了边车（istio-proxy容器，内部包含Golang写的pilot-agent负责Envoy 生命周期管理，和C++写的envoy进程本体）的新Pod定义去真正创建。这个机制 的巧妙之处在于：整个注入过程完全发生在Pod真正被创建之前的一次拦截调用 里，运维人员只需要给名称空间打个标签，后续所有新建Pod都会自动带上边车， 不需要对每个应用单独操作。