Istio

在 Amazon EKS 上使用 Istio Service Mesh 的实用指南。

什么是 Istio？

Istio 是一个开源 Service Mesh 平台，用于连接、保护、控制和观测微服务。它管理复杂微服务架构中 Service 之间的通信，并提供流量控制、安全性和可观测性。

Service Mesh 概念

Service Mesh 是管理微服务之间通信的基础设施层。Istio 会在每个 Service 旁部署一个 Sidecar Proxy（Envoy），以拦截和控制所有网络流量。这无需修改应用程序代码即可提供以下能力：

流量路由：智能路由、负载均衡、Canary 部署
安全性：自动 mTLS、身份验证、授权
可观测性：指标、日志、分布式追踪
弹性：Circuit Breaking、Retry、Timeout

实际使用示例

未使用 Istio 的应用程序

使用 Istio 的应用程序 - Envoy Proxy 作为 Sidecar 部署到每个 Service

应用 Istio 后，Envoy Proxy 会自动作为 Sidecar 容器部署到每个微服务中，透明地拦截和控制所有网络流量。

您真的需要 Service Mesh 吗？

Service Mesh 是一个强大的工具，但并不适合所有情况。在采用前需要仔细考虑。

决策流程

何时需要 Service Mesh ✅

1. 复杂的微服务环境

推荐标准：

✅ 10 个或更多微服务
✅ Service 间通信频繁（东西向流量）
✅ 使用多种编程语言（Polyglot）
✅ 多个团队独立开发 Service

2. Zero Trust 安全要求

Service Mesh 提供：

Service 之间自动进行 mTLS 加密
基于 SPIFFE 的身份管理
细粒度的身份验证/授权策略
保证通信加密

替代方案难以实现：

在每个 Service 中重复实现安全逻辑
手动管理证书的复杂性
不一致的安全策略

3. 高级流量管理

yaml

# Canary Deployment (Traffic Distribution)
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10  # Only 10% to new version

适用场景：

Canary 部署、A/B 测试
基于 Header/path 的路由
Traffic Mirroring（Shadow Testing）
Fault Injection（Chaos Engineering）
Circuit Breaking、Retry、Timeout

4. 统一可观测性

Service Mesh 优势：

无需修改应用程序代码即可自动收集指标
自动实现 Distributed Tracing
统一日志格式
Service 拓扑可视化（Kiali）

何时不需要 Service Mesh ❌

1. 简单架构

替代方案：

Kubernetes Ingress Controller（NGINX、Traefik）
简单的负载均衡器
应用程序级实现

2. 微服务数量较少（<10）

开销更大：

Service Mesh 的运维复杂性 > 所获得的收益
5-10 个 Service 可以手动管理
NetworkPolicy 提供足够的安全性

替代方案：

yaml

# Kubernetes NetworkPolicy is sufficient
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

3. 运维资源不足

Service Mesh 运维要求：

Istio/Envoy 专业知识
Control Plane 监控和管理
升级和补丁管理
故障排除能力（调试复杂性增加）

团队所需准备：

至少 1-2 名 Service Mesh 专家
持续学习并跟踪更新
充足的测试环境

4. 对性能要求极高时

Service Mesh 开销：

延迟：+1-3ms（P50）、+5-10ms（P99）
CPU：每个 Pod +10-20%
内存：每个 Pod +50-100MB（Sidecar 模式）

考虑替代方案：

Ambient Mode（资源使用量减少 90%）
基于 CNI 的解决方案（Cilium）
应用程序级优化

替代解决方案比较

功能	Service Mesh	CNI（Cilium）	Ingress Controller	应用程序级
L7 流量管理	✅ 完整支持	⚠️ 有限	⚠️ 仅 Ingress	✅ 可实现
mTLS 自动化	✅ 完整支持	✅ 可实现	❌ 不支持	❌ 手动实现
Distributed Tracing	✅ 自动	❌ 不支持	❌ 不支持	⚠️ 手动实现
L3/L4 策略	✅ 支持	✅ 完整支持	❌ 不支持	❌ 不支持
运维复杂性	🔴 高	🟡 中等	🟢 低	🟡 中等
资源开销	🔴 高（Sidecar） 🟢 低（Ambient）	🟢 低	🟢 低	🟢 无
适用规模	10+ 个 Service	所有规模	小规模	小规模

基于 CNI 的解决方案（Cilium）

Cilium 基于 eBPF 在网络层提供许多功能：

Cilium 更适合的情况：

L3/L4 网络策略是主要目的
高性能是核心要求
希望避免 Service Mesh 的运维负担
仅需要简单的 mTLS 和可观测性

参考：Cilium 文档

决策检查清单

采用前请回答以下问题：

架构：

[ ] 您是否有 10 个或更多微服务？
[ ] Service 间通信是否复杂？
[ ] 是否使用多种编程语言？

安全性：

[ ] 是否需要 Zero Trust 安全模型？
[ ] Service 之间的 mTLS 加密是否是强制要求？
[ ] 是否需要细粒度访问控制？

流量管理：

[ ] 是否需要 Canary 部署、A/B 测试？
[ ] 是否需要高级路由规则？
[ ] 是否需要为许多 Service 使用 Circuit Breaking、Retry？

