测验：金丝雀与流量切分

服务网格的加权流量分配相比滚动更新，最准确的优势是什么？

• Pod 数量与流量比例相互独立，无需重新部署即可只回退权重
• 代理会根据响应码作出判断，因此无需 readiness 探针
• 无需构建新镜像，只调整权重就能运行新版本代码
• 能够以远快于滚动更新的速度替换相同数量的 Pod

权重设置为 90:10，但实际观测到的比例是 88:12。应如何判断？

• 权重只在部分代理上生效，应重新应用以完成同步
• 由于启用了一致性哈希，特定用户键集中落到了 v2
• 权重之和超过 100，超出部分被加给了后一个目标
• 每次请求都通过随机抽样分配流量，样本较小时这是正常波动

关于流量镜像，哪项描述正确？

• 镜像比例也要计入 weight 之和，以凑足 100
• 如果镜像目标先于原目标响应，其响应会返回给用户
• 镜像请求的响应会被丢弃，但写入数据库等副作用确实会发生
• 如果镜像目标返回 5xx，原请求也会以相同错误失败

在加权金丝雀发布期间，用户抱怨不同页面显示不同版本。解决办法是什么？

• 在 VirtualService 中添加重试，把发往其他版本的请求送回原版本
• 将 DestinationRule 的负载均衡器改为一致性哈希，并使用用户身份请求头作为键
• 将加权分流改为流量镜像，让新版本只收到复制的请求
• 将权重恢复为 100/0，终止金丝雀发布并推迟到下一次部署窗口

如果 VirtualService 的权重之和不等于 100，会怎样？

• 仅记录警告事件，仍按所写比例应用并正常转发流量
• 验证会拒绝配置，从机制上防止只改一侧却忘记另一侧的事故
• 权重最大的目标会吸收缺少的份额，并接收全部流量
• 缺少的份额会自动加给数组中的第一个目标，使总和达到 100

如果没有任何 Pod 匹配 DestinationRule 的 subset 标签，却将 10% 流量分配给该 subset，会怎样？

• 系统会跳过没有端点的 subset，将请求转给其余 subset
• 这 10% 请求会因没有健康的上游（UH）而返回 503
• 验证会因没有匹配标签的 Pod 而拒绝应用配置
• 这 10% 请求会排队等待，直到匹配的 Pod 启动

为什么金丝雀发布计划中必须包含回滚条款？

• 因为将权重提高到 100 时，旧版本 Pod 会自动删除
• 因为变更管理审计要求必须提交回滚流程文档
• 为了预先消除即使看到不良指标仍犹豫是否回滚的判断偏差
• 因为不写明回滚路径，就无法逐步提高权重