4. 网格拓扑基础：服务网格中的 Sidecar 注入原理、自动注入与手动注入、Sidecar 资源限制

4.1 Sidecar 注入原理

在 Istio 服务网格中，Sidecar 代理（Envoy）是数据平面的核心组件。每个业务 Pod 启动时，Istio 会向该 Pod 内注入一个 Envoy 容器，拦截所有进出流量。注入的本质是 修改 Pod 的 YAML 定义，在原有容器列表中添加 Envoy 容器及其初始化容器（istio-init）。

注入过程涉及两个关键容器：

• istio-init 容器（Init 容器）：负责设置 Pod 网络命名空间的 iptables 规则，将入站和出站流量重定向到 Envoy 代理（默认端口 15001/15006）。该容器执行完毕后退出。
• istio-proxy 容器（Sidecar 容器）：运行 Envoy 代理，与业务容器共享网络命名空间，处理所有流量转发、策略执行和遥测数据采集。

4.2 自动注入与手动注入

Istio 提供两种 Sidecar 注入方式，适用于不同的开发和运维场景。

4.2.1 自动注入配置示例

为 Namespace 启用自动注入：

# 为 default 命名空间添加注入标签
kubectl label namespace default istio-injection=enabled

# 验证标签是否生效
kubectl get namespace -L istio-injection

在 Pod 级别覆盖注入行为（通过注解）：

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  annotations:
    sidecar.istio.io/inject: "true"   # 显式启用注入
    # sidecar.istio.io/inject: "false"  # 显式禁用注入
spec:
  containers:
  - name: app
    image: my-app:latest

4.2.2 手动注入操作示例

# 使用 istioctl 手动注入 Sidecar
istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml

# 直接注入并应用到集群
istioctl kube-inject -f deployment.yaml | kubectl apply -f -

4.3 Sidecar 资源限制

Sidecar 代理（Envoy）会消耗额外的 CPU 和内存资源。如果不对 Sidecar 设置资源限制，可能导致节点资源耗尽或 Sidecar 被 OOM Kill，进而影响整个 Pod 的流量处理能力。

4.3.1 默认资源限制

Istio 安装时会在 istio-operator 或 Helm values 中定义全局默认值：

4.3.2 自定义资源限制的三种方式

1. 全局配置（修改 IstioOperator）：影响所有注入的 Sidecar。
2. Namespace 级别（通过 Annotation 默认值）：影响该 Namespace 下所有 Pod。
3. Pod 级别（通过 Annotation 覆盖）：仅影响单个 Pod。

Pod 级别覆盖示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "500m"
        sidecar.istio.io/proxyCPULimit: "1000m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "512Mi"
    spec:
      containers:
      - name: app
        image: my-service:latest

4.3.3 资源限制优化建议

• 起步值：CPU Request 200m，Limit 1000m；内存 Request 256Mi，Limit 512Mi。
• 监控指标：关注 Envoy 的 envoy_server_memory_allocated 和 envoy_server_memory_heap_size。
• 避免过度配置：大多数轻量级微服务的 Sidecar 内存消耗在 50-150Mi 之间。
• 使用 Vertical Pod Autoscaler (VPA)：对 Sidecar 容器启用 VPA 可以自动调整资源 Request。

4.4 注入验证与排错

部署应用后，可以通过以下命令验证 Sidecar 是否成功注入：

# 查看 Pod 中的容器数量（应包含 istio-proxy）
kubectl get pods -n default -l app=my-service

# 查看 Pod 详细信息，确认注入状态
kubectl describe pod my-service-xxxxx

# 检查注入事件
kubectl get events --field-selector involvedObject.name=my-service-xxxxx

常见注入失败原因：

• Namespace 未添加 istio-injection=enabled 标签。
• Pod 注解 sidecar.istio.io/inject: "false" 显式禁用了注入。
• Webhook 组件（istiod）不可用或证书过期。
• Pod 安全策略（PSP）或 OPA 策略阻止了 Init 容器的创建。