Kubernetes & Amazon EKS Training

中文

한국어
English
日本語
Español

中文

한국어
English
日本語
Español

Appearance

基本概念 ​

本文介绍 Istio 的核心概念和架构。理解这些基本概念对于有效使用 Istio 至关重要。

目录 ​

  1. 背景与历史
  2. 为什么选择 Istio？
  3. Istio 架构
  4. 部署模式：Sidecar 与 Ambient
  5. 核心资源
  6. 流量管理概念
  7. 安全概念
  8. 可观测性概念
  9. Namespace 与 Service Mesh
  10. 后续步骤

背景与历史 ​

Service Mesh 的诞生 ​

Microservices 面临的挑战 ​

2010 年代初期，企业开始将单体应用拆分为 Microservices。

新问题：

问题说明影响
服务间通信网络调用增加延迟、故障传播
可观测性需要分布式追踪调试困难
安全性服务到服务的认证/加密mTLS 实现复杂度
流量控制Canary 部署、A/B 测试需要修改应用代码
故障处理Circuit Breaker、Retry每个服务都需要单独实现

早期解决方案：库 ​

问题：

  • 每种语言都需要开发库（Java 使用 Hystrix，Go 使用单独的库……）
  • 与应用代码紧密耦合
  • 更新时需要重新部署所有服务
  • 版本管理复杂

Service Mesh 的理念：将网络逻辑从应用中移至基础设施层

Envoy Proxy 的诞生 ​

Lyft 面临的问题 ​

2015 年，Lyft 面临以下问题：

  • 运行 200 多个 Microservices
  • 使用多种语言和框架（Python、Go、Java 等）
  • 现有代理（HAProxy、NGINX）能力不足
    • 难以动态更改配置
    • 缺少可观测性
    • 高级路由功能有限

Matt Klein 与 Envoy ​

Matt Klein（Lyft 工程师）于 2016 年将 Envoy 开源。

Envoy 解决的问题：

Envoy 的主要特性：

  1. 进程外架构：与应用分离的独立进程
  2. xDS APIs：动态配置更新
  3. L7 Proxy：支持 HTTP/2、gRPC、WebSocket
  4. 可观测性：详细的 metrics、tracing、logging
  5. 性能：使用 C++ 编写，性能优异

CNCF 接纳 ​

时间线：

  • 2016 年 9 月：Envoy 开源
  • 2017 年 9 月：被接纳为 CNCF 项目（Incubating）
  • 2018 年 11 月：晋升为 CNCF Graduated 项目

Istio 的诞生与历史 ​

Google、IBM 和 Lyft 的合作 ​

2017 年 5 月，Google、IBM 和 Lyft 合作发布 Istio。

各公司贡献：

公司主要贡献原因
GoogleControl Plane 设计Borg、Kubernetes 经验
IBM企业级功能企业客户需求
LyftEnvoy Proxy经生产验证的代理

Istio 版本历史 ​

主要里程碑：

版本 1.5（2020 年 3 月）——重要转折点：

此前的架构（Istio 1.4 及更早版本）：

Separated into individual components:
- Mixer (policy/telemetry)
- Pilot (traffic management)
- Citadel (certificate management)
- Galley (configuration validation)

新架构（Istio 1.5+，当前 1.28）：

Istiod (consolidated into single binary)
├── Pilot functionality (Service Discovery, Traffic Management)
├── Citadel functionality (Certificate Authority, Identity)
└── Galley functionality (Configuration Validation)

Mixer completely removed (functionality moved to Envoy)

变更原因：

  • 降低复杂度（4 个组件 → 1 个）
  • 提升性能（移除 Mixer 后延迟降低 50%）
  • 简化运维（单进程管理）
  • 提高资源效率（减少 memory、CPU 使用量）

为什么选择 Istio？ ​

Kubernetes 提供容器编排能力，但在管理 Microservices 之间的复杂通信方面存在局限。Istio 是用于解决这些问题的 Service Mesh 方案。

Microservices 面临的挑战 ​

Istio 提供的核心价值 ​

1. 流量管理 ​

