1. 场景、目标与非目标
平台团队维护共享 Gateway，业务团队在各自命名空间部署服务。支付服务要求 Gateway 看不到明文，内部管理服务要求 Gateway 在入口校验客户端证书，审计团队要求记录路由变更和握手失败。目标是让团队能独立发布路由，同时限制证书、后端和监听器的权限。
先声明非目标：Gateway API 资源只描述意图，具体 TLS 实现、负载均衡能力和证书存储方式仍由 GatewayClass 控制器决定。设计必须包含兼容性检查和控制器能力矩阵，不能把某个实现的行为当成 API 保证。
2. 先拆解 Gateway API 1.5 的能力
Gateway API 1.5 将 TLSRoute、前端客户端证书验证、后端 TLS 相关能力推进到更稳定的阶段，并将 ReferenceGrant 提升到 v1。TLSRoute 通过 TLS 握手中的 SNI 匹配主机名，再把连接转发到后端；监听器可选择 Passthrough 或 Terminate。
Passthrough 让 Gateway 只代理加密字节流，后端负责证书和握手；Terminate 在 Gateway 结束 TLS，再把解密后的 TCP 流发给后端。两者的密钥持有者、可见数据、策略执行点完全不同，不能只用“性能”一个指标决定。
3. 设计资源与所有权
基础设施团队创建 Gateway 和监听器，应用团队创建绑定到监听器的 TLSRoute。用 parentRefs.sectionName 把路由绑定到明确监听器，避免一个路由意外接管整个 Gateway。主机名、端口、协议和证书引用应在代码审查中作为策略输入。
示例资源表达透传意图：
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-edge
namespace: infra
spec:
gatewayClassName: example-gateway-class
listeners:
- name: tls-passthrough
protocol: TLS
port: 8443
tls:
mode: Passthrough
---
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
name: payments
namespace: payments
spec:
parentRefs:
- name: shared-edge
namespace: infra
sectionName: tls-passthrough
hostnames: ["pay.example.com"]
rules:
- backendRefs:
- name: payments
port: 8443跨命名空间引用必须经过控制器支持的授权机制，并由 ReferenceGrant 或等价策略明确允许；禁止依赖默认可见性。
4. Passthrough 与 Terminate 的取舍
选择 Passthrough 时，Gateway 不持有私钥，也看不到应用协议，可以满足后端直接做双向 TLS 或严格端到端加密的要求。代价是 Gateway 无法按 HTTP 内容路由、统一做应用层限流或在入口校验客户端证书；握手和证书轮换压力由后端承担。
选择 Terminate 时，Gateway 集中管理证书并可在入口执行客户端证书验证，路由和观测更统一。代价是 Gateway 能看到明文，后端链路若仍需加密，还要配置后端 TLS；私钥访问面和控制器故障域也扩大。
面试回答应给出分层方案：支付等高敏感连接默认透传；需要统一身份与策略的管理服务终止在 Gateway，并用独立后端 TLS 保护第二跳。
5. 前端 mTLS 与信任锚
前端 mTLS 的验证发生在客户端到 Gateway 的连接上。Gateway 根据配置的 CA 证书包验证客户端证书；默认的严格模式只接受验证通过的客户端。若启用允许不安全回退，缺失或无效证书的连接仍可能到达后端，必须把它视为显式例外，并配合网络策略和审计告警。
信任锚应按租户或环境分组，证书包通过受控的 Secret/ConfigMap 引用分发。不要让应用团队直接引用平台私钥；轮换时先发布新 CA、观察双信任窗口，再撤销旧 CA，并记录生效时间与影响范围。
6. 多租户授权与冲突处理
共享 Gateway 的监听器属于平台边界，应用只能申请特定主机名和后端。控制器应拒绝重叠主机名、未授权 parentRefs、跨命名空间后端和不符合端口/协议策略的资源，并把拒绝原因写入资源状态。
对 ReferenceGrant、Secret 引用和 GatewayClass 能力做准入校验。策略变更必须经过 Git 审核；运行时只允许控制器根据已批准资源生成配置。发生路由冲突时，宁可保持旧配置并报告 Accepted=False，也不要让最后写入者静默覆盖其他租户。
7. 故障、升级与观测
发布前验证控制器是否支持 TLSRoute 的稳定版本、所选 TLS 模式、客户端证书验证和后端 TLS。Gateway API 的版本升级可能需要把旧实验资源迁移到稳定 v1，不能只替换 YAML URL。
观测至少覆盖：SNI 匹配结果、监听器和路由状态、证书到期时间、客户端证书验证失败原因、后端连接错误、配置分发延迟和每个租户的握手/流量指标。故障切换时保持证书信任包、路由状态和后端健康检查一致；若 Gateway 不可用，应有 DNS/LB 层的明确回退，而不是把未加密流量直接旁路。
8. 评分要点与追问
必须说清
- 能区分 TLSRoute 的 SNI 路由、Passthrough 与 Terminate 的密钥和明文边界。
- 能设计前端 mTLS 的 CA 信任、轮换、失败策略及跨命名空间授权。
- 能说明控制器能力差异、资源状态、升级迁移和可观测性，而不是只贴 YAML。
常见追问
- 同一 SNI 同时被两个命名空间声明时，如何避免静默覆盖？
- Gateway 终止 TLS 后，如何保证到后端的第二跳仍满足合规加密？
- 客户端 CA 轮换期间如何支持双证书，同时限制旧证书的最长有效时间？
评分参考
优秀答案会把资源所有权、加密边界、授权和运行证据连成闭环：先选定谁持有密钥，再用状态条件拒绝冲突配置，最后用握手、证书和后端指标证明策略确实生效。