k3s集群内同命名空间下无法通过服务名访问Service如何排查？

IP可以正常访问说明Service本身的转发规则、后端Endpoint绑定均无异常，服务名访问失败为集群DNS解析链路故障导致，k3s环境下常见故障点如下：

• CoreDNS服务运行异常
  k3s默认使用CoreDNS提供集群内部服务发现能力，执行kubectl get pods -n kube-system -l k8s-app=kube-dns检查CoreDNS Pod状态，确保所有Pod处于Running状态且无频繁重启。如果Pod异常，可通过kubectl logs -n kube-system <coredns-pod-name>查看日志排查配置错误、资源不足等问题。
• 访问源Pod的DNS配置异常
  进入发起请求的Pod中执行cat /etc/resolv.conf，确认nameserver指向集群DNS服务的ClusterIP（k3s默认是10.43.0.10），search域包含*.svc.cluster.local以及当前命名空间的搜索后缀。如果配置不符合要求，检查Pod的dnsPolicy字段，不要设置为Default或None，保持默认的ClusterFirst即可。
• 集群网络连通性故障
  若CoreDNS运行正常，验证访问源Pod到CoreDNS Pod的网络连通性：在源Pod中执行ping <coredns-pod-ip>，如果无法连通，排查k3s的CNI插件故障，常见原因包括flannel网络配置错误、节点防火墙拦截了CNI网段流量、节点之间VXLAN端口（默认8472）被禁。
• 命名空间不匹配
  确认发起请求的Pod和amen-sc Service处于同一命名空间，跨命名空间访问时需要使用完整服务名：amen-sc.<目标命名空间>.svc.cluster.local:3030。

配置有效性说明 #

你提交的Service配置本身符合需求：默认类型为ClusterIP，仅对集群内部暴露，只要修复上述DNS相关故障，即可直接通过服务名:端口的格式在同命名空间下正常访问。修复后可先执行nslookup amen-sc验证解析结果是否为对应Service的ClusterIP，再执行访问操作即可。

内容的提问来源于stack exchange，提问作者Anurag Vohra