4、Sidecar注入原理：手动注入与自动注入、Sidecar注入的配置、Sidecar生命周期管理

好，咱们今天聊聊Sidecar注入。说白了，就是怎么把Envoy这个代理容器，悄无声息地塞进你的Pod里。我刚开始接触Istio时，觉得这玩意儿挺神奇的——明明没改我的Deployment，Pod启动后却多了一个容器。嗯，今天我就把这里面的门道给你讲透。

4.1 手动注入：最原始的方式

手动注入，就是你自己动手，用istioctl命令把Sidecar配置写进YAML里。我个人习惯在调试时用这种方式，因为看得见摸得着。

核心命令：

# 生成注入后的YAML
istioctl kube-inject -f deployment.yaml > injected-deployment.yaml

# 直接部署
kubectl apply -f injected-deployment.yaml

你想想看，这个命令干了什么？它读取你的Deployment，然后在Pod模板里插入了init容器和Sidecar容器的定义。我曾在项目中遇到过一个问题：手动注入后，Pod启动失败。排查了半天，发现是istio-proxy的镜像拉取策略设置不对。说白了，手动注入虽然直观，但容易出错。

我的建议：手动注入适合CI/CD流水线中做预检，生产环境别这么干。我曾经在测试环境用了一个月手动注入，每次改Deployment都得重新跑一遍istioctl，烦得很。

4.2 自动注入：生产环境的标配

自动注入，说白了就是利用Kuberentes的MutatingAdmissionWebhook机制。当Pod创建时，Istio的webhook会拦截请求，动态修改Pod定义，把Sidecar加进去。

为什么会这样？因为Istio在集群里部署了一个webhook服务，它监听Pod的创建事件。你只需要给命名空间打个标签，剩下的交给Istio。

# 启用自动注入
kubectl label namespace default istio-injection=enabled

# 验证
kubectl get namespace -L istio-injection

自动注入的流程：

  1. 用户提交Pod创建请求
  2. API Server调用MutatingAdmissionWebhook
  3. Istio的webhook服务返回修改后的Pod定义
  4. API Server用修改后的定义创建Pod

嗯，这里要注意：自动注入不是实时的。它只在Pod创建时生效。如果你改了命名空间的标签，已经运行的Pod不会自动注入。我刚开始就犯过这个错，以为改了标签就能自动注入，结果重启了所有Pod才生效。

4.3 Sidecar注入的配置详解

Sidecar注入的配置，说白了就是告诉Istio：哪些Pod要注入，注入什么版本的Sidecar，资源限制是多少。我个人习惯把这些配置放在一个单独的ConfigMap里。

配置项 说明 我的经验
istio-injection=enabled 命名空间级别的注入开关 最常用，但粒度太粗
sidecar.istio.io/inject: "true" Pod级别的注入注解 推荐，可以精确控制
sidecar.istio.io/proxyCPU Sidecar的CPU限制 默认100m，我一般设200m
sidecar.istio.io/proxyMemory Sidecar的内存限制 默认128Mi，高并发建议256Mi

避坑指南：我曾经在生产环境遇到过Sidecar OOM的问题。原因是某个服务流量突增，Envoy的内存占用飙升。从那以后，我养成了一个习惯：给Sidecar设置合理的资源限制，并且监控它的实际使用量。

# Pod级别的注入控制
apiVersion: v1
kind: Pod
metadata:
  annotations:
    sidecar.istio.io/inject: "true"
    sidecar.istio.io/proxyCPU: "200m"
    sidecar.istio.io/proxyMemory: "256Mi"
spec:
  containers:
  - name: my-app
    image: my-app:latest

4.4 Sidecar生命周期管理

Sidecar的生命周期，说白了就是它从生到死的过程。我把它分为三个阶段：启动、运行、退出。

4.4.1 启动阶段

Pod启动时，init容器先跑。它负责配置iptables规则，把流量劫持到Envoy。然后Sidecar容器启动，等待主容器就绪。

启动顺序：

  1. Init容器：istio-init，配置网络规则
  2. Sidecar容器：istio-proxy，启动Envoy
  3. 主容器：你的业务应用

你想想看，为什么要有init容器？因为流量劫持必须在主容器启动前完成。我遇到过一个问题：init容器执行失败，导致Pod一直处于Init:CrashLoopBackOff状态。排查后发现是CNI插件冲突。

4.4.2 运行阶段

运行阶段，Sidecar和主容器共存。Envoy负责处理所有进出流量。我个人习惯用以下命令查看Sidecar状态：

# 查看Sidecar日志
kubectl logs pod-name -c istio-proxy

# 查看Sidecar配置
kubectl exec pod-name -c istio-proxy -- pilot-agent request GET /stats

4.4.3 退出阶段

Pod关闭时，Sidecar的退出顺序很重要。Istio默认使用preStop钩子，在Pod终止前优雅关闭Envoy。

我的建议：设置terminationGracePeriodSeconds为30秒以上。我曾经遇到过Pod强制终止导致连接中断的问题，就是因为优雅关闭时间太短。

# 查看Sidecar的preStop钩子
kubectl get pod pod-name -o jsonpath='{.spec.containers[?(@.name=="istio-proxy")].lifecycle.preStop}'

避坑指南：我曾经在生产环境遇到一个问题：滚动更新时，旧Pod的Sidecar还没完全关闭，新Pod的Sidecar已经开始接收流量，导致请求路由混乱。解决方案是调整PodDisruptionBudget和优雅关闭时间。

4.5 实战经验总结

说了这么多，我总结几条实战经验：

  • 注入策略：生产环境用自动注入，测试环境用手动注入
  • 资源规划：Sidecar默认资源偏小，根据流量调整
  • 监控告警：监控Sidecar的CPU、内存、连接数
  • 优雅关闭：设置合理的terminationGracePeriodSeconds

嗯，Sidecar注入这块，说白了就是让Envoy成为你应用的"影子"。它默默处理流量，你几乎感觉不到它的存在。但一旦出了问题，排查起来也挺头疼的。我建议你多看看Envoy的日志和指标，慢慢就能摸清它的脾气了。

← 上一章 📖 返回目录 下一章 →