云原生技术-服务网格（Service Mesh）

收藏 2025-11-20

服务网格基本概念

1.1 什么是服务网格？

服务网格是一种专门用于处理服务间通信的基础设施层，它建立在容器编排平台（例如Kubernetes）之上，旨在为微服务架构提供高效、安全且可靠的通信机制。

1.2 核心架构

数据平面（Data Plane）

数据平面由一系列Sidecar代理构成，每个微服务实例旁边都会部署一个这样的代理，负责处理所有进出的网络流量。主要组件包括Envoy、Linkerd-proxy等。

控制平面（Control Plane）

控制平面负责管理和配置所有的Sidecar代理，提供诸如服务发现、负载均衡、证书管理等功能。主要组件有Istiod（Istio）、Linkerd（控制平面）等。

1.3 核心特性

透明代理：业务代码无需意识到服务网格的存在。
可观测性：提供详尽的指标、日志和追踪信息。
流量管理：具备精细的流量控制能力。
安全性：支持自动mTLS、认证授权等安全措施。
韧性：包括熔断、重试、超时及故障注入等功能。

服务网格的核心作用

2.1 流量管理

服务网格提供了动态路由、流量镜像、智能负载均衡以及故障恢复等多种流量管理功能，支持金丝雀发布、蓝绿部署和A/B测试等场景。

2.2 可观测性

通过收集延迟、错误率、流量等关键指标，提供分布式的追踪能力和可视化服务依赖关系图，帮助运维人员更好地理解系统运行状况。

2.3 安全性

服务网格确保服务间通信的安全性，通过自动mTLS加密、基于身份的细粒度策略控制和自动证书管理，增强了系统的整体安全性。

2.4 运维简化

服务网格实现了应用与基础设施的解耦，使业务开发者可以更加专注于业务逻辑的开发，同时提供统一的技术栈和多语言支持，降低了运维复杂度。

配置命令详解（以Istio为例）

3.1 安装与基础配置

首先，需要安装Istio。

# 下载Istio
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
   # 将当前目录下的 bin 子目录添加到系统的 PATH 环境变量中，并使其优先级高于其他已存在的路径

# 安装Istio到Kubernetes集群
istioctl install --set profile=demo -y

# 给namespace添加标签，启用自动Sidecar注入
kubectl label namespace default istio-injection=enabled

安装完成后，可以通过以下命令验证安装情况：

# 检查控制平面状态
kubectl get pods -n istio-system

# 检查Sidecar注入器
kubectl get mutatingwebhookconfigurations

# 查看已安装的CRD
kubectl get crd | grep istio.io

3.2 核心CRD配置命令

VirtualService - 虚拟服务

VirtualService用于定义HTTP请求的路由规则，例如将所有发往特定服务的请求路由到其特定版本。

# 创建虚拟服务
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
    # 指定 Istio API 版本（v1beta1），表明这是 Istio 的流量管理资源。
kind: VirtualService
    # 定义 Istio 的虚拟服务，用于控制服务间流量的路由规则。
metadata:
  name: productpage
    # 资源名称（productpage），需在集群内唯一
spec:
  hosts:
  - productpage
    # 指定规则适用的目标服务（这里是 productpage）
    # 可以是 Kubernetes Service 名称、DNS 名称或 Istio 的通配符（如 *.example.com）
  http:
  - route:
    # 定义 HTTP 流量的路由规则
    - destination:
        host: productpage
            # 目标服务（仍为 productpage，表示流量仍发往该服务）
        subset: v1
            # 指定子集（v1），需对应 DestinationRule 中定义的子集（如版本标签 v1）
EOF

# 查看虚拟服务
kubectl get virtualservice
kubectl describe virtualservice productpage

流量路由的基本概念：

productpage

具体操作示例：

v1

在配置前，需确保已创建相应的DestinationRule，定义了服务的不同版本。

DestinationRule

DestinationRule的定义：

subset: v1

基于Pod标签的子集定义：

version: v1

典型使用场景包括金丝雀发布、A/B测试和故障注入。

v2

v1

VirtualService

http:
- route:
  - destination:
      host: productpage
      subset: v1
    weight: 90
  - destination:
      host: productpage
      subset: v2
    weight: 10

Cookie

fault

timeout

DestinationRule - 目标规则

DestinationRule用于对Kubernetes服务的流量进行细粒度控制，特别适用于定义服务的不同版本。

# 创建目标规则定义子集
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1    
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
    # 指定规则适用的目标服务名称（对应 Kubernetes Service 的 metadata.name）
    # Istio 会将此规则应用到所有流量发往 productpage 服务的请求
  subsets:
    # 定义服务的子集（版本分组），每个子集通过 labels 选择器匹配 Pod
    # 子集名称（如 v1）会被 VirtualService 引用，实现精准路由
  - name: v1    
    labels:
      version: v1    # 匹配带有标签 version: v1 的 Pod
  - name: v2
    labels:
      version: v2    # 匹配带有标签 version: v2 的 Pod
EOF

DestinationRule的主要功能包括定义子集、设置负载均衡策略和配置流量策略。

