题干与适用场景
平台团队维护共享 Kubernetes 集群，应用团队部署 gRPC 服务。平台要求统一入口、TLS 终止、按 service/method/header 路由，并支持灰度发布；应用团队只能修改自己的 Route，不能接管基础设施或访问其他命名空间。请设计资源模型、请求路径、授权边界、可观测性和失败回退。
假设 Gateway API 控制器已安装，后端服务使用 HTTP/2 gRPC，客户端需要明确的超时和重试策略。回答重点是跨团队控制面的职责分离，不绑定某一家 Gateway 实现。
面试官考察点
- 是否能把 GatewayClass、Gateway、GRPCRoute 和 Service 的责任拆开。
- 是否理解 GRPCRoute 的匹配粒度与 HTTPRoute 的差别，而非只写一段 YAML。
- 是否处理跨命名空间 ReferenceGrant、RBAC、默认拒绝和审计。
- 是否说明灰度权重、长连接、流式 RPC 与重试带来的风险。
- 是否设计状态观测、回滚条件和控制器/数据面故障路径。
回答前需要澄清的问题
- Gateway 由平台集中管理还是每个团队独立拥有？这决定 Route 的 attach 权限和变更审批。
- 路由按 service、method、header 还是 hostname 区分？匹配优先级不同会改变规则冲突处理。
- RPC 是 unary 还是长时间 streaming？streaming 通常不适合按请求重试或中途切流。
- 灰度按请求比例、租户、header 还是客户端版本？需要定义权重、粘性和回滚信号。
- 后端 Service 是否跨命名空间，是否允许跨集群故障转移？这会引入 ReferenceGrant 和额外健康检查。
30 秒回答框架
我先把平台拥有的 Gateway 与应用拥有的 GRPCRoute 分开，Service 作为后端发现边界。Route 只声明 gRPC 方法和元数据匹配，跨命名空间引用必须经过显式授权。控制器把有效状态和引用错误写入可观测条件，数据面按权重转发并对 streaming 禁止盲目重试。灰度先从单一租户或 header 开始，以错误率、尾延迟和业务指标作为回滚门槛，Route 无效或后端不健康时回到稳定版本。
分步骤深入解答
1. 资源职责与数据流
平台创建 GatewayClass 选择控制器，再创建监听器、地址和 TLS 策略。应用团队在自己的命名空间创建 GRPCRoute，通过 parentRefs 挂到允许的 Gateway，并把规则指向自己的 Service。请求进入 Gateway 后，控制器生成数据面配置，按 hostname、gRPC service、method 和 headers 选择 backendRefs。
2. 匹配与冲突处理
先定义精确匹配和默认匹配的优先级，例如完整 service/method 优先于仅 service，再优先于 header 兜底。禁止两个团队对同一 parent 和相同匹配条件产生隐式覆盖；冲突应在 Accepted、ResolvedRefs 等状态条件中暴露，并由 CI 检查 Route 状态。对于未知 method，选择明确的 UNIMPLEMENTED 或稳定后端回退，不能静默转发到任意服务。
3. 多租户授权
应用只能写自己的 Route 和 Service。Gateway 的 allowedRoutes 限制可 attach 的命名空间；跨命名空间 backendRef 需要 ReferenceGrant，且授权对象由目标命名空间所有者批准。RBAC、Admission Policy 和 Git 审核共同阻止团队修改平台 TLS、监听器和别人的授权。审计记录应包含谁改变了 parent、backendRef 和权重。
4. 灰度、长连接与重试
unary RPC 可以按权重把新请求分到 stable/canary；streaming RPC 一旦建立连接，权重不会在中途重新计算。不要对非幂等 unary 调用自动重试，也不要在客户端超时不明时叠加 Gateway 重试。灰度键可以是显式 header 或租户名单，避免随机比例让同一租户在调试时漂移。权重改变应小步提交，并记录生效时间。
5. 健康、状态与故障回退
数据面需要 gRPC health checking、连接池和明确的 per-route timeout。控制器不可用时，已下发配置应继续服务但不能接受新的无验证变更；Gateway 不可接受、引用无法解析或后端无可用端点时，状态应让发布系统阻断。回滚可把权重归零、恢复上一版本 Route，或切换到备用 Gateway；回滚动作必须幂等。
6. 可观测性与容量边界
按 route、service、method、status code、租户和版本记录请求数、错误率、P50/P95/P99 延迟、active streams、重试次数和连接耗时。高基数原始 metadata 不应直接作为指标标签，可在日志中采样并脱敏。容量评估要覆盖连接数、stream 并发、TLS CPU、控制器推送延迟和单个后端的最大连接数；压测 unary 与 streaming 两种形态。
高质量示范回答
我会先确认平台团队拥有 GatewayClass、Gateway 和监听器，应用团队只拥有本命名空间的 GRPCRoute 与 Service。GRPCRoute 按 service/method 和受控 header 匹配 backendRefs；跨命名空间引用需要目标方创建 ReferenceGrant，Gateway 的 allowedRoutes 和 RBAC 再限制 attach 范围。
发布时我把 unary 请求按权重切到 stable 与 canary，streaming 连接只在建立时选路，不做中途切流。对非幂等调用不自动重试，超时和重试预算由客户端与 Gateway 协同。控制器持续暴露 Route 的 Accepted、ResolvedRefs 和后端健康状态；CI 发现无效引用或冲突就阻断发布。灰度从单租户或显式 header 开始，以方法级错误率、尾延迟、active streams 和业务成功率触发回滚，恢复上一版权重并保留审计记录。
常见错误
把 GRPCRoute 当作普通 Ingress
忽略 service/method 和 HTTP/2 语义会导致规则过宽；修正方法是先定义匹配优先级与未知 method 行为。
允许应用直接修改 Gateway
共享监听器和 TLS 会被越权改动；修正方法是用 allowedRoutes、RBAC、ReferenceGrant 和 Admission Policy 分层授权。
对 streaming RPC 盲目重试或切流
会重复副作用或截断长连接；修正方法是区分 unary/streaming，按幂等性和连接生命周期制定策略。
只看控制器部署成功
控制器成功不等于 Route 被接受或后端有端点；修正方法是检查 Accepted、ResolvedRefs、健康状态和数据面指标。
追问及应对
追问一：两个 Route 匹配同一个 method 怎么办？
禁止依赖实现方的隐式顺序。用 namespace/parent attach 策略限制所有权，在 CI 检查冲突，并把不可解析状态作为发布失败条件。
追问二：canary 版本只对某个租户开放，如何保证稳定？
用显式租户或 header 匹配，避免随机权重造成同一租户漂移；同时记录版本和租户维度的错误率，回滚时先撤销该匹配。
追问三：Gateway 控制器宕机会中断流量吗？
取决于数据面是否保留最近有效配置。设计上让已下发配置继续服务，但冻结新变更，并监控配置年龄；超过安全期限则切到备用控制器或 Gateway。
追问四：跨命名空间 backendRef 为什么需要额外授权？
它会让一个团队把流量指向另一个团队的 Service。ReferenceGrant 把同意权交给目标命名空间所有者，配合 RBAC 和审计可防止隐式越权。