Service DNS解析失败主因是Service配置错误而非DNS本身，需检查selector匹配、targetPort端口、Headless Service误用；外部访问应优先Ingress+TLS终止；集群外Go客户端须显式加载kubeconfig或service account；环境感知推荐DNS探测kubernetes.default.svc.cluster.local。
Service DNS 名在集群内访问时为什么解析不到？
集群内 Pod 访问 my-service.default.svc.cluster.local 失败，大概率不是 DNS 配置问题，而是 Service 类型或端口映射没对上。
- 确认
Service的spec.selector确实匹配了后端 Pod 的 label（常见漏掉app: my-app这类键值） - 检查
Service的spec.ports[].targetPort是否指向容器实际监听的端口（比如 Go 程序监听8080，但写成了80） - 避免用
ClusterIP: None（Headless Service）却按普通 Service 方式解析——它只返回 Pod IP 列表，不提供 VIP - DNS 解析本身依赖
kube-dns或CoreDNS正常运行，可通过kubectl exec -it busybox -- nslookup my-service快速验证
Go 应用如何安全地从集群外访问集群内服务？
直接暴露 NodePort 或 LoadBalancer 给外部调用 Go 服务，容易绕过身份校验和流量治理。更可控的做法是走 Ingress + TLS 终止，再由 Ingress 控制器转发到 ClusterIP Service。
- Go HTTP 服务不要自己处理 HTTPS；让
nginx-ingress或istio-ingressgateway负责证书卸载 - 若必须用 NodePort，请限制
nodePort范围（如30000-32767），并配合 NetworkPolicy 禁止非白名单节点访问该端口 - Ingress 的
spec.rules[].http.paths[].backend.service.name必须与 Service 名完全一致（区分大小写），且命名空间默认为 Ingress 所在 namespace - Go 程序里硬编码
http://my-service:8080是反模式；应通过环境变量传入 base URL，方便内外网切换
Go 客户端在集群外调用集群内服务时，如何复用 kubeconfig 或 service account？
集群外的 Go 程序无法直接用 rest.InClusterConfig()，必须显式加载 kubeconfig 或构造 REST config。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先使用
rest.InClusterConfig()的替代方案：clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig")，注意路径需挂载进容器或本地可读 - 若用 service account token（如从 CI 环境调用），需手动构造
rest.Config：设置Host为 API server 地址、BearerToken为 token 内容、TLSClientConfig.Insecure设为false并填入 CA 证书 - Go 的
net/http默认不读取系统 CA，K8s API 调用务必传入rest.TLSClientConfig{CAData: caBytes}，否则报错x509: certificate signed by unknown authority - 别把
~/.kube/config直接塞进生产镜像；token 和证书应通过 Secret 挂载，避免硬编码或泄露
双向访问链路中，Go 应用如何感知当前运行环境（集群内 or 集群外）？
靠判断环境变量是否含 KUBERNETES_SERVICE_HOST 最轻量，但不够健壮；推荐结合 DNS 可达性做运行时探测。
立即学习“go语言免费学习笔记（深入）”；
- 启动时尝试解析
kubernetes.default.svc.cluster.local：能成功就认为在集群内，走ClusterIP；失败则 fallback 到外部域名或配置项 - 不要依赖
os.Getenv("POD_NAME")这类字段做判断——它们可能被用户手动注入，不可信 - 若用 Istio，可通过
istio-proxy注入的ISTIO_META_CLUSTER_ID辅助识别，但需确保 sidecar 已启用 - 环境感知逻辑建议封装成一个
IsInCluster()函数，在main()初始化阶段调用一次，避免每次请求都查 DNS
真正的难点不在配置怎么写，而在网络策略、证书信任链、DNS 缓存这三者叠加时的调试顺序——先确认 DNS 解析通不通，再看 TLS 握手有没有被拦截，最后才查策略放行没放行。这三个环节任何一层卡住，现象都可能是“连接超时”，但原因天差地别。
