背景：

首先是由于集群内同一namespace下的网关服务kong无法正常运行（ClusterIp），而Nodeport模式的konga能正常通过浏览器访问，看kong的日志报连接被拒绝的错误。

排查过程：

然后进入容器测试发现k8s集群的pod之间无法正常通过svc name访问，但通过ip可以访问。说明集群之间的服务发现有问题，此时查看kube-system命名空间下的coredns的pod，果然是coredns没有正常启动。
但此时查看coredns的日志和describe它也没有获得有效的信息，还是没有找到它不能正常启动的原因，然后转化思路，既然coredns也是节点上的容器，那节点的kubelet就应该负责管理控制，于是在node节点上看kubelet容器的日志，果真发现了明显的报错，报无法连接集群的api-server。

然后果断在该pod所在节点的宿主机上测试该ip的连通性和端口是否开放，发现宿主机上测试时通的；

然后进行容器的测试，此时犯了个错误，我选择了特殊容器kube-route容器来进行的测试，发现也是通的，但我在部署的engage服务的pod里测试，却是不通的。这一下就完全没有任何思路了，同一个宿主机上的不同容器之间的网络规则居然不同。在这里浪费了很多时间，最后在别人的提醒下，kube-route作为集群网络插件，它本身是不走集群网络的，是走的本地主机，这就导致测试时得到的奇怪结果。

解决：

此时结果基本上出来了，宿主机可以，容器不可以，于是到master上排查iptables规则，果然发现有对docker所设的Drop规则，直接执行iptables -P INPUT ACCEPT将INPUT链上的规则设为接受，此时问题解决，coredns服务起来，服务发现好了，kong的奇怪报错也没了。