reconcile 函数启动 panic 的根本原因是类型未注册进 scheme，需在 ctrl.newmanager() 前调用 myappv1.addtoscheme(scheme.scheme)；status 更新必须用 status().update()；configmap 变更不触发 reconcile 因 generation 不变，应改用 resourceversion 判断或自定义 predicate；获取 pod 日志须绕过 cache 直连 api server。
Reconcile 函数为什么一启动就 panic
根本原因不是逻辑写错了，而是类型没注册进 Scheme。ctrl.NewManager() 启动时若没调用 myappv1.AddToScheme(scheme.Scheme)，后续所有 r.Client.Get() 都会直接 panic，错误信息像 no kind "MyApp" is registered——这跟 CRD 是否 kubectl apply 成功无关，是 Go 类型和 API Server 之间“语言不通”。
- 确认
AddToScheme调用在ctrl.NewManager()之前，且路径正确（通常在api/v1/register.go） - 检查 CRD YAML 中
spec.versions[0].name（如v1）和 Go struct 的GroupVersionKind().Version完全一致 - 多版本 CRD 下，只有 storage version 被 scheme 默认识别；其他版本需 conversion webhook，client 不自动转换
Reconcile 里怎么安全更新 status 字段
Status().Update() 是唯一合法方式，用 r.Client.Update() 全量提交会失败且静默：APIServer 拒绝请求、status 不变、日志里只报 Operation cannot be fulfilled。
- 必须写成
r.Status().Update(ctx, &myApp)，不能漏掉.Status() -
MyAppStatus结构体字段必须全部首字母大写（导出），不能含函数或嵌套指针 - 如果
Status().Update()返回 error，直接return ctrl.Result{}, err，别 sleep 或重试——它本就不该重试
为什么改了 ConfigMap，Reconcile 却不触发
因为默认的 GenerationChangedPredicate 对 ConfigMap/Secret 无效：它们更新内容不改变 metadata.generation，只变 resourceVersion。
- 换用
predicate.LabelChangedPredicate{}，或自定义 predicate 判断resourceVersion变化 - 若需按 label 索引 ConfigMap（比如只监听
app=myapp），必须先调mgr.GetFieldIndexer().IndexField()注册索引，再显式Watches() - 漏掉
.Owns(&corev1.ConfigMap{})就收不到子资源事件，.For(&MyApp{})只监听 MyApp 本身
Reconcile 中获取 Pod 日志为什么总是 panic
r.Client 是带 cache 的读写客户端，而日志接口必须绕过 cache、直连 API Server。直接 r.Client.Get() 拿到 Pod 再调日志方法，会因类型不匹配或 cache 缺失 panic。
- 正确做法是用
corev1clientset.CoreV1().Pods(namespace).GetLogs()，client 需从r.Client.Scheme()和原始*rest.Config构造 - 不要在 Reconcile 中同步调用日志接口——它可能超时，阻塞整个 reconcile queue
- 应改为异步：把日志拉取逻辑放进独立 job，或通过 Event / Status 字段上报摘要
OwnerReference 显式声明；所有状态更新都要走 Status().Update() 而非全量写入。这些不是“最佳实践”，而是不这么做就会静默失败的硬约束。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
