测验：用 CR 部署应用

如果对启用了 status 子资源的 CR 使用普通 update 写入 status，会怎样？

• spec 和 status 都会保存
• status 部分会被静默忽略
• generation 会增加
• 请求会报错并被拒绝

为什么所有者引用使用 uid 而不是名称进行关联？

• 因为名称在不同命名空间中可能重复，容易冲突
• 因为 uid 比名称短，可以节省 etcd 存储空间
• 因为名称只能用于标签选择器匹配，不能用于引用
• 因为删除父对象后用相同名称重新创建，得到的是另一个对象

为什么 conditions 中要同时包含 reason 和 message？

• 因为 reason 保存之前的状态，message 保存当前状态
• 因为告警规则按 reason 分支，而人类阅读 message
• 因为 Kubernetes 强制要求两个字段都存在
• 因为 message 有长度限制，需要拆分到 reason 中

当 status.observedGeneration 小于 metadata.generation 时，意味着什么？

• 在 status 子资源关闭的情况下保存了对象
• 控制器尚未应用最新规范
• 存储版本过旧，转换尚未完成
• 对象正在删除，因此更新已停止

关于 CR 中 spec.tier 的值与 metadata.labels.tier 标签之间的关系，哪项正确？

• spec.tier 和标签只要存在一个，就能用标签选择器筛选
• 标签即使位于 metadata 中，也只能通过 status 用于查询
• spec 是控制器读取的意图，标签是供人和工具选择的索引，两者职责不同
• 在 spec.tier 中设置值后，API 服务器会自动添加相同标签

为什么在 spec 中加入 restartNow: true 之类的字段是一种反模式？

• 因为它是一次性命令，执行后便失去意义，协调循环无法在每次运行时重新做出一致判断
• 因为布尔字段既无法通过 CEL 验证，也无法通过 OpenAPI 模式验证
• 因为把默认值设为 true 会导致无限重启
• 因为一次性信号只能放在 status 中，不能放在 spec 中

如果在 status 中不断以数组形式累积事件日志，会产生什么问题？

• 每次更新都会重写整个对象，控制器缓存占用的内存也会同步膨胀
• 数组变大后，status 子资源会自动关闭
• etcd 不支持大型数组字段，因此会拒绝保存
• 数组占用空间后，就无法同时使用 conditions