List()返回Status不准，因其仅读etcd快照，不触发控制器同步；需用Get()轮询直至Status字段匹配Spec且非nil。
直接用 client-go 的 List() 方法查资源，绝大多数情况下能拿到数据，但返回的 Status 字段（比如 AvailableReplicas、ReadyReplicas）经常是 0 或旧值——这不是代码写错了，而是 API Server 返回的是 etcd 快照，不是“实时状态”。
为什么 List() 返回的 Status 总是不准
调用 clientset.AppsV1().Deployments(ns).List() 或 clientset.CoreV1().Pods(ns).List()，拿到的对象里 Status 字段往往滞后。这是因为：
-
List()是一次性的只读快照查询，不触发控制器 reconcile，也不等待状态同步 - Kubernetes 控制器（如 Deployment Controller）更新
Status是异步的，可能有几百毫秒到数秒延迟 - 如果你在刚创建完 Deployment 后立刻
List()，Status.Replicas很可能还是 0
要确认真实就绪状态，必须主动轮询 Get() 并检查字段，例如：Get(ctx, name, metav1.GetOptions{})，直到 Status.AvailableReplicas == Spec.Replicas 且不为 nil。
怎么安全地查 Pod 日志和事件
查日志不能只靠 clientset.CoreV1().Pods(ns).GetLogs() 返回的 rest.ResponseWrapper，它默认不校验容器是否 ready，容易返回空或 EOF 错误。
立即学习“go语言免费学习笔记（深入）”；
- 先用
Get()拿 Pod 对象，检查Status.Phase == "Running"且Status.ContainerStatuses[0].Ready == true - 日志参数推荐显式传
corev1.PodLogOptions{Container: "main", TailLines: &tail}，避免默认行为因容器名缺失报错 - 查关联事件要用
clientset.CoreV1().Events(ns).List()+--field-selector involvedObject.name=xxx,involvedObject.kind=Pod形式，不能只靠标签
用 dynamic 客户端查 CRD 资源时最常踩的坑
查自定义资源（如 ingressroute.contour.io、elasticsearch.k8s.elastic.co）必须用 dynamic.Interface，但新手常卡在 GVR（GroupVersionResource）拼错：
- GVR 的
Group必须全小写、带点号，比如"networking.k8s.io"，不是"networking"或"k8s.io/networking" -
Version要跟 CRD 定义中spec.versions[].name一致，常见是"v1"或"v1beta1"，不是 API path 里的v1 -
Resource是复数小写形式，比如"ingresses"、"ingressroutes"，不是结构体名IngressRoute - 查不到时先用
kubectl api-resources --api-group=xxx确认 GVR 是否注册成功
过滤和分页要注意的边界情况
ListOptions 看似简单，但几个字段组合不当会导致漏数据或 panic：
-
LabelSelector用字符串（如"app in (web,api)"）比labels.Selector更稳妥，后者需手动 Parse，出错不报明确错误 -
Limit和Continue必须配合使用：首次请求设Limit=500，后续用上一次响应的metadata.continue值填入Continue字段，否则分页失效 -
TimeoutSeconds不建议设超过 30，Kubernetes 默认 apiserver 请求超时是 60s，但 client-go 的 http.Transport 默认 idle timeout 是 30s，容易提前断连
真正麻烦的从来不是“能不能查到”，而是“查到的数据是不是此刻真实的”。Status 字段不可信、CRD GVR 易拼错、分页参数易遗漏——这些细节不盯住，工具跑得再快也等于白搭。
