节点亲和性是pod调度的关键开关，配置错误会导致pending；需检查标签是否存在且精确匹配、operator与值类型一致、旧pod是否占资源；go应用应优先用preferred而非required，避免硬亲和导致停摆。
Go 应用在 Kubernetes 中部署时，节点亲和性（nodeAffinity）不是“可有可无的加分项”，而是决定 Pod 能否调度到目标节点的关键开关。配置错一个字段，Pod 就卡在 Pending 状态，连日志都看不到。
nodeAffinity 配置后 Pod 一直 Pending？先查这三件事
硬亲和（requiredDuringSchedulingIgnoredDuringExecution）失效最常见表现就是 Pod 卡住不动。这不是 Go 应用的问题，而是调度器根本找不到匹配的节点。
- 用
kubectl get nodes --show-labels确认集群里真有你写的 label，比如zone=us-west-2a—— 不是“应该有”，是必须存在且拼写、大小写、值完全一致 -
matchExpressions中的operator必须和 label 值类型匹配：In对应字符串列表，Gt/Lt只能用于数字字符串（如"32"），不能对beta.kubernetes.io/arch=amd64用Gt - Deployment 更新后，旧 Pod 还占着节点资源，新副本可能因资源不足被拒；删掉旧 ReplicaSet 或直接
kubectl delete pod -l app=go-app强制触发重建
required 还是 preferred？Go 服务上线初期别碰 required
Go 应用启动快、内存占用低，但对节点标签容错率极低。硬亲和要求所有条件同时满足，一旦某节点漏打 disk-type=ssd 标签，或资源刚好差 100m CPU，整个 Deployment 就停摆。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 新版本上线、灰度发布、测试环境优先用
preferredDuringSchedulingIgnoredDuringExecution，靠weight控制倾向强度（1–100，只取最高分那条生效） - 只有 etcd 成员、ZooKeeper 集群这类强状态组件，才值得用
required；且必须保证节点数 ≥ 副本数，并统一打齐topology.kubernetes.io/zone等拓扑标签 - 软亲和下即使没匹配到，Pod 仍能调度成功——你看到的是“尽量避开”，不是“禁止”
Go 应用代码里要不要自己判断节点？完全没必要
Kubernetes 的 nodeAffinity 已经在调度层完成决策，Go 进程启动时，它所在的节点早已确定。应用层再查 spec.nodeName 或调 API Server 做二次筛选，纯属重复劳动，还引入权限、网络、竞态风险。
- 真需要感知拓扑（比如跨 AZ 写日志），用 Downward API 注入：
fieldRef: fieldPath: spec.nodeName或environment: valueFrom: fieldRef: fieldPath: metadata.labels - 不要在
main()里写clientset.CoreV1().Nodes().Get(...)—— 权限难配、延迟高、失败无回退 - 镜像构建阶段就该定死行为：多阶段构建 +
-ldflags="-s -w"减小体积，比运行时动态适配节点靠谱十倍
节点亲和性的真正复杂点不在 YAML 写法，而在标签生命周期管理：谁负责打标？节点扩容时是否自动同步？label 键名变更后存量 Pod 是否要滚动重启？这些比 matchExpressions 多写两行更易出问题。