问题：部署新版本时，希望安全地切换流量。

Istio 解决方案：

yaml
# Canary deployment without code changes
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90  # Existing version 90%
    - destination:
        host: reviews
        subset: v2
      weight: 10  # New version 10%

优势：

  • 无需修改应用代码
  • 实时调整流量分配
  • 支持自动回滚
  • 支持 A/B 测试、Blue/Green 部署

2. 安全性 ​

问题：希望对服务间通信进行加密和认证。

Istio 解决方案：

yaml
# Automatic mTLS enablement
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # Automatic encryption for all inter-service communication

优势：

  • 自动签发和轮换证书
  • 自动验证服务身份
  • 细粒度权限控制
  • 实现 Zero Trust 网络

3. 可观测性 ​

问题：难以追踪跨越数十个 Microservices 的请求流。

Istio 解决方案：

  • 自动生成 metrics（Latency、Traffic、Errors、Saturation）
  • Distributed Tracing
  • Service 拓扑可视化

优势：

  • 自动识别瓶颈
  • 快速定位错误根因
  • 实时监控 Service 状态

4. 弹性 ​

问题：一个 Service 的故障会传播到整个系统。

Istio 解决方案：

yaml
# Automatic Circuit Breaker configuration
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s

优势：

  • 故障隔离（Circuit Breaker）
  • 自动 Retry 和 Timeout
  • 自动移除不健康实例
  • 流量限制（Rate Limiting）

何时使用 Istio ​

✅ 适合使用 Istio 的场景：

  1. Microservices 架构
    • 10 个或更多 Service
    • Service 之间存在复杂依赖关系
    • 频繁部署
  2. 需要高级流量管理
    • Canary 部署、A/B 测试
    • 细粒度路由控制
    • Traffic Mirroring
  3. 严格的安全要求
    • 必须加密服务间通信
    • 细粒度访问控制
    • 合规性要求
  4. 可观测性和调试
    • 追踪复杂的服务间问题
    • 识别性能瓶颈
    • SLO/SLA 监控

❌ Istio 可能过于复杂的场景：

  1. 简单应用
    • Service 数量较少（少于 5 个）
    • 需求简单
    • Kubernetes Ingress 已足够
  2. 资源受限
    • 小型 cluster
    • 无法承受资源开销
    • Sidecar memory 成本负担较重
  3. 缺乏运维能力
    • 学习时间不足
    • 没有专门的平台团队
    • 倾向于更简单的解决方案

替代方案对比 ​

Kubernetes Ingress 与 Istio ​

特性Kubernetes IngressIstio
范围外部 → Cluster外部 + 内部服务间
路由基础（Path、Host）高级（Header、Cookie 等）
mTLS手动配置自动
可观测性有限丰富
复杂度低高
适用场景简单应用Microservices

AWS VPC Lattice 与 Istio ​

有关详细对比，请参阅 AWS Integration 文档。

快速摘要：

  • VPC Lattice：AWS 托管、简单、支持跨 VPC/account 通信
  • Istio：开源、功能强大、仅限 Kubernetes、细粒度控制

Linkerd 与 Istio ​

属性IstioLinkerd
复杂度高低
功能非常丰富仅核心功能
资源高低
学习曲线陡峭平缓
社区大小

选择指南：

  • 需要高级功能和灵活性 → Istio
  • 需要简单轻量的 mesh → Linkerd

部署模式：Sidecar 与 Ambient ​

Istio 支持两种部署模式：Sidecar Mode 和 Ambient Mode。

Sidecar Mode（默认） ​

将 Envoy Proxy 作为 Sidecar container 注入到每个应用 Pod 中。

优势：

  • 成熟稳定
  • 支持所有 Istio 功能
  • 可按 Pod 进行细粒度控制

劣势：

  • 资源开销（每个 Pod 一个 Envoy）
  • 启动时间增加（Init Container）
  • 权限设置复杂（iptables）

Ambient Mode（新方法） ​

无需 Sidecar，而是在 node 层处理流量。

优势：

  • 资源使用量低（每个 node 一个）
  • Pod 启动快速
  • 运维简单
  • 可逐步应用 L7 功能

