测验：平台架构与基础设施

可分配CPU 24核，三个租户请求的CPU配额上限之和为30核。如果没有当前的 Pod 信息，我们能说什么？

• 总和/容量上限为1.25，实际请求总和和使用情况需单独检查。
• 正在运行的 Pod 保留 30 个核心，其中 6 个核心始终处于待处理状态。
• 集群 CPU 利用率为 125%，因此所有团队都会立即受到限制
• 由于配额总和超出容量，API 服务器拒绝最后一个配额。

新的 Pod 是单个容器，内存请求/限制为 64Mi，没有 CPU 资源或 Pod 级资源。服务质量怎么样？

• 保证：这是因为指定内存的请求和限制是相同的。
• Burstable：内存资源可用，但保证的CPU条件缺失。
• BestEffort：这是因为如果未声明 CPU，内存资源也会被忽略。
• 创建被拒绝：API 架构禁止仅声明内存的 Pod。

同一节点上的两个 Pod 使用相同的 RWO PVC，且均处于 Ready 状态。什么是最合适的决定？

• 由于 RWO 只允许一个 pod，因此 Ready 状态之一必定是假的。
• 由于它们是挂载在一起的，因此验证了两个版本的同时写入一致性。
• RWO 可以允许这样做，但应用程序的同时写入安全性是独立的。
• 您必须在下次 Pod 重新启动之前更改为 RWX 以保留当前共享数据。

新版本的Ledger服务一上线就会更新数据。如果我只曝光蓝色/绿色预览，我应该检查什么？

• 验证服务转换是否自动处理所有文件锁定
• 如果没有外部流量可以预览，则判定没有写入。
• 等待 RWO 自动关闭旧 pod，然后打开新 pod
• 独立于流量，控制两个版本的writer，使它们不重叠。

我降低了 LimitRange 的 defaultRequest，但现有 pod 的请求保持不变。您如何解读这一观察？

• 默认值适用于新的 Pod 准入，因此请分别检查现有对象和新对象。
• 配额控制器自动降低下一个周期中现有 Pod 的所有请求
• kubectl get 缓存是问题所在，因此重新启动 API 服务器以强制使用新的默认值
• 由于defaultRequest已被忽略，删除LimitRange也会删除现有值。

即使添加节点后，我仍然在 pod 事件中看到 nodeSelector 不匹配。下一步适当的行动是什么？

• 如果首先降低总体 CPU 利用率，调度程序会放宽选择器条件。
• 比较选择器和节点标签并检查其他放置约束。
• 增加 PVC 大小会将新节点变成满足选择器的候选节点。
• 通过简单地减少请求量，可以将相同的 Pod 放置在未标记的节点上。