边车代理

每个实例一个代理

边车与应用运行在同一 Pod 或主机命名空间中，平台把流量重定向经过它。代理可用 mTLS 认证双方、执行重试预算、按版本路由并上报延迟，应用无需引入网络库。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"

示例展示按需注入。更重要的运维细节不那么显眼：代理必须在应用接收流量前就绪，并在应用退出前排空连接。

生命周期与资源

边车给每个 Pod 增加一个容器，其内存和 CPU 随连接与流量增长，并且可能独立故障。要设置资源请求和限制，把代理纳入就绪检查，并确保关闭顺序：停止接收新流量、排空代理、再终止应用。比应用存活更久的边车会占用监听器并干扰下一次发布。

让策略可理解

网格可表达重试、超时、熔断和路由。若不了解应用的幂等性和截止时间，就在代理上全部启用，可能让故障更糟。应把代理策略视为生产配置：评审、测试，并记录哪一层拥有哪种行为。

何时使用

当跨多服务统一传输安全和遥测足以抵消每实例开销，或遗留服务无法修改时，使用边车。优点是不改代码即可获得一致性；代价是资源成本、生命周期复杂度和每个请求多一层。与 API 网关相比，边车覆盖东西向流量和按实例策略，而不是共享的南北向入口。