Istio 技术栈概览

Istio 是 Google、IBM、Lyft 联合创建的**服务网格（Service Mesh）**平台，是 CNCF 毕业项目。它通过在 Kubernetes Pod 中注入 Envoy Sidecar，以应用无侵入的方式实现流量管理、安全通信（mTLS）、可观测性（Metrics/Logs/Tracing），让开发者专注于业务逻辑。

解决什么问题

• 微服务通信治理与业务代码耦合 → Sidecar 代理透明接管
• 东西向流量不安全 → 自动 mTLS 加密
• 灰度发布/金丝雀部署复杂 → VirtualService + DestinationRule 配置
• 缺乏统一可观测性 → Kiali 可视化 + Jaeger 追踪 + Grafana 监控
• 跨语言治理方案不一致 → Sidecar 模式语言无关

关键特性

• Sidecar 注入：每个 Pod 自动注入 Envoy 代理
• VirtualService：流量路由规则（按 header/cookie/权重分流）
• DestinationRule：目标服务策略（负载均衡、连接池、断路器）
• Gateway：入口流量管理（替代 Nginx/Ingress）
• 自动 mTLS：零配置双向 TLS
• 可观测性：开箱即用的 Kiali Dashboard + Jaeger + Prometheus
• 故障注入：模拟延迟/错误，测试韧性

环境准备

• Kubernetes 集群：1.26+（minikube / kind / 云厂商 K8s）
• kubectl：已配置指向目标集群
• 内存：至少 4GB（Istio 控制面 + Envoy Sidecar 有一定资源消耗）

安装命令

下载 Istio CLI

curl -L https://istio.io/downloadIstio | sh -
cd istio-1.20.*
export PATH=$PWD/bin:$PATH

安装到集群

# 默认 profile（推荐生产可用）
istioctl install --set profile=default -y

# 或最小安装（无 ingress/egress gateway）
istioctl install --set profile=minimal -y

# 验证
istioctl verify-install
kubectl get pods -n istio-system

启用 Sidecar 注入

# 为命名空间启用自动注入
kubectl label namespace default istio-injection=enabled

# 验证
kubectl get namespace -L istio-injection

安装 Kiali Dashboard（可选）

kubectl apply -f samples/addons/
kubectl port-forward svc/kiali 20001:20001 -n istio-system
# 访问 http://localhost:20001

常见问题

Q1: Pod 一直 Pending

集群资源不足。减少副本或增大节点规格。Istio Sidecar 每个 Pod 额外消耗约 50MB 内存。

Q2: 注入后 Pod 无法启动

检查 istioctl analyze 诊断。常见原因：端口命名不符合 Istio 规范（如 http- 前缀缺失）。

Q3: 卸载不干净

istioctl uninstall --purge -y
kubectl delete namespace istio-system
kubectl label namespace default istio-injection-

Istio 例程：基于权重的金丝雀发布

目标

使用 Istio VirtualService + DestinationRule 实现 v1(80%) + v2(20%) 流量分割。

前置：部署两个版本

# app-v1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
  labels:
    app: myapp
    version: v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: app
        image: hashicorp/http-echo
        args:
        - "-text=Hello from v1.0.0"
        - "-listen=:8080"
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
    name: http

# app-v2.yaml（同上，改 version: v2 和 -text="Hello from v2.0.0"）

Istio 流量规则

# istio-routes.yaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: myapp-dr
spec:
  host: myapp
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp-vs
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 80
    - destination:
        host: myapp
        subset: v2
      weight: 20

部署与验证

# 1. 部署应用
kubectl apply -f app-v1.yaml -f app-v2.yaml

# 2. 应用 Istio 规则
kubectl apply -f istio-routes.yaml

# 3. 测试流量分配
kubectl run -it --rm test --image=curlimages/curl --restart=Never -- sh
# 在 Pod 内执行：
for i in $(seq 1 20); do curl -s http://myapp; echo; done

# 预期输出：
# Hello from v1.0.0  (约 16 次)
# Hello from v2.0.0  (约 4 次)

进阶：基于 Header 的 A/B 测试

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp-ab
spec:
  hosts:
  - myapp
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: myapp
        subset: v2
  - route:
    - destination:
        host: myapp
        subset: v1

测试：

curl -H "x-canary: true" http://myapp   # → v2.0.0
curl http://myapp                        # → v1.0.0

核心资源关系

Gateway（入口）
  └── VirtualService（路由规则）
        └── DestinationRule（目标策略）
              ├── subset v1（灰度）
              └── subset v2（正式）

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 模式）