Istio 服务网格入门教程

第一章：什么是 Service Mesh

传统微服务通信

业务代码 = 业务逻辑 + 重试/超时/熔断/安全/监控

这些非业务逻辑散落在各个服务里，不同语言重复实现，升级困难。

Sidecar 模式

┌────────────────────┐
│  业务容器 (app)     │ ← 只管业务
│  localhost:8080    │
├────────────────────┤
│  Sidecar (Envoy)   │ ← 代理所有通信
│  流量/安全/监控     │
└────────────────────┘

Istio 控制面配置所有 Envoy Sidecar，数据面执行规则。业务代码零改动。

第二章：核心 CRD

资源	用途
VirtualService	路由规则（匹配条件 → 目标）
DestinationRule	目标策略（负载均衡、TLS、断路器）
Gateway	入口/出口流量
ServiceEntry	网格外服务注册
PeerAuthentication	服务间 mTLS 策略

第三章：流量管理实战

故障注入

spec:
  http:
  - fault:
      delay:
        percentage: { value: 50 }
        fixedDelay: 5s
    route:
    - destination: { host: myapp }

测试服务韧性，模拟 50% 请求延迟 5 秒。

超时与重试

spec:
  http:
  - timeout: 2s
    retries:
      attempts: 3
      perTryTimeout: 1s
    route:
    - destination: { host: myapp }

第四章：可观测性三件套

• Kiali：服务拓扑可视化，实时流量图
• Jaeger：分布式追踪，查看请求全链路
• Grafana：Istio 自带 Dashboard，监控 QPS/延迟/错误率

第五章：Istio 与 API 网关对比

	Istio Gateway	Nginx/Kong
定位	服务网格入口	传统 API 网关
配置方式	YAML CRD	nginx.conf
动态更新	热更新	需 reload
东西向流量	覆盖	不覆盖
侵入性	Sidecar	无侵入

思考题

1. Sidecar 注入增加了每个 Pod 的资源消耗，什么场景不适合用 Service Mesh？
2. Istio 的 VirtualService 和 Kubernetes Service 有什么区别？能否只用 VS 不用 Service？
3. mTLS 自动模式下，为什么我还能看到明文流量？（提示：Permissive 模式）