测验：请求、就绪与回收的证据

应用程序已 Synced=True·Ready=False，但 pod 的 HTTP 正常。首先要检查什么？

• 组合检查实际资源的条件名称
• 如果删除该服务，父请求是否也会恢复正常？
• 为开发人员提供集群管理是否会导致更快的响应？
• 如果取消 Ready 检查，操作验证是否就足够了？

为什么我团队的replicas=4 请求与其他团队的replicas=1 请求的失败情况不同？

• 两者都有相同的架构错误，因此团队权限无关。
• 第一个是投入限制，第二个是侵犯目标团队的权限。
• 前面是镜像错误，后面是服务端口错误。
• 两者仅在正常验收后的 pod 准备阶段失败。

更改后立即可见之前的“就绪”状态。反映新环境的更有力证据？

• 事实上，metadata.name 与旧名称相同
• 事实上 apply 命令以退出代码 0 结束
• 当前观察生成、更新副本数以及相应 pod 的响应
• 存储过去一次成功的 HTTP 响应的文件

该应用程序的副本=2，但我将子部署更改为 3，然后返回到 2。最好的解释是什么？

• Kubernetes 本身不允许第三个副本
• 已创建新的请求 UID 并自动与之前的应用程序合并。
• API服务器无条件丢弃所有手动补丁
• 控制器将其子状态收敛到原始应用程序的声明。

delete --wait=false 成功，但删除时间戳和终结器被留下。什么是正确的决定？

• 我要求删除它，但它的实际缺失尚未得到证实。
• 自从我收到成功回复以来，所有子资源都已经消失了。
• 如果至少有一个终结器，则无法永久删除它。
• 由于父对象仍然存在，因此所有子 pod 也必须处于活动状态。

为什么我们在为教育释放终结器时首先检查UID和resourceVersion？

• 保证查询API的响应速度
• 避免覆盖新对象或同名的并发更改
• 自动跳过其他控制器的清理工作
• 一次删除命名空间中的所有资源

资源列表查询失败，出现身份验证错误。删除检查器的正确处理是什么？

• 由于没有响应列表，因此另存为“已恢复”
• 由于之前有成功文件，因此将其保存为当前不存在。
• 将观察视为失败并调查搜索同一对象的原因
• 删除其他队伍，再检查一下结果是否为空。

我用相同的名称重新创建了应用程序，并且拥有旧的ready.json。你能写出这个记录吗？

• 相同的名称和命名空间就足够了。
• 一旦 HTTP 响应，它就可以用于任何请求。
• 如果将文件时间更改为当前时间，您将得到相同的观察结果。
• UID 不同，因此之前请求的记录无法重复使用。