测验：边车与数据平面

给 namespace 添加 istio-injection=enabled 标签后，已有 Pod 仍没有 sidecar。正确原因是什么？

• 因为 istiod 会定期重新协调 namespace 标签，必须等待下一个周期
• 因为 namespace 标签只作用于以后创建的 Deployment，不作用于现有工作负载
• 因为注入是在创建 Pod 时由 webhook 执行的操作，已有 Pod 必须重新创建
• 因为标签值不能是 enabled，而必须是 true，webhook 才能识别该 namespace

为什么 istio-init 初始化容器会将 UID 1337 的流量排除在重定向之外？

• 为了让健康检查和指标抓取流量绕过代理，直接得到处理
• 为了在不使用 root 权限运行代理时，将专用 UID 从流量规则中分离出来
• 为了防止 kubelet 发出的探针被 iptables 重定向后失败
• 为了防止代理自身发出的流量再次返回代理，形成无限循环

istiod 暂时宕机时，已获得配置的 sidecar 会如何工作？

• 继续使用最后收到的配置处理流量，但无法应用新配置
• 配置流中断的 sidecar 会重启，并连同应用容器一起停止
• 无法更新配置的代理会立即对传入请求返回 503
• 无法获取新证书的 sidecar 会放弃 mTLS，自动转为明文通信

安装前使用 istioctl manifest generate，最恰当的实际原因是什么？

• 将即将安装的内容保存为文件，以便审查、提交，并在升级时查看 diff
• 因为生成的 manifest 不包含 CRD，可以让集群保持轻量
• 因为 generate 已完成 schema 校验，不再需要单独执行 istioctl validate
• 因为应用预先生成的 manifest 比执行 istioctl install 快得多

为什么要把 xDS 合并到单条 ADS 流中发送？

• 为了避免为每类配置分别建立 gRPC 连接，减少 mTLS 握手成本
• 因为 Envoy 无法通过独立流接收 CDS、EDS、LDS、RDS，只支持统一流
• 因为只有 ADS 支持只发送变化部分的增量传输，而不是每次重发全部配置
• 为了避免 cluster、endpoint、listener 和 route 以不一致的顺序到达并破坏配置

对 istioctl kube-inject 的描述，哪项是正确的？

• 它会将输入的 manifest 应用到集群，立即创建带有 sidecar 的 Pod
• 它会在已有 Pod 中添加 sidecar 容器，无需重启就能将其纳入网格
• 它会预先下载 sidecar 镜像并缓存在节点上，以缩短注入时的启动时间
• 它会预先对 manifest 文件执行 webhook 在创建 Pod 时所做的规约修改，并输出结果

sidecar 模式的哪项成本在实践中经常成为问题？

• VirtualService 和 DestinationRule 不断增加，大量占用 etcd 容量
• 每个 Pod 增加的内存与启动延迟，以及升级时必须重启全部 Pod
• 必须在应用代码中加入各语言的流量管理 SDK，并随应用一起部署
• 控制平面转发所有请求，额外增加一跳并提高延迟