如何设置A/B测试和Canary发布，确保AI服务平滑升级？

在AI模型部署中，确保新模型版本的稳定性和性能至关重要。直接将新模型全面上线（Big Bang Release）风险极高。A/B测试和Canary发布是两种主流的渐进式发布策略，它们允许我们在生产环境中安全地验证新模型。

我们将重点介绍如何使用强大的服务网格 Istio 在 Kubernetes 环境下实现这两种策略。Istio通过流量管理规则（如VirtualService和DestinationRule）提供了精确到百分比和基于内容的路由能力。

1. 环境准备与模型部署

首先，你需要一个已安装Istio的Kubernetes集群。我们假设有一个名为 ai-predictor-svc 的服务，对应两种不同的模型版本（v1和v2）。

我们需要为每个模型版本创建单独的Deployment，并通过标签区分它们，这是Istio进行流量划分的基础。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# ai-predictor-v1.yaml: 稳定模型版本

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ai-predictor-v1

spec:

  selector: {matchLabels: {app: ai-predictor, version: v1}}

  replicas: 3

  template:

    metadata:

      labels: {app: ai-predictor, version: v1}

    spec:

      containers:

      - name: predictor

        image: my-registry/ai-model:v1

---

# ai-predictor-v2.yaml: 新模型版本（Canary或A/B测试目标）

apiVersion: apps/v1

kind: Deployment

metadata:

  name: ai-predictor-v2

spec:

  selector: {matchLabels: {app: ai-predictor, version: v2}}

  replicas: 1

  template:

    metadata:

      labels: {app: ai-predictor, version: v2}

    spec:

      containers:

      - name: predictor

        image: my-registry/ai-model:v2

部署完成后，需要定义一个Kubernetes Service来聚合这两个Deployment，以及一个Istio DestinationRule来定义可路由的子集（Subsets）。

1
2
3
4
5
6
7
8
9
10
11
12
# DestinationRule 定义了服务下的子集

apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

  name: ai-predictor-rule

spec:

  host: ai-predictor-svc

  subsets:

  - name: v1

    labels: {version: v1}

  - name: v2

    labels: {version: v2}

2. 实现Canary发布（基于权重的流量分配）

Canary发布的目标是将一小部分生产流量（例如5%或10%）导向新版本（v2），在观察性能指标和错误率稳定后，逐步增加权重，最终完全切换到新版本。

下面的 VirtualService 配置将95%的流量分配给稳定版本 (v1)，5%的流量分配给新版本 (v2)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# VirtualService 用于流量路由和权重分配

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

  name: ai-predictor-vs

spec:

  hosts:

  - ai-predictor-svc

  http:

  - route:

    - destination:

        host: ai-predictor-svc

        subset: v1

      weight: 95  # 95% 流量到 V1

    - destination:

        host: ai-predictor-svc

        subset: v2

      weight: 5   # 5% 流量到 V2 (Canary)

操作步骤：
1. 应用上述YAML (kubectl apply -f virtualservice.yaml).
2. 监控v2版本的延迟、错误率和业务指标（如预测准确率）。
3. 如果v2稳定，逐渐修改weight值，例如改为 v1: 70, v2: 30。
4. 最终，当 v2 权重达到 100 时，即可下线 v1 的 Deployment。

3. 实现A/B测试（基于请求头的路由）

A/B测试通常用于精确控制流量的来源，例如，让内部测试团队或来自特定地理位置的用户体验新模型，而其他所有用户仍使用稳定模型。

Istio允许我们根据请求头（Header）、查询参数（Query Parameter）甚至Cookie进行路由匹配。

下面的配置实现了：如果请求头中包含 x-model-test: beta-user，则将请求路由到 v2；否则路由到 v1。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# VirtualService 用于 A/B 测试路由

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

  name: ai-predictor-ab-test-vs

spec:

  hosts:

  - ai-predictor-svc

  http:

  # Rule 1: A/B 测试匹配规则

  - match:

    - headers:

        x-model-test:

          exact: beta-user

    route:

    - destination:

        host: ai-predictor-svc

        subset: v2  # 匹配用户访问 V2

  # Rule 2: 默认规则 ( fallback )

  - route:

    - destination:

        host: ai-predictor-svc

        subset: v1  # 其他用户访问 V1

测试验证：

测试团队可以通过发送带有特定HTTP头的请求来访问新模型：

1
2
3
4
5
# 访问稳定 V1 模型 (默认路由)

curl -H "Content-Type: application/json" http://<GATEWAY_IP>/predict



# 访问 A/B 测试 V2 模型 (命中匹配规则)

curl -H "x-model-test: beta-user" -H "Content-Type: application/json" http://<GATEWAY_IP>/predict

总结

利用Istio的流量管理能力，AI基础设施团队可以极大地降低模型升级的风险。Canary发布适用于渐进式、低风险的通用升级，而A/B测试则提供了精确控制的能力，确保特定用户群体或内部测试能够独家验证新模型的表现。通过结合监控工具（如Prometheus和Grafana）实时观察流量分割和模型性能指标，AI服务的平滑升级将不再是难题。