测验：编写并部署 CRD

关于 CRD 的 metadata.name 命名规则，哪项正确？

• 以命名空间作为前缀
• 必须采用 <복수형>.<그룹> 的形式
• 可以任意命名，但不能超过 63 个字符
• 将 kind 转换为小写

启用 status 子资源后，对控制器设计产生的关键影响是什么？

• status 不存储在 etcd 中，只存储在 apiserver 的内存缓存中
• status 中会自动创建 conditions 数组，并由服务器管理
• 写入 status 不会增加 metadata.generation，因此可以与 spec 变更区分开
• status 会变为只读，用户无法通过 kubectl 查看

在 CR 中加入架构未定义的字段并应用时，默认会怎样？

• 该字段会被移入 annotation 并原样保留
• apply 会因架构违规而被拒绝
• 该字段会原样存储，由控制器自行忽略
• 该字段会在存储前被剪除，不发出警告就消失

为什么 scale 子资源需要 labelSelectorPath？

• 让垃圾收集器无需所有者引用也能找到子对象
• 让 API 服务器从多个版本中选择存储版本
• 让 HPA 使用该选择器统计 Pod 并计算指标
• 让 kubectl scale 找到目标 Pod 集合

一个 CRD 同时提供 v1alpha1 和 v1 时，必须遵守什么规则？

• 必须恰好有一个版本的 storage 为 true
• 旧版本的 served 必须设为 false
• 两个版本的架构必须完全相同
• 两个版本的 storage 都必须设为 true

将存储版本从 v1alpha1 改为 v1 后，如果不重新保存现有对象，会发生什么？

• 以旧版本存储的对象会原样保留，导致无法创建同名的新对象
• API 服务器会检测实际存储格式，并自动将 storage 标志恢复为旧版本
• 旧版本会保留在 status.storedVersions 中；如果删除其架构，将无法读取已存储对象
• 每次读取时都会自动执行架构转换，因此跳过重新保存也毫无问题

字段可以设置 default，却仍将其设为 required，会产生什么问题？

• 该字段会自动从 spec 移到 status
• API 服务器会忽略 required 字段的 default，以空值存储
• pruning 不会作用于该字段，因此拼写错误会原样保留
• 用户每次都必须写入相同值，而且以后很难将其降低为可选字段