DestinationRule

实际工作原理：

subset

version=v1

productpage

ServiceEntry - 服务入口

ServiceEntry的主要功能是将外部服务纳入网格，使网格内的服务能够通过Istio的流量管理、安全策略和可观测性功能访问外部API。

ServiceEntry

ServiceEntry还用于控制出口流量，确保只有明确允许的外部服务才能被访问，从而提高安全性。

# 允许访问外部服务
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: external-api
spec:
  hosts:
  - api.external.com
    # 指定外部服务的主机名（如 api.external.com）
    # Istio 会拦截发往这些主机的流量，并根据规则处理（如路由、策略应用）
  ports:    # 定义外部服务的端口配置
  - number: 443    # 目标端口
    name: https    # 端口名称（可任意，但建议语义化）
    protocol: HTTPS    # 协议类型（支持 HTTP、HTTPS、TCP、TLS 等）
    # 如果外部服务使用 HTTP 但需强制 HTTPS，可通过 TLS 协议配置
  resolution: DNS
    # 指定如何解析主机名
        # DNS：通过 DNS 解析主机名（适用于大多数外部服务）
        # STATIC：直接使用端点 IP（需配合 endpoints 字段）
        # NONE：不解析（通常用于 Unix 域套接字）
  location: MESH_EXTERNAL
    # 声明服务位于网格外部（默认值）
    # MESH_INTERNAL：表示服务实际运行在网格内（但未通过 Kubernetes Service 暴露，较少用）
    # 此字段影响 Istio 的某些默认行为（如是否启用双向 TLS）
EOF

实际工作原理：

api.external.com:443

ServiceEntry

# DestinationRule 示例：强制使用 TLS
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: external-api-tls
spec:
  host: api.external.com
  trafficPolicy:
    tls:
      mode: SIMPLE # 启用 TLS

Gateway

# ServiceEntry 修改为通过出口网关访问
location: MESH_EXTERNAL
exportTo: ["."] # 限制作用域

3.3 安全配置命令

PeerAuthentication用于配置对等认证。

# 启用严格mTLS
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT
EOF

# 查看对等认证策略
kubectl get peerauthentication

AuthorizationPolicy用于定义授权策略。

# 创建拒绝所有流量的默认策略
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  {}
EOF

# 创建允许特定服务的策略
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-productpage
spec:
  selector:
    matchLabels:
      app: productpage
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-gateway"]
    to:
    - operation:
        methods: ["GET"]
EOF

3.4 监控与诊断命令

查看Sidecar状态：

# 检查特定Pod的Sidecar状态
kubectl get pods -l app=productpage
istioctl proxy-status
istioctl proxy-config clusters productpage-v1-7f44c4d57c-abcde
istioctl proxy-config listeners productpage-v1-7f44c4d57c-abcde

流量监控：

# 查看服务网格流量指标
kubectl exec -it deploy/sleep -- curl http://prometheus:9090/api/v1/query?query=istio_requests_total

# 访问Kiali仪表板（需要先安装）
istioctl dashboard kiali

经典配置案例详解：金丝雀发布

4.1 场景描述

我们将为一个名为

reviews

的应用实施金丝雀发布。

4.1 金丝雀发布的服务实施

逐步将流量从v1版本迁移到v2版本。

4.2 部署准备工作

部署两个版本的服务

# 部署v1版本
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: reviews-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: reviews
      version: v1
  template:
    metadata:
      labels:
        app: reviews
        version: v1
    spec:
      containers:
      - name: reviews
        image: istio/examples-bookinfo-reviews-v1:1.16.2
        ports:
        - containerPort: 9080
EOF

# 部署v2版本
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: reviews-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: reviews
      version: v2
  template:
    metadata:
      labels:
        app: reviews
        version: v2
    spec:
      containers:
      - name: reviews
        image: istio/examples-bookinfo-reviews-v2:1.16.2
        ports:
        - containerPort: 9080
EOF

# 创建Service
kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: reviews
spec:
  selector:
    app: reviews
  ports:
  - port: 9080
    name: http
EOF

4.3 目标规则配置

定义子集

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
EOF

4.4 金丝雀发布策略

阶段一：100%流量到v1（基线）

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 100
    - destination:
        host: reviews
        subset: v2
      weight: 0
EOF

阶段二：90% v1, 10% v2（小规模测试）

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10
EOF

阶段三：50% v1, 50% v2（中等规模）

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 50
    - destination:
        host: reviews
        subset: v2
      weight: 50
EOF

阶段四：100% v2（完全切换）

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 0
    - destination:
        host: reviews
        subset: v2
      weight: 100
EOF

4.5 高级流量管理

基于HTTP头的路由

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews    # 目标服务名称
  http:
  # 第一条规则：匹配 User-Agent 包含 "Mobile" 的请求
  - match:
    - headers:
        user-agent:
          regex: .*Mobile.*    # 正则匹配
    route:
    - destination:
        host: reviews
        subset: v2    # 路由到 v2
  # 第二条规则：默认权重路由（剩余请求）
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80    # 80% 流量
    - destination:
        host: reviews
        subset: v2
      weight: 20    # 20% 流量