劣势：

  • 技术相对较新（成熟度较低）
  • 部分高级功能受限
  • 难以按 Pod 进行细粒度控制

对比表 ​

属性Sidecar ModeAmbient Mode
资源使用量高（每个 Pod）低（每个 node）
启动时间慢（Init Container）快
运维复杂度高低
L4 功能支持支持
L7 功能完全支持可选（Waypoint）
成熟度高中
迁移-可从现有 Sidecar 迁移
推荐用途需要高级 L7 功能优先考虑资源效率

选择指南 ​

选择 Sidecar Mode：

  • 需要使用所有 Istio 功能
  • 需要按 Pod 进行细粒度策略控制
  • 需要经生产验证的稳定性

选择 Ambient Mode：

  • 资源效率很重要
  • 仅需要简单的 L4 功能
  • 计划逐步添加 L7 功能

有关详情，请参阅 Advanced: Ambient Mode 文档。

Istio 架构 ​

Istio 由两个主要组件构成：Control Plane 和 Data Plane。

组件说明
Control Plane (istiod)负责 Service Discovery、配置分发和证书管理的中央控制系统
Data Plane (Envoy Proxy)以 Sidecar 形式部署在每个 Pod 中，处理实际流量（路由、mTLS、metrics）

有关详细的架构结构、内部运行原理和流量拦截机制，请参阅 Architecture 文档。

核心资源 ​

Istio 使用 Kubernetes Custom Resource Definitions（CRDs）管理配置。

1. VirtualService ​

VirtualService 定义请求如何路由到 Service。

yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews  # Target service
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2  # Route specific user to v2
  - route:
    - destination:
        host: reviews
        subset: v1  # Route to v1 by default

主要特性：

  • 基于路径的路由（Path、Header、Query Parameter）
  • 流量拆分（Canary、A/B 测试）
  • Retry、Timeout、Fault Injection
  • URL Rewrite、Header 操作

2. DestinationRule ​

DestinationRule 定义 Service subset（版本）并应用流量策略。

yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST  # Load balancing algorithm
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

主要特性：

  • Service 版本（subset）定义
  • Load balancing 算法
  • Connection Pool 设置
  • Circuit Breaker（Outlier Detection）
  • TLS 设置

3. Gateway ​

Gateway 管理进入 mesh 的外部流量。

yaml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway  # Select Ingress Gateway pod
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bookinfo.example.com"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: bookinfo-credential  # TLS certificate
    hosts:
    - "bookinfo.example.com"

主要特性：

  • 定义外部流量入口点
  • Host、port、protocol 设置
  • TLS termination
  • SNI 路由

4. ServiceEntry ​

ServiceEntry 使 mesh 外的外部 Service 能够像内部 Service 一样使用。

yaml
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-api
spec:
  hosts:
  - api.external.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

主要特性：

  • 外部 Service 注册
  • 外部 Service 的流量控制
  • Egress 流量管理

5. PeerAuthentication ​

PeerAuthentication 定义 Service 之间的认证策略。

yaml
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # STRICT, PERMISSIVE, DISABLE

6. AuthorizationPolicy ​

AuthorizationPolicy 定义 Service 访问权限。

yaml
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-ratings
  namespace: default
spec:
  selector:
    matchLabels:
      app: ratings
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/reviews"]
    to:
    - operation:
        methods: ["GET"]

流量管理概念 ​

流量路由流程 ​

流量拆分（Canary 部署） ​

yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-canary
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90  # 90% of traffic
    - destination:
        host: reviews
        subset: v2
      weight: 10  # 10% of traffic (canary)

Circuit Breaker ​

yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-circuit-breaker
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

安全概念 ​

mTLS（Mutual TLS） ​

Istio 会自动加密服务间通信。

mTLS 模式：

  • STRICT：仅允许 mTLS
  • PERMISSIVE：同时允许 mTLS 和明文（用于迁移）
  • DISABLE：禁用 mTLS

Authentication 与 Authorization ​

yaml
# JWT Authentication
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-auth
spec:
  jwtRules:
  - issuer: "https://accounts.google.com"
    jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