可观测性：

[ ] Distributed Tracing 是否是强制要求？
[ ] 是否需要统一收集指标？
[ ] 是否需要 Service 拓扑可视化？

运维：

[ ] 您是否拥有 Service Mesh 专家？
[ ] 您能否应对运维复杂性？
[ ] 您能否接受资源开销？

结果：

✅ 勾选 10 项或更多：强烈建议使用 Service Mesh
🟡 勾选 5-9 项：需要谨慎评估，从小规模开始（推荐 Ambient Mode）
❌ 勾选 4 项或更少：考虑替代方案（CNI、Ingress、应用程序级）

渐进式采用策略

如果您确定需要 Service Mesh，请逐步采用：

推荐顺序：

试点项目（1-2 个 namespace）
可观测性优先（指标、日志、追踪）
应用安全性（mTLS PERMISSIVE → STRICT）
流量管理（VirtualService、DestinationRule）
全公司范围扩展

主要功能

流量管理
- 智能路由和负载均衡
- A/B 测试、Canary 部署、Blue/Green 部署
- Circuit Breaking、Retry、Timeout 控制
- Traffic Mirroring 和 Fault Injection
安全性
- Service 之间自动进行 mTLS 加密
- 强身份验证和授权
- 细粒度访问控制策略
- 网络隔离和安全策略
可观测性
- 自动生成指标、日志和追踪
- Prometheus、Grafana、Jaeger、Kiali 集成
- Service 拓扑可视化
- 实时流量监控
弹性
- Circuit Breaker 模式
- Rate Limiting
- Outlier Detection
- Zone Aware Routing

Istio 架构

Istio 由 Control Plane 和 Data Plane 组成：

Control Plane（istiod）：

Pilot：Service 发现、流量路由规则管理
Citadel：证书生成和管理、启用 mTLS
Galley：配置验证和部署

Data Plane：

Envoy Proxy：作为 Sidecar 部署到每个 Pod，拦截和控制所有网络流量

在 Amazon EKS 上使用 Istio 的优势

轻松管理微服务
- 无需修改应用程序代码即可进行流量管理
- 使用声明式配置应用一致的策略
- 使用 Kubernetes Native API
增强安全性
- Service 之间自动加密
- 与 AWS IAM 集成的身份验证
- 细粒度权限控制
提升可观测性
- 与 Amazon CloudWatch 集成
- 通过 AWS X-Ray 进行分布式追踪
- 详细的指标和日志
与 AWS Service 集成
- Application Load Balancer（ALB）集成
- AWS Certificate Manager（ACM）集成
- 与 Amazon EBS CSI Driver 兼容

快速开始

如果您刚开始使用 Istio，请按以下顺序阅读文档：

安装和初始设置：在 EKS 集群上安装 Istio
基本概念：了解 Istio 核心概念
流量管理：学习 Gateway、VirtualService、DestinationRule
安全：配置 mTLS、身份验证、授权
可观测性：收集指标、日志、追踪
最佳实践：生产环境建议

实操示例

每个部分都包含可用的 YAML 示例。所有示例均采用点击复制的结构：

yaml

# Example VirtualService
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1

参考资料

测验

要测试您在本章中学到的知识，请尝试以下测验：

端到端可观测性实验

ArgoCD 详解测验

Istio 详解测验

Linkerd 详解测验

Cilium 服务网格详解测验

Cilium 深入解析

Calico 深入解析

指标

日志

追踪

告警

可观测性实验

ArgoCD

流量管理

安全性

可观测性

弹性

高级

对比指南

指标

日志

追踪

告警

Istio ​

目录 ​

什么是 Istio？ ​

Service Mesh 概念 ​

实际使用示例 ​

您真的需要 Service Mesh 吗？ ​

决策流程 ​

何时需要 Service Mesh ✅ ​

1. 复杂的微服务环境 ​

2. Zero Trust 安全要求 ​

3. 高级流量管理 ​

4. 统一可观测性 ​

何时不需要 Service Mesh ❌ ​

1. 简单架构 ​

2. 微服务数量较少（<10） ​

3. 运维资源不足 ​

4. 对性能要求极高时 ​

替代解决方案比较 ​

基于 CNI 的解决方案（Cilium） ​

决策检查清单 ​

渐进式采用策略 ​

主要功能 ​

Istio 架构 ​

在 Amazon EKS 上使用 Istio 的优势 ​

快速开始 ​

实操示例 ​

参考资料 ​

测验 ​

Istio

目录

什么是 Istio？

Service Mesh 概念

实际使用示例

您真的需要 Service Mesh 吗？

决策流程

何时需要 Service Mesh ✅

1. 复杂的微服务环境

2. Zero Trust 安全要求

3. 高级流量管理

4. 统一可观测性

何时不需要 Service Mesh ❌

1. 简单架构

2. 微服务数量较少（<10）

3. 运维资源不足

4. 对性能要求极高时

替代解决方案比较

基于 CNI 的解决方案（Cilium）

决策检查清单

渐进式采用策略

主要功能

Istio 架构

在 Amazon EKS 上使用 Istio 的优势

快速开始

实操示例

参考资料

测验