Operator 模式核心：CRD 与 reconcile 循环如何把运维知识（备份、扩容、升级）编码为自动化？
Operator 模式用 CRD 定义应用的自定义期望状态（如备份策略、副本数、升级版本），Operator 控制器通过 reconcile 循环持续对比期望状态与当前状态，把运维知识（备份、扩容、升级、故障处理）编码为自动化逻辑。用户只声明 CR 的期望状态，Operator 自动执行所有运维操作（创建 Deployment、执行备份、滚动升级、故障恢复）。核心是把"人做运维"变成"代码做运维"，实现应用级自动化与自愈。
核心是"CRD 声明期望 + reconcile 驱动运维自动化"。Operator 编码运维知识。
controller-runtime 抽象：Manager、Controller、Reconciler、Cache、Client 的分工与启动流程？
controller-runtime 是构建 Operator 的框架。Manager 统筹所有 controller 的启动与生命周期（Leader Election、metrics、健康检查）。Controller 负责监听资源并调度 reconcile（informer 触发、并发 worker）。Reconciler 实现 reconcile 逻辑（对比期望与当前，返回 Result）。Cache 提供缓存读（informer 缓存，减少 API 访问），Client 提供读写 API（缓存读 + 直连写）。启动流程：创建 Manager → 向 Manager 注册 Controller（传入 Reconciler、watch 资源）→ 启动 Manager（启动各 controller、Leader Election、缓存同步）→ 等待信号。Controller 通过 Builder 绑定 Reconciler 与 watch。
核心是"Manager 统筹、Controller 触发、Reconciler 实现逻辑、Cache 缓存读、Client 读写"。启动时注册并启动。
reconcile 循环机制：期望状态与当前状态对比、事件触发、requeue 与幂等性要求如何？
reconcile 循环：事件（CR 增删改、关联资源变化）触发 reconcile，函数读取期望状态（CR spec）与当前状态（实际资源），对比差异并执行操作使其收敛，返回 Result（Requeue 决定是否重入队）。requeue：操作未完成或临时失败时 Requeue 重试（带退避），RequeueAfter 定时重新 reconcile。幂等性要求：reconcile 可重复执行（相同输入产生相同结果），因为事件可能丢失、重复触发，只有幂等才能保证最终一致。这是控制器设计的核心要求。
核心是"事件驱动 + 对比修正 + requeue 重试 + 幂等"。幂等保证最终一致。
Admission webhook 在 Operator 中的角色：默认值注入、校验、failurePolicy 与故障模式？
Operator 常用 Admission webhook：mutating webhook 在 CR 创建/更新时注入默认值（如缺省字段、自动计算），validating webhook 校验 CR 是否合法（如必填字段、范围、版本）。failurePolicy 决定 webhook 失败时行为：Ignore（忽略继续）或 Fail（拒绝请求）。故障模式：webhook 不可达时，Ignore 会放行但可能绕过校验，Fail 会阻断所有操作（安全但可能整体不可用）。设计时需权衡：校验严格用 Fail，非关键用 Ignore。webhook 用 TLS 证书通信。
核心是"注入默认值 + 校验 + failurePolicy 控制故障行为"。故障模式需权衡。
CRD 设计：版本与 conversion、status 子资源、scale 子资源、schema 校验与 CEL 规则？
CRD 设计要点：1）多版本：可声明多个版本（v1alpha1/v1），用 conversion webhook 或 CEL 转换保护存储版本；2）status 子资源（subresources.status: true）：使 status 独立存储，只读，控制器通过 status 更新，避免与 spec 冲突；3）scale 子资源（scale: true）：支持 HPA 与 kubectl scale，通过 specReplicasPath/statusReplicasPath 映射；4）schema 校验：在 openAPIV3Schema 定义字段类型与约束，校验 CR 合法性；5）CEL（Common Expression Language）：在 schema 中用 x-kubernetes-validations 写 CEL 表达式做复杂校验（如字段间依赖）、default 默认值。这些提高 CRD 的健壮性与可用性。
核心是"版本转换 + status/scale 子资源 + schema 与 CEL 校验"。CEL 增强复杂校验。
Operator 升级与生命周期：CRD 演进、webhook 与控制器版本配套、回滚与兼容策略？
Operator 升级：1）CRD 演进：升级 CRD 时要保证新版本兼容（多版本 + conversion），存量 CR 平滑迁移；2）webhook 与控制器版本配套：升级控制器时 webhook 与控制器需同步升级，避免 webhook 校验与控制器逻辑不一致；3）回滚与兼容：升级前备份 CRD，回滚时恢复；新版本兼容旧版本 CR（字段默认值、废弃字段）。策略：先升级 CRD（支持多版本），再升级控制器与 webhook，灰度验证，失败回滚。CRD 不可逆变更（如删除字段）需谨慎。
核心是"CRD 多版本兼容 + webhook 与控制器配套升级 + 回滚预案"。升级需兼容存量。
Operator 可观测性：reconcile 次数/时长/失败率、workqueue 深度与事件指标化如何做？
Operator 可观测性通过 Prometheus 指标暴露：reconcile 次数（reconcile total）、时长（reconcile duration，histogram）、失败率（reconcile errors）、workqueue 深度与速率（workqueue_depth、workqueue_adds 等，client-go 自带）、事件（创建/更新/删除的事件计数）。controller-runtime 提供内置 metrics（workqueue、rest_client 请求）。配合日志（结构化）与事件（Event 上报）形成可观测性。指标用于监控 Operator 健康与性能，配置告警。
核心是"Workqueue/API 指标 + reconcile 自定义指标 + 事件"。controller-runtime 暴露内置指标。
finalizer 语义：删除保护与异步清理、finalizer 卡住导致对象无法删除的排查？
finalizer 标记在对象 metadata.finalizers 中，用于删除保护：对象被删除时，若仍有 finalizer，对象进入 Terminating 状态（不真正删除），直到所有 finalizer 被移除。finalizer 用于异步清理（如删除外部资源、依赖对象）。控制器监听删除事件，执行清理后移除 finalizer，对象才被删除。finalizer 卡住：控制器未运行或清理失败，finalizer 无法移除，对象一直 Terminating。排查：kubectl get <obj> -o yaml 看 finalizers，检查控制器状态/日志，确认清理逻辑。必要时手动移除 finalizer（危险，可能残留外部资源）。
核心是"finalizer 阻塞删除直到清理完成"。卡住多因控制器失败。
kubebuilder 与 Operator SDK 选型：脚手架、代码生成（deepcopy/CRD manifests）与测试框架差异？
kubebuilder 与 Operator SDK 都是脚手架工具。kubebuilder：官方推荐，基于 controller-runtime，生成 API/Controller 骨架、deepcopy 代码、CRD manifests（通过 controller-gen），内置 envtest 测试框架。Operator SDK：基于 helm/ansible/golang 三种语言，更易让非 Go 用户用 Helm/Ansible 写 Operator，也支持 Go（基于 kubebuilder）。差异：kubebuilder 更贴近 controller-runtime 原生、轻量；Operator SDK 支持多语言（Helm/Ansible）且封装更完整。选型：Go 项目用 kubebuilder，多语言/快速用 Operator SDK。两者都生成 deepcopy、CRD、Manifests。
核心是"两者都生成 deepcopy/CRD，kubebuilder 原生 Go，Operator SDK 支持多语言"。
主流 Operator 运维实践：Prometheus Operator、Strimzi、etcd-operator 如何用 CRD 简化运维？
主流 Operator 用 CRD 简化运维。Prometheus Operator：用 Prometheus/ServiceMonitor/Alertmanager 等 CRD 声明监控配置，自动创建/管理 Prometheus 实例、抓取目标、告警规则，无需手动维护 Prometheus 配置。Strimzi：用 Kafka CRD 管理 Kafka 集群（创建、升级、扩容、Topic 管理），实现 Kafka 运维自动化。etcd-operator：用 EtcdCluster CRD 管理 etcd 集群（创建、扩缩容、备份、故障恢复）。共同点：CRD 声明期望状态，Operator 自动执行部署与运维，简化了复杂分布式系统的管理。
核心是"CRD 声明 + Operator 自动化运维复杂系统"。Prometheus/Strimzi/etcd 都是范例。
控制器与 API Server 交互：informer/watch/cache、事件处理与限速队列（workqueue）机制？
控制器通过 informer 与 API Server 交互：List+Watch 资源，缓存到本地（cache/store），注册事件回调。事件处理：Add/Update/Delete 回调把对象 key 放入 workqueue。workqueue 是限速队列（RateLimitingQueue）：带指数退避（rate limiter）与延迟（delaying queue），同一 key 去重，处理失败按策略重试。worker 从队列取 key 调用 reconcile。限速队列防止单对象风暴导致重复处理，保护 API Server。informer 的 resync 定期全量同步兜底。
核心是"informer 缓存 + workqueue 限速去重"。这是控制器与 API Server 交互的核心。
控制器高可用：Leader Election（lease）机制、多副本运行与 leader 切换的优雅过渡？
控制器高可用用 Leader Election：多副本运行但只有 leader 实例执行 reconcile，其他副本 standby。通过 Lease 对象（coordination.k8s.io）实现：leader 定期续租（renew），非 leader 监听 lease，leader 失去租约后其他副本竞选成为新 leader。controller-runtime 的 Manager 内置 Leader Election（LeaderElectionID、LeaderElectionNamespace 配置）。leader 切换时新 leader 重建缓存（list/watch 全量），期间 reconcile 可能延迟，但保证仅一个 leader 执行，避免重复操作。优雅过渡：leader 释放租约、新 leader 接管。
核心是"Lease 租约实现单 leader + 多副本 standby"。切换时重建缓存。
CRD 的 status conditions 与事件上报：如何用 conditions（Available/Progressing/Degraded）表达资源状态，与 kubectl 展示和告警的衔接？
CRD 的 status.conditions 用标准化的 conditions（如 Available、Progressing、Degraded）表达资源状态，每个 condition 有 type、status（True/False/Unknown）、reason、message、lastTransitionTime。控制器根据 reconcile 结果更新 conditions：Available 表示就绪可用，Progressing 表示正在推进，Degraded 表示退化。与 kubectl 展示衔接：通过 kubectl describe 显示 conditions，或自定义 printer columns（kubectl get 显示状态列）。告警衔接：监控系统（Prometheus）采集 conditions 或事件，根据 Available=False/Degraded=True 触发告警，实现资源状态可视化与告警。
核心是"conditions 标准化表达状态 + printer columns 展示 + 监控告警"。条件便于 kubectl 与告警消费。
Operator 的性能与并发控制：reconcile 并发数、workqueue 限速与批量事件合并，慢 reconcile 的排队与并发上限如何设置？
Operator 性能控制：1）reconcile 并发数：controller-runtime 的 MaxConcurrentReconciles（max concurrency）设置并发 worker 数，提高吞吐但需注意资源；2）workqueue 限速：RateLimiter 控制重试频率（指数退避），防止风暴；3）批量事件合并：workqueue 对同一 key 去重合并，多个事件合并为一次 reconcile；4）慢 reconcile：若 reconcile 慢，会排队，需设置并发上限避免堆积，可拆分 reconcile 或异步操作。参数通过 controller-runtime 的 controller.Options 配置（MaxConcurrentReconciles、RateLimiter）。
核心是"MaxConcurrentReconciles 控制并发 + workqueue 限速合并 + 慢 reconcile 排队管理"。
Operator 的配置与扩展点：ControllerConfig、环境变量与 feature gate 如何设计，避免把业务配置硬编码进控制器？
Operator 配置设计避免硬编码业务配置：1）ControllerConfig（CR/ConfigMap/参数）保存可配置项（如镜像、超时、并发），控制器读取；2）环境变量注入运行参数（Pod env），适合部署相关配置；3）feature gate 控制可选功能开关（--feature-gates 或 flag），便于渐进启用；4）业务逻辑参数（如镜像 tag、副本数）放 CR spec 或 ConfigMap，不硬编码。设计扩展点：定义清晰的配置接口（Config 结构体、flag、ConfigMap），控制器从这些来源读取，避免改代码。监控与日志配置也通过配置而非硬编码。
核心是"配置用 ConfigMap/flag/env/CR 归一化，避免硬编码业务值"。设计可配置扩展点。
多版本 CRD 兼容：v1alpha1 到 v1 的 conversion webhook、字段废弃策略与客户端迁移，如何保证存量资源平滑升级？
多版本兼容：1）CRD 声明多个版本（v1alpha1、v1），指定 storage 版本；2）conversion webhook（或 CEL 转换）在版本间转换对象，保证 v1alpha1 与 v1 可互转；3）字段废弃策略：废弃字段在新版本标记 deprecated/移除，但转换时兼容（保留旧字段或默认值），避免存量数据丢失；4）客户端迁移：客户端从 v1alpha1 迁移到 v1，测试后切换。平滑升级：先引入新版本（同时保留旧版本），CRD 转换保证存量 CR 可读可写，之后客户端切换，最后废弃旧版本。存量资源通过转换保留数据。
核心是"conversion webhook 转换 + 字段兼容 + 客户端分阶段迁移"。多版本并存平滑升级。
Operator RBAC 与多租户：cluster-scoped 与 namespace-scoped 控制器、最小权限清单设计？
Operator RBAC 设计：1）cluster-scoped 控制器：管理集群级资源（如 CRD、ClusterRole），需要 cluster 级权限（ClusterRole/ClusterRoleBinding）；2）namespace-scoped 控制器：只管理某命名空间资源，用 Role/RoleBinding 限定权限，保证多租户隔离。最小权限清单：只授予控制器运行所需的 verbs/resources（get/list/watch/create/update/patch/delete 到必要资源），通过 kubebuilder 的 RBAC marker 生成。多租户时，namespace-scoped Operator 用各自命名空间权限，避免越权。服务账号（ServiceAccount）绑定最小权限。
核心是"cluster-scoped vs namespace-scoped + 最小权限清单"。多租户用 namespace 权限隔离。
Operator 测试：envtest、表驱动 reconcile 测试与故障注入如何验证控制器正确性？
Operator 测试：1）envtest：用 controller-runtime 的 envtest 启动本地 control plane（etcd+apiserver）进行集成测试，验证控制器与真实 API 交互；2）表驱动 reconcile 测试：用表格列出测试用例（输入 CR、期望状态），调用 Reconcile 并断言结果，覆盖正常与异常路径；3）故障注入：模拟 API 失败、资源冲突、超时，验证控制器容错与重试。结合单元测试（ginkgo）、集成测试（envtest 真实环境）与 e2e。测试验证 reconcile 幂等性、条件更新、错误处理。
核心是"envtest 集成测试 + 表驱动用例 + 故障注入"。验证控制器正确性与容错。
从脚本运维到 Operator 的演进：何时值得写 Operator，与 CronJob、工作流平台的边界？
何时值得写 Operator：当应用需要持续满足期望状态（reconcile 循环）、有复杂生命周期（备份、升级、扩容、故障恢复）、需要事件驱动自愈、或运维知识需复用自动化时。若只是周期任务（如定时备份），用 CronJob 即可；若是复杂工作流编排，用工作流平台（Argo Workflows、Tekton）。边界：Operator 专注于"持续维护期望状态"的控制器，CronJob 专注定时触发一次任务，工作流平台专注编排多步骤流程。演进：从脚本/CronJob 起步，当需要状态一致性与自愈时演进为 Operator。Operator 适合有状态、需自愈的复杂应用。
核心是"Operator 适合持续期望状态自愈，CronJob 定时任务，工作流编排流程"。按需演进。
