4. K8s Service 的标签选择器与蓝绿流量路由：selector 机制、标签策略、多版本共存
在蓝绿发布中，K8s Service 是流量路由的核心枢纽。它通过 标签选择器（Label Selector） 将虚拟 IP 与后端 Pod 动态绑定。本章深入剖析 selector 的匹配机制、标签设计策略以及如何利用 Service 实现多版本流量的精确控制。
4.1 标签选择器（Selector）的匹配机制
K8s Service 通过 spec.selector 字段定义一组标签键值对，只有携带全部匹配标签的 Pod 才会被纳入 Endpoints 列表。匹配规则分为两种：
| 匹配类型 | 语法示例 | 匹配逻辑 | 典型场景 |
|---|---|---|---|
| 精确匹配（Equality） | app: myapp, version: v1 |
Pod 必须同时包含 app=myapp 和 version=v1 标签 |
蓝绿发布中，Service 精确指向某一版本 |
| 集合匹配（Set） | environment in (prod, staging) |
Pod 的 environment 标签值必须属于集合中的某一个 |
灰度发布中，将流量路由到多个版本 |
关键原则：Service 的 selector 是“与”逻辑（AND），所有条件必须同时满足。如果 Pod 缺少任何一个标签，都不会被选中。这是实现蓝绿隔离的基础。
4.2 蓝绿发布中的标签策略
为了支持蓝绿发布，必须为每个版本定义唯一且可区分的标签组合。推荐采用“应用标识 + 版本标识”的双标签策略：
- 稳定标签（stable）：
app: myapp, version: stable—— 始终指向当前生产版本。 - 候选标签（candidate）：
app: myapp, version: candidate—— 指向新版本，用于验证。 - 版本标签（version-specific）：
app: myapp, version: v1.2.3—— 精确标识某个版本，用于回滚或审计。
最佳实践：在 Deployment 的
spec.template.metadata.labels 中同时写入 app 和 version 标签。Service 的 selector 只使用 app 和 version，避免引入 tier、env 等非版本相关标签，防止误匹配。
4.3 多版本共存的流量路由模型
蓝绿发布期间，蓝组（Blue）和绿组（Green）的 Pod 同时运行。通过创建两个独立的 Service，可以实现流量隔离与切换：
4.4 流量切换与回滚操作
当验证通过后，只需修改 myapp-prod Service 的 selector，将 version=stable 改为 version=candidate，流量即瞬间切换到绿组。回滚时，只需将 selector 改回 version=stable。
注意：直接修改 Service 的 selector 会导致连接中断（Connection Draining 问题）。生产环境中建议配合
externalTrafficPolicy: Local 或使用 Ingress Controller 实现优雅切换。
4.5 标签策略对比表
| 策略名称 | 标签设计 | 优点 | 缺点 |
|---|---|---|---|
| 单标签版本化 | version: v1 |
简单直接 | 无法区分不同应用 |
| 双标签隔离 | app: myapp, version: v1 |
应用与版本解耦，支持多应用共存 | 标签数量略多 |
| 三标签精细化 | app, version, track: canary |
支持金丝雀、蓝绿、A/B 测试 | 管理复杂度增加 |
4.6 多版本 Service 配置示例
以下 YAML 展示了蓝绿发布中两个 Service 的典型配置：
---
# 生产 Service（指向蓝组）
apiVersion: v1
kind: Service
metadata:
name: myapp-prod
spec:
selector:
app: myapp
version: stable # 指向蓝组
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
# 预览 Service（指向绿组）
apiVersion: v1
kind: Service
metadata:
name: myapp-preview
spec:
selector:
app: myapp
version: candidate # 指向绿组
ports:
- protocol: TCP
port: 80
targetPort: 8080
自动化回滚提示：在自动化脚本中，回滚操作就是执行
kubectl patch service myapp-prod -p '{"spec":{"selector":{"version":"stable"}}}'。确保回滚前蓝组 Pod 仍在运行且健康。
4.7 标签选择器的常见陷阱
- 标签漂移：手动修改 Pod 标签会导致 Service 瞬间将流量路由到错误版本。应通过 Deployment 的
spec.template统一管理标签。 - 空选择器：如果 selector 没有匹配到任何 Pod，Service 的 Endpoints 列表为空，流量会被丢弃。监控 Endpoints 数量是发布前的必要检查项。
- 多 Service 冲突：两个 Service 的 selector 如果都匹配同一组 Pod，会导致流量负载均衡混乱。确保每个版本有唯一的
version标签值。