记录一次K8S跨命名空间访问 xxx.xxx.svc.cluster.local 类似内部服务不通的问题
搭建K8S集群后，发现一个自带的mysql服务无法连通，经过排查发现使用的mysql的服务域名为：mysql.common.svc.cluster.local，很标准的内部服务域名，即common空间的名为mysql的服务，但是始终不通，错误为unkown host，也就是域名无法解析，调用者的pod在另一个namespace下，一开始以为服务端口不通，后来在另一个与mysql同在common空间下的pod里验证通过没问题，直接排除服务自身问题，推测为跨空间访问问题，网络查了很多，主要两个结论：
结论1是跨空间权限问题或者，但是xxx.xxx.svc.cluster.local这种标准内部访问除非设置了跨空间限制，否则不可能跟权限有关；
结论2是coredns的问题，毕竟域名解析不成功，但是经过使用nslookup在使用者pod内验证域名，发现域名解析正确，能够成功给出服务的内部ip，并且使用解析出的ip可以成功访问对应服务端口。
猜测与pod有关，但是同样的情况在其他集群并没出现
经过后续排查，发现问题，在问题再使用者pod内部的/etc/resolv.conf里面，如下
nameserver 10.96.0.10
search app.svc.cluster.local svc.cluster.local cluster.local
options ndots:5问题就是这句：options ndots:5，这段配置的意思的是当域名里 “.” 点这个符号的数量小于ndots后面的数字时，会优先将域名跟search后面的这些域名拼装组合后解析，当都解析失败了，才解析原始域名，比如使用的mysql.common.svc.cluster.local，里面正好有4个点，但是某些环境下，处理的细节有差异，当都解析失败的时候可能不在解析原始域名了，这就造成了上面的错误，但上面的情况在同空间下，第一个是common.svc.cluster.local，正好可以与解析的域名匹配，就解析成功了。最后造成了跨空间访问失败的现象。
因为options ndots:5这句话是k8s自动写入的，关于解决方案，网上找的一些：
1.修改k8s的coredns的配置文件，把ndots数量强制调整为5个以下
2.在app的配置里把pod创建时的dnsconfig做调整，修改ndots的数量
3.当然还有个更简单的，就是补一个点，mysql.common.svc.cluster.local改为 mysql.common.svc.cluster.local.
可以根据情况修改，如果是新集群可以考虑研究下改coredns，新写的yaml可以考虑加dnsconfig，实在觉着复杂，就用第三种