Service Mesh 深度：Istio、Linkerd 与流量治理

没有 Mesh：重试/熔断/超时/TLS 散落在各应用代码里，各语言各写一套
引入 Mesh：治理逻辑下沉到基础设施代理，策略用 YAML 声明
关键认知：Mesh 解决"东西向流量"（服务到服务）；外部进集群的
  "南北向流量"是 Ingress/Gateway API 的事，不要搞混。

┌──────── 控制面（Istiod / controller）────────┐
│  策略转译 + 证书签发，规则下发               │
└───────────────────┬──────────────────────────┘
                    │ xDS / gRPC
┌───────────────────▼──────────────────────────┐
│  数据面（Sidecar）：Pod ──[proxy]──> Pod     │
└──────────────────────────────────────────────┘

创建 Pod 时 MutatingAdmissionWebhook 拦截请求
  → 注入 initContainer（改 iptables）+ sidecar 容器
  → initContainer 劫持网络后退出，sidecar 常驻转发
数据路径：业务容器 → iptables REDIRECT → sidecar → 目标 Pod

kubectl label namespace shop istio-injection=enabled   # 自动注入
istioctl kube-inject -f deploy.yaml | kubectl apply -f -  # 临时注入

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: order-vs
spec:
  hosts: [order]
  http:
    - route:
        - destination: { host: order, subset: stable }
          weight: 90
        - destination: { host: order, subset: canary }
          weight: 10

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: order-vs
  namespace: shop
spec:
  hosts: ["order"]
  http:
    - match:
        - headers: { x-user-group: { exact: "internal" } }
      route:
        - destination: { host: order, subset: canary }
    - mirror:            # 影子测试：复制流量观察，不影响线上
        host: order
        subset: canary

Sidecar 自动产生：Rate（istio_requests_total）、Errors（5xx/4xx）、
  Duration（P50/P95/P99）、Saturation（连接池）。
Istio 对接 Prometheus：ServiceMonitor 抓 sidecar 的 /stats/prometheus。

链路：sidecar 自动注入/透传 trace 头，Jaeger/Tempo 按 trace-id 串起调用。
mTLS：网格内默认双向 TLS；身份 = ServiceAccount，证书由控制面签发并自动轮换。
用 istioctl manifest generate --set values.global.mtls.enabled=true 开启。
误区：mTLS 只保证传输加密与身份，不替代业务鉴权。

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: order-vs
spec:
  hosts: [order]
  http:
    - timeout: 3s
      retries: { attempts: 2, perTryTimeout: 1s }
      route:
        - destination: { host: order, port: { number: 8080 } }

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: order-dr
  namespace: shop
spec:
  host: order
  subsets:
    - name: stable
      labels: { version: v1 }
    - name: canary
      labels: { version: v2 }
  trafficPolicy:
    loadBalancer: { simple: ROUND_ROBIN }
    outlierDetection:
      consecutive5xxErrors: 5
      baseEjectionTime: 30s

linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check
kubectl annotate ns shop linkerd.io/inject=enabled
kubectl rollout restart deploy -n shop

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: order.default.svc.cluster.local
spec:
  routes:
    - name: GET /orders
      condition: { method: GET, pathRegex: /orders }
      isRetryable: true
      timeout: "1s"

选 Istio：需要 header 路由/镜像/熔断等复杂治理、统一南北向、有 Envoy 经验。
选 Linkerd：追求低开销快上手、默认安全、流量策略简单、团队小。
注意：别混跑两套 mesh，iptables 与证书体系会互相冲突。

开销：数据面转发 P99 +1~3ms；CPU 每 Pod 预留 50~200m；
  内存 Envoy ~50MB / linkerd-proxy ~20MB。
经验值：Istio 延迟 +3ms、CPU +8~15%；Linkerd 延迟 +1ms、CPU +2~5%。

容量规划：业务 Pod 的 requests.memory 预留 sidecar（Istio 64Mi 起）；
  用 Fortio/wrk 做"带 mesh vs 不带 mesh"的 A/B 压测，关注 P99 与 CPU throttling；
  关掉不需要的遥测（只保留 RED），控制成本。

□ 按命名空间精准注入，避免全集群误注入
□ 灰度从权重 1% 起步，逐步放量，配合指标看板
□ 开启 mTLS + 严格的 PeerAuthentication（STRICT）
□ 配置熔断与重试预算，防止重试风暴
□ 策略纳入 Git，走 GitOps 评审
□ 升级前 staging 验证（istioctl/linkerd upgrade）