测验：集群架构

调度程序或控制器被设计为通过 kube-apiserver 而不是直接附加到 etcd 的关键原因是什么？

• 这是因为 etcd 客户端库仅适用于 Go。
• 这是因为 etcd 无法同时接收三个以上的客户端连接。
• 因为kubelet没有etcd证书。
• 这是因为授权、验证、准入和审计被绕过，每个组件都被组合到 etcd 存储格式中。

三个控制平面上的三个 etcd 成员正常，但是当第一个节点死亡时，所有节点上的 kubectl 和 kubelet 都变得无法连接。最可能的原因是什么？

• 由于 etcd 仲裁丢失，写入被阻止
• controlPlaneEndpoint 和所有 kubeconfig/kubelet 设置都指向死节点的物理 IP，并且 apiserver 证书 SAN 中没有其他节点 IP。
• kube-controller-manager 的领导者选举失败，停止所有控制循环。
• CNI 挂掉，pod 网络断开。

为什么将控制平面从 1 增加到 2 相当危险？

• 如果有两个成员，就不可能选出一个领导者。
• 由于成员 2 的多数为 2，因此如果其中任何一个死亡，法定人数就会丢失并且写入会被阻止。
• 如果成员数量是偶数，Raft 拒绝启动。
• 由于两个成员必须共享 WAL 文件而发生磁盘争用

哪项正确描述了 kube-scheduler 的过滤阶段和评分阶段？

• 使用分数选择候选节点后，使用过滤器选择一个最终节点。
• 对等待的 Pod 进行过滤排序，对节点进行评分排序
• filter 删除候选节点中违反约束的节点，score 对剩余节点进行评分并选择得分最高的节点。
• 过滤由 kubelet 执行，评分由调度程序执行

关于控制器的协调循环，以下哪一项是正确的？

• 如果您错过了哪怕一个监视事件，该资源的状态就会永久不同步。
• apiserver 向每个控制器发出有关做什么的命令。
• 通过反复减少声明状态和观察状态之间的差异，即使错过一个事件，它也可以通过定期重新同步来收敛。
• 为了提高性能，控制器直接写入 etcd。

如果我仅通过应用 CRD 而不安装自定义控制器来创建 CR，会发生什么情况？

• apiserver 检测到控制器不存在并拒绝请求。
• kube-controller-manager 将其作为默认控制器处理
• 对象在模式验证后保存，但没有发生实际更改，因为没有人协调它们。
• 创建 CRD 时会自动创建控制器 Pod