测验：区分拒绝、超时和注册缺失

在replicas=0之后，就会创建一个违规的pod。那时，ValidatingWebhookConfiguration也消失了。最准确的结论是什么？

• 由于没有进行呼叫登记，所以无法证明Fail的呼叫失败处理。
• 由于策略仍然存在，失败证明了一个忽略错误的错误。
• 由于 Pod 已经创建完毕，正常状态下的 Deny 也不起作用。
• 由于没有控制器，所有命名空间的验证都已关闭

更改为“忽略”后，正常的 Kyverno 显式拒绝了缺少的环境标签。我应该期待什么结果？

• 既然是Ignore，就丢弃拒绝响应并保存Pod。
• 保留显式策略拒绝且不保存 Pod
• 等待3秒，将拒绝结果更改为成功并保存。
• 由于背景评估已关闭，因此录取也被省略。

由于 webhook 超时，来自目标 NS 的正常请求和违规请求均失败，并且保存了范围外 NS 的违规请求。正确的解释是什么？

• 已保存一项违规请求，因此所有请求的“失败”均被忽略。
• 由于正常请求也失败了，所以标签验证方程的结果被颠倒了。
• 与 webhook 调用匹配的作用域被阻止，越界控制被传递。
• 由于越界请求成功，目标 NS 中的错误是分级机问题。

故障前后同名的 Pod 正在运行。还需要哪些额外观察才能得出现有吊舱幸存下来的结论？

• 验证 Pod 名称和标签键的排序顺序是否相同。
• 仅比较前后的容器镜像标签字符串。
• 只比较当前命名空间中的 Pod 总数。
• 将故障前保存的 Pod UID 与当前 UID 进行比较。

暂停工具的父进程可能会被强制终止。以下哪项是本实验的正确回收率设计？

• 一个单独的观察者在时限内恢复与 pidfd 相同的目标。
• 假设即使强制终止，也仅执行父级的finally。
• 当您按下下一步实验步骤的按钮时，使用数字 PID 继续
• 查找具有相同进程名称的所有目标并发送恢复信号

失败 实验请求因 AlreadyExists 失败。接下来怎么办？

• 由于请求失败，webhook超时被记录为成功。
• 使用新名称请求并再次观察实际错误以及是否保存。
• 放松分级机仅比较退出代码而不是错误短语
• 删除目标NS并再次检查是否创建成功。