服务网格迁移实战

将现有系统迁移到服务网格是一个复杂工程，涉及技术评估、架构改造、灰度验证等多个阶段。本文提供一个完整的迁移实战指南。

迁移准备阶段

需求评估

在开始迁移前，需要明确回答以下问题：

问题	评估要点
为什么需要服务网格？	流量治理、安全、可观测性
当前痛点是什么？	列出具体问题
迁移的收益是什么？	量化收益
可以承受的代价是什么？	延迟、资源、成本

环境准备

flowchart TB
    subgraph 环境
        Dev["开发环境"]
        Test["测试环境"]
        Staging["预发布环境"]
        Prod["生产环境"]
    end

    迁移路径: Dev --> Test --> Staging --> Prod

环境	用途	服务数量	建议
开发	开发调试	少量	可选
测试	功能验证	全部	必须
预发布	灰度验证	全部	推荐
生产	正式运行	全部	最后阶段

迁移策略

策略一：渐进式迁移

flowchart LR
    A["1. 部分服务加入网格"] --> B["2. 观察验证"]
    B --> C["3. 扩大范围"]
    C --> D["4. 全量加入"]

优点：

风险可控
可以快速回滚
逐步积累经验

缺点：

迁移周期长
需要双轨运行

策略二：Big Bang 迁移

优点：

迁移周期短
避免长期双轨

缺点：

风险集中
回滚困难

适用场景：小型系统、测试环境

推荐：渐进式 + 蓝绿

blue-green-migration.yaml

# 策略：保持新旧两套，逐步切换
# 阶段 1: v1 (非网格) 100%
# 阶段 2: v1 (网格) 10%, v1 (非网格) 90%
# 阶段 3: v1 (网格) 50%, v1 (非网格) 50%
# 阶段 4: v1 (网格) 100%

迁移步骤详解

步骤一：环境检查

# 检查 Kubernetes 版本
kubectl version --short

# 检查 Istio/Linkerd 支持的 K8s 版本
# Istio 1.20: Kubernetes 1.25+
# Linkerd: Kubernetes 1.21+

# 检查集群资源
kubectl describe nodes

# 检查 RBAC 配置
kubectl auth can-i --list --as=system:serviceaccount:istio-system:istiod

步骤二：安装控制平面

# Istio 安装
istioctl install --set profile=default -y

# 验证安装
istioctl verify-install

# 检查组件
kubectl get pods -n istio-system

步骤三：选择试点服务

选择试点服务的标准：

标准	说明
业务重要性	非核心服务优先
流量复杂度	简单调用链优先
团队熟悉度	团队熟悉的服务优先
技术栈	标准技术栈优先

推荐试点顺序：

网关服务：承载入口流量，便于观察
下游依赖少的服务：减少影响因素
读多写少的服务：问题影响较小
核心服务：积累经验后再迁移

步骤四：应用改造

4.1 启用 Sidecar 注入

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

# 查看注入状态
kubectl get namespace -l istio-injection

4.2 应用配置

app-config.yaml

# 1. 创建 DestinationRule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
---
# 2. 创建基础 VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
          weight: 100

步骤五：验证功能

# 1. 检查 Sidecar 注入
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].name}'

# 2. 检查 xDS 配置
istioctl proxy-config cluster <pod-name>

# 3. 测试服务连通性
kubectl exec -it <test-pod> -c istio-proxy -- curl http://<service-name>:8080/health

# 4. 检查 mTLS
istioctl x authz check <pod-name>

步骤六：监控配置

monitoring-config.yaml

# 确认 Prometheus 抓取配置
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: istio-component-monitor
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      istio: pilot
  namespaceSelector:
    matchNames:
      - istio-system
  endpoints:
    - port: http-monitoring
      interval: 15s

常见问题与解决

问题一：服务无法注册到网格

# 排查步骤
# 1. 检查 Sidecar 是否注入
kubectl describe pod <pod-name> | grep -A 5 "Containers"

# 2. 检查 Istiod 是否正常运行
kubectl get pods -n istio-system -l app=istiod

# 3. 检查 xDS 连接
istioctl proxy-status

# 4. 查看 Sidecar 日志
kubectl logs <pod-name> -c istio-proxy

问题二：mTLS 握手失败

mtls-troubleshoot.yaml

# 检查 mTLS 配置
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: <namespace>
spec:
  mtls:
    mode: PERMISSIVE  # 临时改为 PERMISSIVE 排查

# 验证证书
istioctl x pc secret <pod-name>

问题三：流量路由异常

# 检查 VirtualService
kubectl get virtualservice

