Kind启动失败主因是Docker未运行、cgroup v2不兼容或磁盘不足；Go微服务需用NodePort+localhost访问；频繁删建集群需规范命名与清理上下文；client-go测试须用kind get kubeconfig构造配置。
Kind 启动集群失败：kind create cluster 卡住或报错
根本原因通常是 Docker 服务未运行、cgroup v2 不兼容，或本地磁盘空间不足。Kind 本质是用 Docker 容器模拟 K8s 节点，它不抽象底层依赖——Docker 崩了，Kind 就起不来。
- 先执行
docker info确认 Docker 正常且Cgroup Version是 v1；若为 v2（常见于新版 Ubuntu/Arch），需在 GRUB 中加systemd.unified_cgroup_hierarchy=0并重启 - 检查
docker system df -v，镜像+构建缓存超 20GB 时，kind create cluster可能因磁盘 I/O 阻塞；建议清理：docker system prune -a --volumes - 默认使用最新版 Kubernetes 镜像，但 Kind v0.20+ 对 k8s v1.29+ 有已知挂载问题；稳妥起见显式指定：
kind create cluster --image kindest/node:v1.28.0
Go 微服务连不上本地 Kind 集群的 Service
不是代码写错了，而是 Go 进程默认跑在宿主机网络里，而 Kind 的 ClusterIP 只在集群内部可达。想让本地 Go 程序调用 Service，必须绕过 ClusterIP，走 NodePort 或 hostPort。
- Service 类型必须设为
NodePort，且在 Kind 配置中开放对应端口（默认只开 80/443）：kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane extraPortMappings: - containerPort: 30080 hostPort: 30080 protocol: TCP - Go 代码里别用
http://myservice.default.svc.cluster.local:8080——这 DNS 根本解析不了；改用http://localhost:30080 - 如果服务用了 gRPC，注意
NodePort会强制走 TCP，且需在客户端配置WithBlock()和合理超时，否则容易卡在连接建立阶段
频繁删建 Kind 集群导致 kubectl 上下文混乱
每次 kind create cluster 都会向 $HOME/.kube/config 写入新 context，但不会自动清理旧的。久而久之 kubectl get nodes 报 connection refused 就是因为当前 context 指向一个已被删掉的集群。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 创建时加
--name myapp-dev，后续删集群用kind delete cluster --name myapp-dev，避免误删其他环境 - 切换上下文别靠记忆：
kubectl config use-context kind-myapp-dev；查当前上下文：kubectl config current-context - 清理僵尸 context：
kubectl config delete-context kind-old-cluster+kubectl config delete-cluster kind-old-cluster+kubectl config unset users.kind-old-cluster
Go 测试中调用 client-go 操作 Kind 集群总超时
本地测试里用 rest.InClusterConfig() 肯定失败——那玩意儿只在 Pod 里有效。必须手动构造 config，且关键点在于：不能直接用 ~/.kube/config 的证书路径，因为 Kind 生成的证书绑定的是容器内网 IP（如 172.18.0.2），宿主机访问不了。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是用
kind get kubeconfig --name myapp-dev输出并解析，它返回的是带localhost地址和自签名 CA 的 config - 加载时必须显式设置
rest.Config.Burst和QPS（比如QPS: 10, Burst: 20），否则并发测试时 client-go 限流太狠 - CA 证书不能跳过校验：
rest.InsecureSkipTLSVerify: false，然后把config.CAData传给rest.AnonymousClientConfig()——跳过会导致 401
Kind 不是黑盒，它只是把 K8s 节点塞进 Docker 容器；所有网络、证书、权限问题，都得按真实集群逻辑去查，只是调试时你得清楚自己站在哪一边：宿主机？容器内？还是 Pod 里？
