这是我的集群环境:
service cluster ip cidr:10.254.0.0/16
pod ip cidr: 172.30.0.0/16
kube-proxy: ipvs mode
flannel : vxlan
kubectl版本
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.4", GitCommit:"5ca598b4ba5abb89bb773071ce452e33fb66339d", GitTreeState:"clean", BuildDate:"2018-06-06T08:13:03Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.4", GitCommit:"5ca598b4ba5abb89bb773071ce452e33fb66339d", GitTreeState:"clean", BuildDate:"2018-06-06T08:00:59Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
我预期的结果:
我可以从kubernetes主服务器正常访问SVC IP。
在主主机上，我已经部署了kube-proxy和法兰绒。
我的kubernetes集群的所有组件都是通过发行版二进制文件部署的。
我已经正常部署了群集，并且在大多数情况下，它可以在外部提供服务。
我已经部署了一个nginx服务器，我的截图:
nginx server
Service IP: 10.254.126.228
Pod IP: 172.30.21.3
当我直接在kubernetes主主机上访问Pod IP(172.30.21.3)时，可以正常访问它。
我的截图:
http request
但是，当我访问服务IP时，会发生访问超时。
我的截图:
Access SVC IP time out
仅当在容器外部的主机上请求SVC IP时，才会发生这种情况。如果我在容器中，则可以正常访问SVC IP。
我的截图:
in the container http request
这是我的ipvs规则列表:
ipvs rule list
我使用tcpdump监听了nginx Pod节点主机上的flannel.1 NIC和docker0 NIC，发现了以下问题:
当我直接在kubernetes主主机上访问Pod IP时，我的主主机上的法兰NIC会将数据包发送到节点主机法兰NIC，然后将其转发到docker0 NIC，最后转发到Pod IP。同时，pod IP将响应我的请求，一切正常。
但是当我在kubernetes主主机上访问SVC IP时，我发现发送数据包的NIC更改为eth0而不是使用法兰绒NIC，因此节点主机上的法兰绒NIC直接丢弃了请求，并且没有继续转发到docker0。
我意识到这可能是基于策略的路由的问题。如果我将目标为10.254的请求转发到正确的网关，是否可以解决此问题？
但这应该有一个更标准的解决方案。谁能帮我？
(对不起，我的英语不太好...)
最佳答案
看来您的svc CIDR与主机CIDR有交集
关于kubernetes - 在kubernetes集群中，主机无法访问SVC IP，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/52510592/