---
# Authorization Policy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
spec:
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

可观测性概念 ​

Istio 自动生成 metrics、logs 和 traces。

自动生成的 Metrics ​

关键 Metrics ​

Metric说明
istio_requests_total请求总数
istio_request_duration_milliseconds请求延迟
istio_request_bytes请求大小
istio_response_bytes响应大小
istio_tcp_connections_opened_totalTCP 连接数

Distributed Tracing ​

yaml
# Enable tracing in Envoy
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100.0  # 100% sampling
        zipkin:
          address: jaeger-collector.istio-system:9411

Namespace 与 Service Mesh ​

Namespace 隔离 ​

yaml
# Per-namespace mTLS policy
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
# Per-namespace authorization policy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  action: DENY
  rules:
  - {}

Service Mesh 范围 ​

bash
# Include only specific namespaces in the mesh
kubectl label namespace default istio-injection=enabled
kubectl label namespace staging istio-injection=enabled

# Exclude specific namespace
kubectl label namespace kube-system istio-injection=disabled

Multi-tenancy ​

yaml
# Restrict mesh scope with Sidecar resource
apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: production
spec:
  egress:
  - hosts:
    - "production/*"  # Only production namespace accessible
    - "istio-system/*"

VM Workload 注册 ​

Istio 不仅可以在 Service Mesh 中注册 Kubernetes Pod，还可以注册 Virtual Machine（VM）Workload。这使 legacy application 或 cluster 外的 Service 能够使用 Istio 的流量管理、安全和可观测性功能。

为什么需要 VM Workload ​

使用场景：

  • 逐步迁移 legacy application
  • 将 database server 纳入 mesh
  • 集成 cluster 外的 Service
  • 配置 hybrid cloud 环境

VM 注册架构 ​

WorkloadEntry 资源 ​

VM Workload 使用 WorkloadEntry 资源进行注册。

yaml
apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: legacy-database
  namespace: default
spec:
  address: 192.168.1.100  # VM IP address
  labels:
    app: mysql
    version: v5.7
  serviceAccount: database-sa
  ports:
    mysql: 3306

WorkloadEntry 关键字段：

  • address：VM IP 地址
  • labels：与 Service selector 匹配
  • serviceAccount：用于 mTLS authentication 的 Service account
  • ports：暴露的 port 定义

与 ServiceEntry 集成 ​

WorkloadEntry 与 ServiceEntry 一起使用，将 VM Service 注册到 mesh 中。

yaml
# Define service with ServiceEntry
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: legacy-database
spec:
  hosts:
  - database.legacy.com
  ports:
  - number: 3306
    name: mysql
    protocol: TCP
  location: MESH_INTERNAL  # Register as internal mesh service
  resolution: STATIC
  workloadSelector:
    labels:
      app: mysql
---
# Register VM instance with WorkloadEntry
apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: mysql-vm-1
  namespace: default
spec:
  address: 192.168.1.100
  labels:
    app: mysql
    version: v5.7
  serviceAccount: mysql-sa

VM 注册与 Multi-Cluster 对比 ​

特性VM Workload 注册Multi-ClusterKubernetes Pod
Workload 位置cluster 外的 VM不同的 Kubernetes clustercluster 内
Envoy 安装手动安装自动（Sidecar）自动（Sidecar）
注册方式WorkloadEntryServiceEntry + EndpointSliceService + Pod
mTLS支持支持支持
Service Discovery手动（指定 IP）自动自动
使用场景Legacy app、DBMulti-cloud、disaster recoveryCloud-native app
运维复杂度高中低

VM 注册的优势 ​

1. 逐步迁移 ​

优势：

  • 无需修改即可将现有 VM application 集成到 mesh
  • 分阶段迁移到 Kubernetes
  • 在迁移期间保持一致的安全性和可观测性

2. 统一安全策略 ​

yaml
# mTLS policy applied to both VMs and pods
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # Enforce mTLS for both VMs and pods
---
# VM database access control
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: database-access
  namespace: default
