测验：服务网格与 Istio 架构

istiod 所有 pod 都死了。已运行的工作负载之间的流量会发生什么情况？

• 它立即挂断——因为所有请求都经过 istiod
• mTLS 被禁用并回退到明文。
• Sidecar 重新启动，并在短暂暂停后恢复正常。
• 它继续使用上次收到的设置，但停止传播新设置和续订证书。

Istio 将 LDS·RDS·CDS·EDS 捆绑到名为 ADS 的单个 gRPC 流中的最大原因是什么？

• 通过减少连接数来节省带宽
• 由于建立了mTLS，证书必须通过同一通道传输。
• 通过确保参考顺序自动更改设置，例如 CDS 然后 EDS、LDS 然后 RDS。
• 在多集群中，每个集群只能打开一个流，因此

在 Envoy 设置中，集群名称显示为outbound|9080|v2|reviews.prod.svc.cluster.local。第三列v2来自什么？

• istiod 会自动读取 pod 的版本标签。
• DestinationRule 中定义的子集名称
• VirtualService的路由名称
• 部署的修订号

为什么 istio-init 植入的 iptables 规则仅排除 UID 1337 的流量被重定向？

• 1337是应用程序容器的UID，因此为了性能而跳过代理。
• Kubernetes 禁止 UID 低于 1337 的数据包操作。
• 1337是istio-proxy自己的UID，如果不排除的话，proxy发送的数据包会返回到proxy，造成死循环。
• 代理健康检查流量的约定

对 sidecar 注入的 pod 的外部请求在到达应用程序之前首先到达哪个端口？

• 15001
• 15008
• 15021
• 15006

在istioctl proxy-status中，任何代理的CDS都显示为STALE。这是什么意思？

• istiod 尚未将配置发送到代理
• istiod 发送了配置，但没有收到来自代理的 ACK
• 代理设置比 istiod 更新
• 代理使用旧版本的 Envoy。