3. Envoy Sidecar 注入机制:手动注入、自动注入(Webhook)、注入模板与配置
Envoy Sidecar 的注入是 Istio 数据面网格化的核心操作。升级后,注入策略可能因版本差异、Webhook 配置变更或模板更新而失效或产生非预期行为。理解三种注入方式——手动注入、基于 Webhook 的自动注入以及注入模板的定制逻辑,是诊断和重置注入策略的基础。
3.1 手动注入:显式控制与调试
手动注入通过 istioctl kube-inject 命令,在部署前将 Sidecar 配置写入 Pod 模板。此方式不依赖集群内的 Webhook,适用于 CI/CD 管道或调试场景。
适用场景: 离线环境、无 Webhook 权限的命名空间、快速验证 Sidecar 配置变更。
命令示例
# 将 deployment.yaml 注入 Sidecar 并输出到标准输出
istioctl kube-inject -f deployment.yaml
# 直接应用到集群
istioctl kube-inject -f deployment.yaml | kubectl apply -f -
# 指定注入模板(自定义模板路径)
istioctl kube-inject -f deployment.yaml --injectConfigFile inject-config.yaml
手动注入 vs 自动注入对比
| 特性 | 手动注入 | 自动注入(Webhook) |
|---|---|---|
| 触发时机 | 部署前(kubectl apply 前) | Pod 创建时(MutatingWebhook) |
| 依赖组件 | istioctl 客户端 | istiod、Webhook 配置、CA 证书 |
| 版本一致性 | 与 istioctl 版本绑定 | 与 istiod 版本绑定 |
| 回滚复杂度 | 低(重新生成 YAML) | 中(需调整 label 或 Webhook 配置) |
| 升级影响 | 需重新注入(旧 Sidecar 保留) | 新 Pod 自动使用新版本 |
3.2 自动注入:Webhook 机制与升级风险
自动注入依赖 Kubernetes MutatingAdmissionWebhook。当 Pod 创建请求到达 API Server 时,istiod 注册的 Webhook 拦截请求,根据命名空间标签和 Pod 注解决定是否注入 Sidecar。
Webhook 配置关键字段
# 查看当前 Webhook 配置
kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml
# 关键字段说明
webhooks:
- name: sidecar-injector.istio.io
clientConfig:
service:
name: istiod # Webhook 后端服务
namespace: istio-system
path: /inject # 注入端点
caBundle: <base64-cert> # 升级后需验证此证书是否有效
rules:
- operations: ["CREATE"]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
namespaceSelector:
matchLabels:
istio-injection: enabled # 命名空间标签触发条件
3.3 注入模板与配置定制
Istio 使用 Sidecar 注入模板 定义注入到 Pod 中的容器、卷、环境变量和启动参数。模板位于 istiod 内部,可通过 istioctl profile dump 导出,也支持通过 Sidecar CRD 或 meshConfig 进行定制。
模板结构概览
| 模板部分 | 内容说明 | 升级后常见变更 |
|---|---|---|
| containers | Envoy 容器定义(镜像、资源、端口) | 镜像版本升级、新增启动参数 |
| volumes | Sidecar 挂载的卷(如 istio-、certs) | 卷类型或挂载路径变化 |
| initContainers | istio-init 容器(iptables 规则配置) | CNI 模式启用后可能移除 |
| env | 环境变量(如 PILOT_CERT_PROVIDER、METRICS) | 新增或废弃变量 |
| annotations | 注入注解(如 sidecar.istio.io/inject) | 注解行为可能调整 |
自定义注入配置示例
# 通过 Sidecar CRD 覆盖全局注入模板
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: custom-sidecar
namespace: default
spec:
workloadSelector:
labels:
app: my-app
egress:
- hosts:
- "istio-system/*"
# 自定义注入环境变量
env:
- name: ISTIO_META_APP_CONTAINERS
value: "my-app"
- name: ISTIO_META_CLUSTER_ID
value: "Kubernetes"
升级检查要点: 升级后使用
istioctl experimental describe pod <pod-name> 查看实际注入的 Sidecar 配置,与升级前的模板进行对比,确认镜像版本、启动参数和卷挂载是否一致。
3.4 注入策略重置的核心原则
- 版本对齐: 确保 istiod、istioctl 和 Sidecar 镜像版本一致,避免混合版本导致协议不兼容。
- Webhook 证书验证: 升级后检查 caBundle 是否过期,必要时重新生成并更新 Webhook 配置。
- 模板差异分析: 使用
istioctl manifest generate导出新旧版本的注入模板,对比关键字段变化。 - 渐进式注入: 先对测试命名空间启用自动注入,验证无误后再推广到生产命名空间。
- 回滚预案: 保留升级前的 Webhook 配置和注入模板备份,以便快速回退。
常见陷阱: 升级后如果命名空间标签
istio-injection=enabled 未变,但 Pod 未注入 Sidecar,优先检查 Webhook 的 caBundle 是否与当前 istiod 证书匹配。证书轮换后未更新 Webhook 配置是升级后注入失败的首要原因。