最直接方式是用clientset.CoreV1().Nodes().List(ctx, metav1.ListOptions{Limit: 500})获取全量节点，遍历每个node.Status.Conditions查找Type=="Ready"的项，判断其Status是否为"True"且Reason非KubeletNotReady等故障态，并检查LastHeartbeatTime时效性，所有API调用必须带context.WithTimeout防止goroutine卡死。
用 client-go 调 nodes API 获取节点状态最直接
Go 服务要读 Kubernetes 集群的节点健康状态，本质是调 /api/v1/nodes 接口，解析每个 Node 对象的 Conditions 字段。这不是靠本地进程探测，而是走 K8s API Server 的权威视图。client-go 是官方推荐且唯一稳定的方式，别手写 http.Client 去拼 URL 和 token。
关键点：节点“健康”在 K8s 里没有布尔值定义，得看 Ready condition 的 Status 是否为 True，同时 Reason 不是 KubeletNotReady 或 NetworkPluginNotReady 等已知故障态。
- 必须用
clientset.CoreV1().Nodes().List(ctx, opts)，不能用Get单个节点——你通常需要全量巡检 -
opts := metav1.ListOptions{Limit: 500}必须设Limit，大集群不设会 OOM - 每个
node.Status.Conditions是 slice，需遍历找Type == "Ready"的项，再判断其Status和LastHeartbeatTime - 别忽略
node.Status.Allocatable和node.Status.Capacity——资源耗尽（如memoryallocatable ≈ 0）也是事实上的不健康
context.WithTimeout 不加就卡死，不是可选项
线上最常见错误就是没给 API 调用套 context 超时，结果一次 etcd 网络抖动或 apiserver 限流，整个 goroutine 挂住，后续所有定时任务全阻塞。K8s API 默认无超时，client-go 也不会帮你兜底。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 每次 List/Get 前必须：
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second) - 调完立刻
cancel()，避免 goroutine 泄漏 - 别用全局
context.Background()直接传进 clientset 方法——它永远不会超时 - 如果巡检逻辑本身是 cron job，还要在外层再包一层更长的 timeout（比如 30 秒），留出重试和降级时间
别把 Unknown 当 False，节点状态有三态
节点 Condition 的 Status 是 "True"、"False" 或 "Unknown"。很多代码直接 if cond.Status != "True" 就标为不健康，这是错的。Unknown 表示 kubelet 失联（比如节点宕机、网络中断），此时应触发告警，但不能简单等同于 False 做自动摘除——你可能正处在网络分区中，误判会放大故障。
立即学习“go语言免费学习笔记（深入）”；
- 区分处理：
True→ 健康；False→ 明确故障（查Reason和Message）；Unknown→ 触发二次确认或告警，不参与自动决策 - 检查
LastHeartbeatTime与当前时间差，超过 40 秒未心跳基本可认为失联（kubelet 默认每 10 秒上报一次） - 对
Unknown状态，可额外发起一次net.DialContext直连节点 IP 的 kubelet 端口（如 10250），验证是否真断网
缓存节点状态，别每次 HTTP 请求都拉全量
如果你的服务每秒被调多次，或者自身是定时巡检器，频繁调 nodes List 接口会造成 apiserver 压力、限流甚至 429 错误。真实生产环境必须加本地缓存。
- 用
sync.RWMutex包裹一个 map[string]*corev1.Node，key 是node.Name - 后台用
time.Ticker每 30 秒刷新一次全量节点列表，更新缓存 - 对外提供
GetNodeStatus(name string) (status string, lastHeartbeat time.Time)这类只读接口，不触发新 HTTP 请求 - 缓存失效策略：单个节点连续两次
List都没出现，才从 map 中删除（防临时丢包）
Ready condition 只反映 kubelet 在线，不保证磁盘没满、网络插件没崩、CNI 配置没漂移。这些得结合 node.Status.Conditions 里的 DiskPressure、MemoryPressure、NetworkUnavailable 一起看，而且每个 condition 的 Status 更新时机不同，必须严格按 timestamp 判断时效性。 
