测验：Operator 的运维

安装 Operator 时，为什么必须先创建 CRD，再创建控制器 Deployment？

• 因为 CRD 清单引用了控制器 Deployment 的镜像标签
• 因为垃圾回收器需要先有 CRD 才能建立所有者引用
• 因为 CRD 注册耗时，控制器先启动就会超时
• 因为控制器启动后立即 watch 该类型，类型不存在就会陷入崩溃循环

RBAC 已授权更新 webservices，但控制器仍无法写入 status。原因是什么？

• CRD 禁用了 status 子资源，写入会被忽略
• CRD 是集群范围资源，应使用 Role 而不是 ClusterRole
• status 属于创建操作，需要 create 而不是 update 权限
• webservices/status 是独立资源，需要单独授权

ClusterRoleBinding 的 subject 名称与实际服务账号不同时，会怎样？

• 绑定正常创建，只有控制器遇到 403
• 不存在的主体会被替换成默认服务账号
• 主体存在性检查会拒绝该绑定
• 系统会自动改成最相近的服务账号名称

为什么控制器在很多情况下不需要 delete 权限？

• 删除 CRD 时，该类型的子对象会自动全部清理
• 删除请求通过 status 子资源处理
• 可以让所有者引用和垃圾回收器清理子对象
• kubectl delete 会在客户端代为清理

对领导者选举的必要性，哪项描述最准确？

• 让待命副本清空缓存，减少总内存用量
• 只让一个副本建立 watch，避免 API 服务器的速率限制
• 防止多个副本同时协调同一对象而发生冲突
• 让多个副本分担对象以实现负载均衡

升级 Operator 时同步删除 CRD 的旧版本 schema，为什么危险？

• 因为 kubectl 的发现缓存仍持有该版本 schema，请求会出错
• 因为 status.storedVersions 若仍包含该版本，就可能无法读取已存储的对象
• 因为 API 服务器只允许向 CRD 的 versions 列表添加版本，不允许删除
• 因为旧控制器镜像在编译时直接引用了该版本的 Go 类型

为什么权限验证表还要包含“不应该允许的操作”？

• 因为 RBAC 必须显式写拒绝规则
• 如果只验证允许的操作，权限开得过宽也会通过
• 为了增加评分难度
• 因为 kubectl auth can-i 只有回答 no 时才准确