spec:
  selector:
    matchLabels:
      app: mysql  # WorkloadEntry label
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/app-sa"]
    to:
    - operation:
        methods: ["*"]

3. 一致的可观测性 ​

VM Workload 提供与 Kubernetes Pod 相同的 metrics、logs 和 distributed tracing。

promql
# Unified metric query for VMs and pods
sum(rate(istio_requests_total{destination_workload="mysql-vm-1"}[5m]))

# Error rate from VM
sum(rate(istio_requests_total{destination_workload="mysql-vm-1",response_code="500"}[5m]))
/
sum(rate(istio_requests_total{destination_workload="mysql-vm-1"}[5m]))

VM 注册的限制 ​

  1. 手动安装 Envoy：必须在 VM 上手动安装和配置 Envoy Proxy
  2. 网络连通性：VM 与 Kubernetes cluster 之间需要网络连接
  3. 证书管理：必须将 Service account certificate 部署到 VM
  4. 运维负担：需要管理和更新 VM Envoy 版本
  5. 自动扩缩容限制：没有 Kubernetes HPA 那样的自动扩缩容能力

实际使用示例 ​

场景：Legacy Database 集成 ​

yaml
# 1. Define database service with ServiceEntry
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: legacy-postgres
  namespace: production
spec:
  hosts:
  - postgres.production.svc.cluster.local
  addresses:
  - 240.240.1.10  # Virtual IP
  ports:
  - number: 5432
    name: postgresql
    protocol: TCP
  location: MESH_INTERNAL
  resolution: STATIC
  workloadSelector:
    labels:
      app: postgres
      tier: database
---
# 2. Register VM instance with WorkloadEntry
apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: postgres-vm-1
  namespace: production
spec:
  address: 10.0.1.100  # Actual VM IP
  labels:
    app: postgres
    tier: database
    version: v13
  serviceAccount: postgres-sa
  ports:
    postgresql: 5432
---
# 3. Access control policy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: postgres-access-control
  namespace: production
spec:
  selector:
    matchLabels:
      app: postgres
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["production"]
        principals: ["cluster.local/ns/production/sa/api-service"]
    to:
    - operation:
        ports: ["5432"]

结果：

  • Kubernetes Pod 通过 postgres.production.svc.cluster.local 访问 database
  • VM 与 Pod 之间自动进行 mTLS 加密
  • 应用访问控制策略
  • 自动收集 metrics 和 distributed tracing

Workload 注册对比摘要 ​

通过 Istio 灵活的 Workload 注册能力：

  • Kubernetes Pod：Cloud-native application
  • Multi-Cluster：Multi-cloud、区域分布、disaster recovery
  • Virtual Machine：Legacy app、database、hybrid 环境

所有 Workload 都能获得一致的安全性、流量管理和可观测性功能。

后续步骤 ​

现在你已经了解 Istio 的基本概念。请通过以下文档学习如何在实践中使用它们：

核心功能 ​

  1. Traffic Management
    • Gateway 和 VirtualService 的用法
    • DestinationRule 和 subset 定义
    • ServiceEntry 和 WorkloadEntry（VM 注册）
    • 高级路由模式（Canary、A/B 测试）
    • Traffic Mirroring 和 Shadowing
  2. Security
    • mTLS 配置和 PeerAuthentication
    • Authentication（RequestAuthentication、JWT）
    • Authorization（AuthorizationPolicy）
    • Security policy 管理
    • 外部 Authentication 集成
  3. Observability
    • Metric 收集（Prometheus）
    • Distributed tracing（Jaeger、Zipkin）
    • Logging 配置
    • Kiali Service Mesh 可视化
    • Grafana dashboards
  4. Resilience
    • Circuit Breaker 模式
    • Retry 和 Timeout 设置
    • Rate Limiting
    • Outlier Detection
    • Fault Injection 测试

高级主题 ​

  1. Advanced Topics
    • Ambient Mode（无 Sidecar 的 mesh）
    • Multi-Cluster 配置
    • EnvoyFilter 自定义
    • DNS Proxy 和 Caching
    • VM Workload 详细配置
    • WASM plugin 开发

参考资料 ​