# 1. Service Mesh 的 Sidecar 代理模型如何实现"零侵入"，相比 SDK 方式的本质差异？ A Sidecar 模型需要修改应用代码以启用治理能力 B SDK 方式升级治理能力无需重新发布应用 C Sidecar 通过流量劫持与注入实现零侵入，应用零改动即可获得治理能力；SDK 方式则与应用深度耦合 ✓ 正确答案 D Sidecar 模型只能用于单一语言的应用
# 2. Sidecar 模式实现零侵入的完整链路中注入、流量劫持（iptables）与配置热更新如何工作？ A 流量劫持由 istio-proxy 主容器以 NET_ADMIN 权限完成 B 注入由 MutatingAdmissionWebhook 完成，劫持由 istio-init 的 iptables 完成，配置由 xDS 热更新完成 ✓ 正确答案 C 配置更新需要重启应用容器才能生效 D iptables 只在应用启动时生效一次
# 3. 数据面（Envoy）与控制面（Istiod）的分工，xDS 协议如何下发配置？ A 控制面负责实际流量转发，数据面负责配置下发 B Envoy 收到坏配置后 NACK 并立即应用坏配置 C xDS 只分发证书，不负责路由与端点 D 数据面（Envoy）执行转发与治理，控制面（Istiod）翻译并下发配置；xDS 通过 LDS/RDS/CDS/EDS/SDS 分发 ✓ 正确答案
# 4. Sidecar 生命周期与主容器生命周期对齐（preStop/健康检查）的坑点？ A Sidecar 与主容器同时收到 SIGTERM，无需考虑排空顺序 B preStop 钩子设置越长越好，能保证所有请求完成 C 需让应用优雅排空、sidecar 用 drain-time 排空连接，并确保 terminationGracePeriodSeconds 足够；sidecar 应先于主容器就绪 ✓ 正确答案 D 健康检查只针对主容器，与 sidecar 无关
# 5. Sidecar 的资源开销与延迟代价如何度量，什么规模才值得引入网格？ A Sidecar 每实例内存开销通常达数 GB，延迟可忽略 B 任何规模都应立即引入网格以统一治理 C 网格治理收益随服务数量增长而边际增加，规模小、对延迟敏感的场景可能不值得引入 ✓ 正确答案 D 网格引入后无任何性能或资源代价
# 6. 无 Sidecar 模式（Ambient/Proxyless）的演进与适用场景？ A Ambient 为每个 Pod 注入 sidecar，只是换了代理镜像 B Ambient 通过 ztunnel 提供 L4 安全并可按需启用 L7 waypoint；Proxyless 让应用直接经 xDS 接入控制面 ✓ 正确答案 C Proxyless 模式可为任意语言透明启用 D 无 Sidecar 模式功能完全等同于 Sidecar 模式
# 7. 服务网格控制面与数据面的生命周期中配置下发、版本升级与故障隔离如何协同 A 数据面与控制面必须同时升级，否则无法工作 B 数据面升级必须先于控制面 C 控制面故障会导致所有数据面立即停止转发 D 控制面故障时数据面仍可基于最后下发的好配置继续转发，版本升级应控制面先于数据面并保持兼容 ✓ 正确答案
# 8. 网格规模增长后的配置下发性能中 xDS 推送风暴与 sidecar 内存如何治理？ A 网格规模增大后应让每个 sidecar 订阅全部集群以保证一致性 B sidecar 内存与订阅的集群数量无关 C 推送风暴只能通过重启控制面解决 D 通过增量 xDS、按依赖裁剪 Sidecar 订阅范围与控制端点变化频率，可缓解推送风暴并降低 sidecar 内存 ✓ 正确答案
# 9. 多集群网格（多主/单主/混合）的拓扑选择与故障域设计？ A 单主拓扑无任何故障风险 B 多主拓扑每个集群独立控制面，故障隔离好但运维复杂；单主拓扑控制面集中、简单但主集群故障影响所有集群 ✓ 正确答案 C 多主拓扑无法跨集群做 mTLS D 多集群拓扑与故障域设计无关
# 10. 服务网格与传统负载均衡的边界中东西向流量治理能力与资源成本的权衡 A 传统 LB 已能提供服务间细粒度治理，无需网格 B 网格只处理南北向流量 C 网关/LB 承担南北向入口治理，网格承担服务间东西向治理；网格以资源开销换取东西向治理能力 ✓ 正确答案 D 网格引入后无任何资源开销
# 11. 网格 mTLS 的实现中 SPIFFE 身份、证书签发与轮换机制如何工作 A 网格 mTLS 使用固定长期证书，不轮换 B SPIFFE 身份与证书无关 C mTLS 基于 SPIFFE 身份，Istiod 签发短期证书并通过 SDS 下发，证书临近过期自动轮换 ✓ 正确答案 D mTLS 只认证服务端，不认证客户端
# 12. 网格可观测性中 sidecar 指标、分布式追踪与访问日志如何统一采集与关联 A Envoy 生成指标、传播 trace 头并记录访问日志，三者通过公共字段（服务名、trace id 等）关联实现排障闭环 ✓ 正确答案 B 指标、追踪、日志三者相互独立，无法关联 C 网格只提供指标，不提供追踪与日志 D 追踪需要应用代码配合，网格无法自动做
# 13. 网格安全体系中自动 mTLS、授权策略与证书生命周期如何协同 A 授权策略无需 mTLS 身份即可判断 B 强制 mTLS 后无需再配置授权策略 C 证书轮换与安全无关 D mTLS 建立身份、AuthorizationPolicy 基于身份授权、证书定期轮换，三者协同实现零信任 ✓ 正确答案
# 14. 网格性能开销中额外网络跳数、sidecar CPU/内存与延迟预算如何量化 A 多跳调用不会叠加代理开销 B Sidecar 引入后无任何延迟与资源开销 C Sidecar 每实例内存消耗通常为数十 MB，单跳代理延迟约毫秒级，需纳入延迟预算 ✓ 正确答案 D 应忽略 P99，只关注平均延迟
# 15. 网格排障入口中 sidecar 启动日志、xDS 推送状态与代理统计如何组合定位 A 排障只能看启动日志，无法看运行配置 B 只需看业务容器日志即可定位网格问题 C xDS 状态与代理统计无关 D 启动日志确认代理可用，proxy-status 确认 xDS 配置同步，proxy-config/stats 定位运行时异常，三层组合定位 ✓ 正确答案
# 16. 网格排障中流量 503/超时如何通过 sidecar 日志与策略配置定位 A 503 的响应 flag（如 UH/UO/UC）配合 cluster 端点健康状态与策略配置可定位根因 ✓ 正确答案 B 503 一定是业务代码错误 C 访问日志无法区分超时与无健康端点 D 503 与连接池和熔断配置无关
# 17. 网格流量管理中 VirtualService 路由与 DestinationRule 负载均衡/连接池的配置层级 A subset 与 DestinationRule 无关 B VirtualService 负责连接池，DestinationRule 负责路由 C 两者职责完全相同，可互换 D VirtualService 负责路由，DestinationRule 负责负载均衡/连接池/熔断，VirtualService 的 subset 由 DestinationRule 定义 ✓ 正确答案
# 18. 网格遥测集成中 Prometheus 指标、OTel 追踪与访问日志的导出配置 A 通过 Telemetry 资源可统一配置指标、追踪与访问日志的导出，Prometheus 抓取 sidecar 指标、OTel 导出追踪 ✓ 正确答案 B 网格遥测只能输出到 Prometheus，无法配置追踪 C Telemetry 只能配置指标，不能配置日志 D 访问日志无法导出到外部系统
