测验：Operator 模式与调谐循环

传递给协调函数的是什么？

• 只有对象的键（命名空间/名称）
• 变更前后的 diff
• watch 事件的原始 JSON
• 整个变更对象及事件类型

判断协调逻辑是否幂等，最实用的标准是什么？

• 第二次执行没有报错，返回同样的结果码
• 每次协调的执行时间都差不多
• 已处于正确状态时，下游对象的 resourceVersion 不再改变
• 第二次执行的日志没有出现 changed 或 updated

外部依赖尚未就绪时，应该如何处理？

• 在 status 中记录失败，等待下一个事件
• 返回错误，交给工作队列进行指数退避重试
• 在协调函数中不断轮询，直到就绪
• 不返回错误，而是延迟重新入队，表示稍后再检查

防止控制器写入自己的 status 后陷入无限协调循环，标准方法是什么？

• 仅处理 generation 变化的事件
• 在每次协调之间加入 sleep，拉长重调用间隔
• 将工作线程并发数降为 1，消除重复处理和重调用
• 把 status 移到 annotation 中，排除监视

请求删除带有终结器的对象时，会发生什么？

• 终结器存在时删除请求被拒绝并返回错误
• API 服务器自动移除终结器后删除对象
• 对象立即删除，并通知控制器清理
• 对象被标记 deletionTimestamp，但仍保留，协调函数会再次调用

终结器中的清理函数不具备幂等性，会造成哪种典型事故？

• 清理执行两次，对象被删除两次，事件也留下两条
• 删除已不存在的资源时报错，终结器无法移除，删除永远不能完成
• 垃圾回收器不仅删除子对象，还会删除父对象
• 每次重试清理时，status 中的 conditions 都被重置为空

子对象已经通过所有者引用关联，何时仍需要终结器？

• 清理目标位于集群之外，垃圾回收器不知道它的存在时
• 需要启用 status 子资源记录条件时
• 一个父对象关联多个子对象时
• 子对象位于与父对象不同的命名空间时