EOF

实际工作原理

1. 流量匹配顺序

Istio Sidecar（Envoy）按顺序匹配流量规则。

http

规则：

先检查请求头是否包含 "Mobile"。
如果匹配，则路由到指定路径（跳过后续规则）。
否则，进入第二条规则，按权重分配流量。

User-Agent

v2

2. 典型场景

移动端优化：将移动用户的流量路由到专门优化的版本。

v2

金丝雀发布：对非移动用户逐步放量（80%到一个版本，20%到另一个版本）。

v1

故障注入测试：

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews    # 目标服务名称
  http:
  # 第一条规则：注入延迟故障（仅影响 50% 的请求） 
  # fault 故障注入配置，用于模拟服务故障（如延迟、中止） 
  - fault:
      delay:
        percentage:
          value: 50    # 对 50% 的请求生效
        fixedDelay: 7s    # 强制延迟 7 秒
    route:
    - destination:
        host: reviews
        subset: v1 # 故障请求路由到 v1
  # 第二条规则：默认路由（剩余 100% 请求）
  - route:
    - destination:
        host: reviews
        subset: v2    # 正常请求路由到 v2
EOF

实际工作原理（续）

1. 流量匹配

当客户端请求服务时，Istio Sidecar（Envoy）会按顺序匹配规则。

先检查是否命中特定规则（50%概率）。
未命中的请求走第二条默认路由。

reviews

fault

2. 故障注入

如果请求被特定规则选中（50%概率）：

Envoy 会强制延迟 7 秒后再将请求转发到目标服务。
如果目标服务的超时时间短于 7 秒，客户端会收到超时响应。
剩余 50% 的请求直接路由到目标服务，无延迟。

fault

v1

timeout

504 Gateway Timeout

3. 典型用途

测试弹性：验证客户端和服务是否能正确处理延迟（如重试、熔断逻辑）。
金丝雀测试：将故障请求路由到一个版本，正常请求路由到另一个版本，对比两者行为。

4.6 超时与重试配置

实际工作原理：

1. 当客户端发送请求到服务时，Istio Sidecar（Envoy）会根据预设规则处理请求。

2. 请求会被路由到服务的特定子集（需通过定义子集对应的 Pod 标签）。

3. 如果请求超时（超过 3 秒）或失败（符合特定条件），Envoy 会重试最多 3 次（每次最多等待 2 秒）。

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews    # 指定此VirtualService适用的目标服务reviews
  http:    # 定义 HTTP流量的路由规则
  - route:    # 指定流量的目标地址destination
    - destination:
        host: reviews    # 目标服务名称（必须与 hosts 字段一致）
        subset: v1    # 将流量路由到 reviews 服务的 v1 子集
    timeout: 3s    
      # 设置请求的超时时间为 3 秒。如果后端服务未在 3 秒内响应，Envoy 会返回 504 Gateway Timeout
    retries:    # 定义重试策略
      attempts: 3    # 最多重试 3 次（实际请求 = 1 次初始请求 + 3 次重试 = 最多 4 次尝试）
      perTryTimeout: 2s    # 每次重试的超时时间为 2 秒
      retryOn: connect-failure,refused-stream,unavailable
        # 触发重试的条件（支持以下值，用逗号分隔）
            # connect-failure：连接后端失败（如网络错误）
            # refused-stream：后端拒绝流（如 HTTP/2 错误）
            # unavailable：后端返回 503 错误
EOF

http://reviews:9080

VirtualService

v1

DestinationRule

version: v1

retryOn

4.7 监控与验证

查看流量分布

# 通过Istio指标查看流量分布
kubectl exec -it deploy/sleep -- sh -c 'curl -s "http://prometheus:9090/api/v1/query?query=istio_requests_total{reporter=\"destination\",destination_service=\"reviews.default.svc.cluster.local\"}"' | jq '.data.result[].metric.destination_version'

# 查看Kiali仪表板观察流量分布
istioctl dashboard kiali

检查配置状态

# 验证VirtualService配置
kubectl get virtualservice reviews -o yaml

# 检查Sidecar配置
istioctl proxy-config route $(kubectl get pod -l app=productpage -o jsonpath='{.items[0].metadata.name}') --name 9080 -o json

五、总结

服务网格通过以下方式彻底改变了微服务通信：

传统方式	服务网格方式
在应用代码中处理网络逻辑	网络逻辑下沉到基础设施层
每个服务实现自己的重试、熔断	统一的策略管理
难以实现细粒度流量控制	精细的流量管理能力
监控分散，难以关联	统一的可观测性

核心价值：

开发者生产力：业务开发者专注于业务逻辑。
运维标准化：统一的网络策略和运维模式。
架构韧性：自动化的故障恢复能力。
安全增强：零信任网络的安全模型。

服务网格是现代微服务架构的关键基础设施，Istio作为其中的代表性项目，提供了完整的企业级服务网格解决方案。

扫码加我拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

栏目导航