服务网格 31：多租户需要隔离哪些控制面与数据面边界

一个 namespace 一个租户，隔离就足够了吗

不够。租户 A 与 B 在同一隔离实验集群内分别运行累计 frontend → orders → inventory 服务，可以复用同一合成 SKU、请求 ID 前缀和库存账本，但四类边界仍需分开证明：谁能提交规则（Kubernetes RBAC）、规则可见及附着到谁（Istio/Gateway API 作用域）、业务请求能否越权（数据面认证授权），以及共享控制面/waypoint/ztunnel 被租户 A 占满时租户 B 的可用性。前面认证与授权章节讨论的执行点不能由“两个 namespace”替代，HTTPRoute 的同 namespace 生产者规则还可能作用于所有调用该 Service 的来源。

租户 API 写权限、规则目标与共享代理容量是三条不同边界；底部业务账本验证实际影响

Namespace 给资源命名空间，不自动为所有业务流量隔离网络，不自动防止错误的全局策略，也不为共享 waypoint 建立硬性的按租户容量限额。RBAC 能禁止 A 修改 B 的资源，却无法据此推出 A 对 B Service 的 HTTP 请求一定会被拒绝；相反，数据面策略即使拒绝了 A，也不能阻止 A 以被授予的 API 权限提交错误配置。要识别依赖关系，至少记录 namespace、ServiceAccount、Route/Policy 的创建主体与目标引用、实际代理状态以及同一请求 ID 的客户端/库存日志。

三张权限表互相不能替代

要回答的问题	验证点	正例与负例
A 可改 B 的 Route/Policy 吗	RBAC 授权、实际 API 请求或 `auth can-i`，含服务账号和 namespace	A 只能改 A；跨 B 修改被拒并留下非零退出
A 的规则会影响 B 的调用吗	生产者/消费者 Route 附着、Istio 配置可见性、代理当前路由	固定来源 namespace/请求头，比较 B 的库存版本；错误目标规则不得悄悄越界
A 能访问 B 的库存写接口吗	工作负载身份、目标入站授权、网络强制范围	B 自有请求允许，A 的错误身份请求拒绝且 B 账本不新增
A 的负载会拖慢 B 吗	共享 waypoint/ztunnel/Istiod 的 CPU、连接与队列	B 正常基线与 A 人工受控高负载期对照；超过门禁即失败

不要把正例“B 业务 200”当作 RBAC 测试结果；也不要把 API Forbidden 的错误响应当作应用拒绝。资源可见性由 Istio 配置范围、Gateway API 引用规则和所选版本共同决定；跨 namespace 后端引用及 ReferenceGrant 的作用需要逐对象核对，不能把允许引用解释为获得任意策略编辑权。共享 waypoint 的处理资源与指标标签基数也需计入租户成本，在未采集前不写任何隔离性能数字。

在隔离集群复跑的次序

先在 examples/service-mesh/ 只读检查具名 context 与合成 namespace，检查失败就立即停止：

1	`SM_CONTEXT=service-mesh-lab SM_NAMESPACE=service-mesh-lab bash scripts/check-02.sh`

再在明确不包含真实业务的集群准备 A/B 两组累积应用与不同 ServiceAccount，固定 sku=paper，请求 ID 包含租户及尝试号，合成写接口仅使用实验账本。先保存两个租户独立成功调用及当前配置；逐层构造负例：以 A 的测试凭据尝试修改 B 规则；保留两条 Route 分别从 A/B 访问 B；让 A 的错误身份访问 B 库存并确认 B 账本无新记录；在受限额度内增加 A 负载，监测 B 的错误率与延迟。每例保存资源、策略、代理实际执行点、客户端退出码、应用端结果；应拒却放行或者污染账本时断言非零。不得靠配成空 EndpointSlice 人为拖垮他人服务，也不试图打满共享生产网关。

现有 examples/service-mesh/evidence/31/20261001T145034Z-2682809/ 的前置检查退出 127，错误为 NOT_RUN: kubectl: command not found。未创建租户环境、网格代理或权限绑定；RBAC/配置可见/跨租户流量/资源压力均 NOT_RUN。本地两个进程或两个 namespace 的静态 YAML 不能替代真实隔离验证。

练习与参考解答

租户 A 不能编辑 B 的 AuthorizationPolicy，是否已证明 A 无法访问 B 库存？参考解答：没有。RBAC 只限制资源 API；还需从 A 的 ServiceAccount 发真实请求、核对 B 的入站策略与代理拒绝位置、B 应用日志与账本。配置误附着或默认允许会使业务通路与 API 权限分离。
B 的正常读请求一直成功，把 A 的同一服务调用并发提高后 B 出现尾延迟，怎样判别这是共享代理压力而不是 B 自己的慢依赖？参考解答：对照 A 负载前/期间/停止后的 B 请求 ID 与库存/外部 stub 日志，读取 waypoint/ztunnel 的 CPU、队列和连接计数及 B 自身耗时；改变 A 负载保持 B 输入不变，若现象跟随共享代理负载而非应用处理时间变化，才有证据定位资源竞争；未完成测量不可宣称因果。