3. 核心资源模型总览
云原生网关的流量治理能力建立在五个核心资源模型之上：Gateway、VirtualService、DestinationRule、ServiceEntry 和 WorkloadEntry。这五个资源共同构成了从“入口监听”到“后端负载均衡”的完整控制链。理解它们之间的依赖关系和职责边界，是掌握网关测试验证的前提。
核心认知： 这五个资源并非孤立存在，而是通过
spec 字段中的引用关系串联成一条“流量管道”。测试验证的本质，就是验证这条管道在每个环节的配置正确性与行为一致性。
3.1 资源职责与关系矩阵
下表从职责、核心字段、依赖关系三个维度，对五个资源进行横向对比：
| 资源名称 | 核心职责 | 关键字段 | 依赖/被依赖 |
|---|---|---|---|
| Gateway | 定义入口监听端口、协议、证书 | servers, selector |
被 VirtualService 绑定 |
| VirtualService | 定义路由规则、流量分发策略 | hosts, http, tcp, gateways |
依赖 Gateway；引用 DestinationRule |
| DestinationRule | 定义负载均衡、连接池、熔断策略 | host, trafficPolicy, subsets |
被 VirtualService 引用 |
| ServiceEntry | 将外部服务注册到网格内 | hosts, ports, resolution |
被 VirtualService/DestinationRule 引用 |
| WorkloadEntry | 手动注册单个工作负载实例 | address, ports, labels |
被 ServiceEntry 引用 |
测试关注点： 依赖关系是测试用例设计的核心线索。例如，修改 Gateway 的端口监听后，必须验证绑定的 VirtualService 是否仍能正确匹配；修改 DestinationRule 的 subsets 后，必须验证 VirtualService 中的路由权重是否仍指向有效的子集。
3.2 资源协作流程：从入口到后端
下图展示了五个资源在一条完整请求链路中的协作顺序：
常见误区： 很多初学者认为 VirtualService 直接指向 Service，实际上 VirtualService 通过
destination.host 引用的是 DestinationRule 或 ServiceEntry 中定义的 host，而非 Kubernetes Service 名称。这一间接引用关系是测试配置正确性的关键检查点。
3.3 资源模型分层架构
从架构分层角度看，五个资源可以归入三个逻辑层：
- 接入层（Gateway）：负责协议适配、端口暴露、证书管理。它是网格的“大门”，所有外部流量必须经过此处。
- 路由层（VirtualService）：负责流量匹配、路由分发、重试、超时、故障注入。它是网格的“交通指挥中心”。
- 策略层（DestinationRule + ServiceEntry + WorkloadEntry）：负责后端策略定义与外部服务注册。DestinationRule 定义负载均衡与熔断策略；ServiceEntry 将外部服务纳入网格管理；WorkloadEntry 提供细粒度的实例级注册能力。
这种分层设计使得每一层的职责清晰、可独立测试。例如，测试 Gateway 时只需关注端口监听与 TLS 握手；测试 VirtualService 时只需关注路由匹配逻辑；测试 DestinationRule 时只需关注负载均衡算法与熔断阈值。
3.4 资源模型与测试验证的映射
下表将每个资源模型映射到对应的测试验证维度：
| 资源模型 | 测试验证维度 | 典型测试用例 |
|---|---|---|
| Gateway | 端口可达性、协议兼容性、TLS 证书有效性 | 使用 curl 验证 HTTPS 端口是否返回 200；使用 openssl 验证证书链 |
| VirtualService | 路由匹配准确性、权重分发比例、超时/重试行为 | 发送带特定 header 的请求，验证是否路由到预期子集；统计 100 次请求的分布 |
| DestinationRule | 负载均衡策略、熔断触发条件、连接池限制 | 注入故障观察熔断是否生效；验证轮询/随机/一致性哈希的分布 |
| ServiceEntry | 外部服务可达性、DNS 解析、TLS 发起 | 从网格内 Pod 访问外部服务，验证是否经过 Sidecar 代理 |
| WorkloadEntry | 实例注册有效性、标签匹配、健康检查 | 手动注册一个 WorkloadEntry，验证流量是否到达指定 IP 和端口 |
测试策略建议： 采用“自底向上”的测试顺序。先验证 WorkloadEntry 和 ServiceEntry 的连通性，再验证 DestinationRule 的策略生效，然后验证 VirtualService 的路由逻辑，最后验证 Gateway 的入口可达性。这样可以快速定位问题所在层。
3.5 资源模型之间的引用关系图
下图以更直观的方式展示五个资源之间的引用关系：
测试验证技巧： 在测试环境中，可以使用
istioctl proxy-config 命令查看 Envoy 的实际配置，验证资源模型之间的引用是否已正确下发。例如，istioctl proxy-config route <pod-name> 可以查看 VirtualService 是否已转换为 Envoy 路由规则。
3.6 本章小结
五个核心资源模型构成了云原生网关的“控制面骨架”：
- Gateway 定义入口，VirtualService 定义路由，DestinationRule 定义策略，ServiceEntry 和 WorkloadEntry 扩展后端范围。
- 资源之间的引用关系决定了流量管道的连通性，任何一层的配置错误都会导致流量中断或行为异常。
- 测试验证应覆盖每个资源的独立功能以及资源之间的交互边界，确保从入口到后端的整条链路配置正确。