找出终止报告中的过度推断

被删除的 Pod 端点被观察为 read=false。仅从这些价值观不能得出什么结论？

• 关闭期间的端点应与正常就绪状态分开读取。
• 服务器已经接受的 HTTP 请求也立即被断开。
• 现有请求的结果必须通过单独的响应观察来确认。
• 服务和终止也需要一起阅读。

当我们第一次将 preStop 添加到部署模板时，我们测量了部署情况。我应该首先检查什么来评估旧 Pod hook 的有效性？

• 确保新 ReplicaSet 的名称仅与旧名称不同。
• 检查修改后的Deployment YAML中是否有生命周期。
• 验证转出完成消息中没有错误。
• 检查实际终止的 Pod 的 UID 和现有生命周期。

preStop 需要 3 秒。计划终止GracePeriodSeconds 时，正确的说法是什么？

• 在同一宽限期内考虑挂钩时间和 TERM 之后任何必要的清理。
• 在钩子结束时，宣布的整个暂停宽限期重新开始。
• 如果挂钩成功，则无论宽限期如何，正在处理的请求都会等到结束。
• 挂钩的睡眠是一个独立的时间段，不包括在终止宽限计算中。

已确认容器退出代码 137 和客户端断开连接。以下哪一个判断最为合理？

• 137 始终是低内存，因此无需查看宽限设置
• 如果是137，则是网络连接问题，因此服务器信号处理无关。
• 通过检查终止原因、实际推迟以及信号观察来缩小原因。
• 由于我们观察到断开连接，因此我们不检查哪个 Pod 响应

Pod Ready 后立即发送的第一个服务请求因连接超时而结束。终止 在写下实验结果之前还缺少什么？

• 客户端重试次数增加记录
• 使新 Pod 与旧 Pod 同名的记录。
• 请注意，preStop 字符串在文件中出现一次。
• 在服务路径准备和删除之前确认服务器接受的记录

Graceful Shutdown 应用程序正在处理它已经接受的 8 秒操作，并且 preStop 也被执行。对时间的正确解释是什么？

• 将挂钩时间添加到总工作时间始终是正确的结束时间。
• 任务和挂钩可能会重叠，因此请查看每个事件和学期后的剩余时间
• 在优雅模式下，即使处理时间比优雅模式长，处理也始终完成。
• 从 API 删除请求开始，所有节点都以相同的速度终止。

如果重新评分时新建一个已经被删除的Pod，再次进行同样的实验，会出现什么问题？

• 替换为新的执行而不检查先前的结果并更改状态。
• 它实际上更准确，因为它保留了观察到的过去的 Pod UID。
• 如果两次执行结果相同，则无需区分不同的UID。
• 当重用相同名称时，Kubernetes 还会恢复以前的连接

来自单个 k3s 服务的一个请求在关闭期间正常完成。您可以在报告中写下哪些结论？

• 所有请求都不会中断，即使对于具有外部负载均衡器的运营服务也是如此。
• 只要设置相同，任意工作时间和流量总是安全的。
• 此 Pod 在本次运行中接受的请求是在关闭期间完成的。
• 如果只实现终止处理，则任务重试不需要幂等性。