测验：流量管理

如果把无条件路由放在 VirtualService 的 spec.http 数组最前面，会怎样？

• 它会截获所有请求，下方的条件规则不会执行
• 验证会因出现无法到达的规则而报错，拒绝应用配置
• 规则会自动重新排序，使更具体的条件优先评估
• 无条件路由会被视为默认值，始终最后评估

DestinationRule 的 subset 实际依据什么选择 Pod？

• subset 的 name 中填写的名称字符串
• Deployment 名称末尾的版本后缀
• Service 端口名称中的协议前缀
• subset 的 labels 中指定的标签

配置为 timeout: 2s、retries.attempts: 3、perTryTimeout: 1s 时，问题是什么？

• 没有 retryOn，重试就完全不会执行
• perTryTimeout 小于 timeout，配置会被拒绝
• 总截止时间短于各次尝试所需时间之和，无法完成全部重试
• attempts 最多只允许设置为 2

在 A → B → C 调用链中，每一层都允许重试 2 次。C 最多会收到多少个请求？

• 认为重试不会相乘，所以最多 3 次
• 每一层的三次尝试相乘，最多 9 次
• 只计算最外层，最多 3 次
• 将两层的重试相加，最多 6 次

为什么应在 outlierDetection 中设置 maxEjectionPercent？

• 因为没有上限时，隔离时间会指数增长，实例最终无法恢复
• 因为隔离后的实例会停止上报指标，形成观测空白
• 因为短暂故障可能使所有实例都被隔离，造成全面故障
• 因为该字段为空时，整个 outlierDetection 会因验证失败而被拒绝

访问日志中的响应标记是 UH。首先应该检查什么？

• 接收方仅允许 STRICT，而发送方使用明文，是否存在 mTLS 不匹配
• DestinationRule subset 的标签是否与实际 Pod 标签一致
• VirtualService 的所有条件是否都未匹配，且不存在 catch-all 路由
• 连接池最大连接数是否过小，导致并发请求未经排队便被丢弃

为什么 Service 端口名称应以 http 开头？

• 因为 API 服务器会根据名称防止同一 Service 中的端口号重复
• 因为 kubectl get svc 会按名称排序端口，更方便阅读
• 因为服务网格根据端口名称判断协议，从而决定是否应用 L7 路由
• 因为 Prometheus 会依据该名称自动选择要抓取的端口