测验：Kubernetes 架构

如果我在 kube-scheduler 完全停止的集群中创建新的 Deployment，会发生什么情况？

• 部署创建本身被拒绝
• Deployment 和 ReplicaSet 已创建，Pod 已创建，但仍处于 Pending 状态。
• kubelet 代表调度程序选择一个节点并启动 pod。
• apiserver 以循环方式分配节点

控制器管理器或调度器被设计为通过 apiserver 而不是直接读取 etcd 的最大原因是什么？

• 这是因为 etcd 的 gRPC 协议仅在 Go 语言中运行。
• 在某一点强制执行身份验证、授权、准入、验证和审核，并向组件隐藏存储格式更改。
• 这是因为 etcd 最多只允许两个同时连接。
• 这是因为etcd没有watch功能，所以apiserver使用轮询代替。

在什么情况下kubectl api-resources会给出比文档站点更准确的答案？

• 当您想提前知道下一个版本将添加哪些资源时
• 当需要每个字段的详细描述和示例 YAML 时
• 跟踪特定资源过去的 API 版本更改历史记录时
• 当您需要包含在此集群中作为 CRD 安装的自定义资源的实际列表时。

基于标签选择器的连接有哪些典型陷阱？

• 如果选择器未对齐，对象创建本身将失败并且部署将被阻止。
• 即使选择器未对齐，对象也会正常创建，但它不会安静地运行，因为它无法捕获任何目标。
• 标签不区分大小写，因此不同的 pod 会混淆
• 选择器一次只能指定一个标签条件。

在具有 3 个 etcd 成员法定人数的集群中，第一个控制平面节点死亡，并且 kubectl 根本无法工作。最可能的原因是什么？

• etcd 仲裁被破坏，集群变为只读。
• 所有客户端的服务器地址都设置为死节点的物理IP，并且证书SAN中没有其他节点IP，因此旁路连接也无法通过TLS验证。
• 当调度程序终止时，apiserver 也会终止。
• 如果控制器管理器无法选举领导者，则 apiserver 会拒绝该请求。

命令式（kubectl create）和声明式（kubectl apply）之间最准确的实际区别是什么？

• apply 将所需状态保留在文件中并记录最后应用的配置，允许重复应用、差异计算和反转。
• create只能创建pod，apply可以创建各种资源。
• create 仅在本地工作，无需经过集群。
• apply 总是删除现有对象，然后创建一个新对象。