# 查看路由配置
istioctl proxy-config route <pod-name>

# 分析配置
istioctl analyze

迁移 CheckList

迁移前检查

## 迁移前检查清单

### 环境准备
- [ ] Kubernetes 版本符合要求
- [ ] 集群资源充足（CPU/内存）
- [ ] 网络插件支持
- [ ] RBAC 权限配置正确

### 工具准备
- [ ] istioctl/linkerd CLI 安装
- [ ] kubectl 配置正确
- [ ] 监控工具就绪

### 知识准备
- [ ] 团队完成培训
- [ ] 故障处理流程确定
- [ ] 回滚方案就绪

### 配置准备
- [ ] 基础配置模板
- [ ] 命名规范
- [ ] 文档就绪

迁移中检查

## 迁移中检查清单

### Sidecar 注入
- [ ] Sidecar 正常注入
- [ ] Sidecar 启动成功
- [ ] 健康检查通过

### 功能验证
- [ ] 服务发现正常
- [ ] 服务调用正常
- [ ] mTLS 正常
- [ ] 健康检查正常

### 监控验证
- [ ] 指标正常上报
- [ ] 追踪正常生成
- [ ] 日志正常收集

### 流量验证
- [ ] 入口流量正常
- [ ] 出口流量正常
- [ ] 路由规则生效

迁移后检查

## 迁移后检查清单

### 业务验证
- [ ] 核心功能正常
- [ ] 性能无明显下降
- [ ] 错误率未增加

### 监控验证
- [ ] 告警正常触发
- [ ] Dashboard 正常显示
- [ ] 日志可关联

### 文档更新
- [ ] 架构文档更新
- [ ] 运维手册更新
- [ ] 监控配置更新

回滚策略

自动回滚

rollback-config.yaml

# 设置 rollback 注解
apiVersion: v1
kind: Deployment
metadata:
  name: my-service
  annotations:
    # 如果 Sidecar 有问题，自动移除
    sidecar.istio.io/inject: "false"
spec:
  # ...

手动回滚

# 1. 移除 Sidecar 注入
kubectl label namespace <namespace> istio-injection-

# 2. 重启 Pod（移除 Sidecar）
kubectl rollout restart deployment -n <namespace>

# 3. 验证
kubectl get pod -n <namespace>

性能验证

对比测试

#!/bin/bash
# 对比测试脚本

# 测试前（无网格）
echo "Testing before mesh..."
fortio load -c 10 -qps 100 -t 60s http://service:8080/api > before.json

# 迁移后
echo "Testing after mesh..."
fortio load -c 10 -qps 100 -t 60s http://service:8080/api > after.json

# 对比结果
echo "=== Performance Comparison ==="
echo "Before: $(cat before.json | jq '.DurationHistogram.Percentile99')"
echo "After: $(cat after.json | jq '.DurationHistogram.Percentile99')"

阈值定义

指标	可接受范围	告警阈值
P99 延迟增加	< 5ms	> 10ms
错误率	< 0.1%	> 1%
成功率	> 99.9%	< 99%
吞吐量下降	< 10%	> 20%

总结

服务网格迁移是一个系统工程：

阶段	关键任务
准备	需求评估、环境准备、团队培训
试点	选择试点服务、验证基础功能
扩展	逐步扩大范围、持续验证
全量	生产迁移、监控完善
优化	配置调优、文档完善

成功关键：

渐进式推进：不要急于求成
充分测试：每个阶段都要充分验证
快速回滚：出现问题可以快速恢复
持续监控：实时掌握系统状态
团队协作：各团队紧密配合

延伸思考：迁移完成不是终点，而是起点。服务网格的能力需要持续挖掘——从基础的流量管理到高级的安全策略，从简单的监控到深入的链路分析，才能真正发挥服务网格的价值。

服务网格迁移实战#

#迁移准备阶段

#需求评估

#环境准备

#迁移策略

#策略一：渐进式迁移

#策略二：Big Bang 迁移

#推荐：渐进式 + 蓝绿

#迁移步骤详解

#步骤一：环境检查

#步骤二：安装控制平面

#步骤三：选择试点服务

#步骤四：应用改造

#4.1 启用 Sidecar 注入

#4.2 应用配置

#步骤五：验证功能

#步骤六：监控配置

#常见问题与解决

#问题一：服务无法注册到网格

#问题二：mTLS 握手失败

#问题三：流量路由异常

#迁移 CheckList

#迁移前检查

#迁移中检查

#迁移后检查

#回滚策略

#自动回滚

#手动回滚

#性能验证

#对比测试

#阈值定义

#总结