楼主: 星星纸鸢
43 0

[学科前沿] 云原生技术-服务网格(Service Mesh) [推广有奖]

  • 0关注
  • 0粉丝

等待验证会员

学前班

40%

还不是VIP/贵宾

-

威望
0
论坛币
0 个
通用积分
0
学术水平
0 点
热心指数
0 点
信用等级
0 点
经验
20 点
帖子
1
精华
0
在线时间
0 小时
注册时间
2018-12-22
最后登录
2018-12-22

楼主
星星纸鸢 发表于 2025-11-20 07:03:41 |AI写论文

+2 论坛币
k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群
赵安豆老师微信:zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

感谢您参与论坛问题回答

经管之家送您两个论坛币!

+2 论坛币

服务网格基本概念

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作为其中的代表性项目,提供了完整的企业级服务网格解决方案。

二维码

扫码加我 拉你入群

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

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

关键词:service MESH mes ice 服务网

您需要登录后才可以回帖 登录 | 我要注册

本版微信群
扫码
拉您进交流群
GMT+8, 2026-2-9 15:44