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)流程 用户 kubectl apply K8s API Server MutatingWebhook istiod 注入逻辑 Pod 创建(已注入) 跳过注入(无标签) ⚠ 升级风险点: Webhook 配置中的 caBundle 过期、istiod 版本不匹配、注入模板变更可能导致注入失败或 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 注入策略重置的核心原则

  1. 版本对齐: 确保 istiod、istioctl 和 Sidecar 镜像版本一致,避免混合版本导致协议不兼容。
  2. Webhook 证书验证: 升级后检查 caBundle 是否过期,必要时重新生成并更新 Webhook 配置。
  3. 模板差异分析: 使用 istioctl manifest generate 导出新旧版本的注入模板,对比关键字段变化。
  4. 渐进式注入: 先对测试命名空间启用自动注入,验证无误后再推广到生产命名空间。
  5. 回滚预案: 保留升级前的 Webhook 配置和注入模板备份,以便快速回退。
常见陷阱: 升级后如果命名空间标签 istio-injection=enabled 未变,但 Pod 未注入 Sidecar,优先检查 Webhook 的 caBundle 是否与当前 istiod 证书匹配。证书轮换后未更新 Webhook 配置是升级后注入失败的首要原因。