【Linkerd】ServiceProfile：L7 路由、重试与 sp-validator

第 8 篇 钉入站 AuthorizationPolicy 与 policy 容器；出站 发现 由 destination.Get 承担（第 7 篇）。L7 行为——按路径路由、可重试、超时、失败分类——走第三条链：ServiceProfile → destination.GetProfile → linkerd2-proxy 出站 HTTP 逻辑。读者常把「重试不生效」当成发现问题，或把 SP 校验失败当成策略拒绝；本篇分列机制与表象。

本篇在系列中的位置

篇目	核心内容
第 8 篇 · 策略模型	Server、AuthorizationPolicy
第 9 篇 · ServiceProfile	L7 路由、sp-validator、GetProfile
第 10 篇 · linkerd2-proxy	Rust 数据面、协议探测
系列目录	关键问题、阅读路径

版本锚定：Linkerd 2.20（tag version-2.20）。ServiceProfile API 组 linkerd.io，版本 v1alpha2（validator webhook 亦接受 v1alpha1）。GetProfile 语义见 destination.proto DestinationProfile @ linkerd2-proxy-api v0.20.0。无真实集群则不粘贴伪造 profile 推送或 apply 输出。

一、ServiceProfile CRD

ServiceProfile 是 Linkerd 原生的 L7 流量描述：绑定到某个 Service（按 FQDN），定义 routes、retryBudget、dstOverrides（流量拆分）等。数据面不直接读 CRD；destination 控制器 watch ServiceProfile，翻译成 DestinationProfile 消息经 GetProfile 流推送。

destination.proto 中 DestinationProfile 关键字段：

• routes：每条含 RequestMatch（路径 regex、HTTP method 等）、timeout、is_retryable、response_classes（哪些响应算失败）。
• retry_budget：retry_ratio、min_retries_per_second、ttl 控制重试风暴上限。
• dst_overrides：将请求按权重拆到多个 authority，各自再触发独立 destination.Get（与 per-target 模型衔接）。
• opaque_protocol：为 true 时 HTTP 路由被忽略，连接按 opaque TCP 处理。

与 Istio VirtualService 对照：Istio 翻译为 xDS RDS；Linkerd 把等价信息塞进 专用 GetProfile 流（istio-xds/14）。排障 L7 应查 profile 流内容，不是 VirtualService 是否同步到 istiod。

ServiceProfile 命名 convention：通常与 Service 同名同 namespace，或通过 Service 注解 linkerd.io/profiles 指向外部 profile——以 2.20 官方 ServiceProfile 文档为准，本篇不展开注解全集。

二、sp-validator webhook

destination Pod 内的 sp-validator 容器注册 linkerd-sp-validator ValidatingWebhookConfiguration：

• 拦截 linkerd.io serviceprofiles 的 CREATE/UPDATE（v1alpha1 / v1alpha2）。
• Service 名 linkerd-sp-validator，证书 Secret linkerd-sp-validator-k8s-tls（helm 模板自签或外部注入）。

分工边界：

校验失败时 kubectl apply 直接报错——此时数据面从未见过该 profile，谈不上「路由不命中」。与运行时 404/超时（profile 已加载但条件不匹配）证据包不同。

failurePolicy 跟随 chart 全局 webhookFailurePolicy：集群级运维门，决定 webhook 不可达时是否阻断写入。

三、与 destination 合流

server.go 中 GetProfile 与 Get 并列：解析 GetDestination.path 后，经 ProfileWatcher 订阅对应 ServiceProfile；IP 查询走 getProfileByIP 分支（用于按 Pod IP 反查 profile）。

合流路径：

flowchart TD
  spcrd["ServiceProfile CRD"] --> pw["ProfileWatcher"]
  pw --> gp["destination.GetProfile stream"]
  gp --> proxy["linkerd2-proxy outbound HTTP"]
  get["destination.Get stream"] --> proxy

出站一次 HTTP 请求同时依赖：

1. Get：后端地址与 mTLS 身份（发现轴）。
2. GetProfile：走哪条 route、是否可重试、超时多久（L7 轴）。

subscribeToServiceProfile 在 profile 缺失时发送 默认空 profile（defaultProfile），使行为回退到无自定义路由——表象是「SP 写了但不生效」，要先查 CRD 是否同名、watcher 是否收到、validator 是否曾拒绝。

dst_overrides 触发对多个 authority 的 Get 调用，把流量拆分与 per-target 流模型绑在一起；拆分配错会表现为部分后端永远无流量，而非单条 route 正则错误。

四、Gateway API 分工指针（详 11）

Linkerd 2.20 同时支持 Gateway API（公告门 1.5.1）与 ServiceProfile。分工原则（机制层，详 第 11 篇）：

双轨开放问题：同一 Service 上 SP 与 HTTPRoute 规则冲突时何者优先，须以 tag 文档与 第 11 篇 为准，本篇不写成已统一仲裁算法。选型读者应把 GAPI 当边界扩展，把 ServiceProfile 当 mesh 内经典 L7 配置路径。

五、校验失败表象

口诀：写入失败找 validator；行为失败先分 Get vs GetProfile；403 找 policy。 不要把三轴证据包混在一个「Linkerd 配置坏了」叙事里。

参考资料

规范 / 官方文档 / 源码（A）

• Linkerd Service Profiles 文档 @ version-2.20
• linkerd2-proxy-api proto/destination.proto（DestinationProfile、Route、RetryBudget）@ v0.20.0
• linkerd/linkerd2 version-2.20：controller/api/destination/server.go（GetProfile）；destination-rbac.yaml（sp-validator webhook）

站内对照（A/B）

• 第 7 篇 · 服务发现流
• 第 8 篇 · 策略模型
• istio-xds/14 · Linkerd 对照
• PLAN.md §九篇 09

学术谱系（A）

• Gateway API GEP 谱系（HTTPRoute 与 policy attachment；2.20 门 1.5.1）

上一篇：策略模型

下一篇：linkerd2-proxy 数据面