0

我已经部署了几个不同的服务并且总是得到同样的错误。

可以从运行 pod 的机器的节点端口访问该服务。在其他两个节点上，我得到了超时。

kube-proxy 在所有工作节点上运行，我可以在 kube-proxy 的日志文件中看到添加了服务端口并打开了节点端口。在这种情况下，我部署了来自 calico 的 stars 演示

Kube-proxy 日志输出：

Mar 11 10:25:10 kuben1 kube-proxy[659]: I0311 10:25:10.229458     659 service.go:309] Adding new service port "management-ui/management-ui:" at 10.32.0.133:9001/TCP
Mar 11 10:25:10 kuben1 kube-proxy[659]: I0311 10:25:10.257483     659 proxier.go:1427] Opened local port "nodePort for management-ui/management-ui:" (:30002/tcp)

kube-proxy 正在监听 30002 端口

root@kuben1:/tmp# netstat -lanp | grep 30002
tcp6       0      0 :::30002                :::*                    LISTEN      659/kube-proxy

还定义了一些 iptable 规则：

root@kuben1:/tmp# iptables -L -t nat | grep management-ui
KUBE-MARK-MASQ  tcp  --  anywhere             anywhere             /* management-ui/management-ui: */ tcp dpt:30002
KUBE-SVC-MIYW5L3VT4JVLCIZ  tcp  --  anywhere             anywhere             /* management-ui/management-ui: */ tcp dpt:30002
KUBE-MARK-MASQ  tcp  -- !10.200.0.0/16        10.32.0.133          /* management-ui/management-ui: cluster IP */ tcp dpt:9001
KUBE-SVC-MIYW5L3VT4JVLCIZ  tcp  --  anywhere             10.32.0.133          /* management-ui/management-ui: cluster IP */ tcp dpt:9001

有趣的部分是我可以从任何工作节点访问服务 IP

root@kubem1:/tmp# kubectl get svc -n management-ui
NAME            TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
management-ui   NodePort   10.32.0.133   <none>        9001:30002/TCP   52m

如果我执行“curl http://10.32.0.133:9001 ” ，则可以从任何工作节点访问服务 IP/端口

我不明白为什么 kube-proxy 不能正确“路由”这个......
有没有人暗示我可以在哪里找到错误？

这里有一些集群规格：

这是一个手工构建集群，灵感来自 Kelsey Hightower 的“kubernetes the hard way”指南。

  • 6 个节点（3 个主节点：3 个工作节点）本地虚拟机
  • 操作系统：Ubuntu 18.04
  • K8s：v1.13.0
  • 码头工人：18.9.3
  • Cni: 印花布

主节点上的组件状态看起来不错

root@kubem1:/tmp# kubectl get componentstatus
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-0               Healthy   {"health":"true"}   
etcd-1               Healthy   {"health":"true"}   
etcd-2               Healthy   {"health":"true"}

如果我信任 kubectl，工作节点看起来还不错

root@kubem1:/tmp# kubectl get nodes -o wide
NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
kuben1   Ready    <none>   39d   v1.13.0   192.168.178.77   <none>        Ubuntu 18.04.2 LTS   4.15.0-46-generic   docker://18.9.3
kuben2   Ready    <none>   39d   v1.13.0   192.168.178.78   <none>        Ubuntu 18.04.2 LTS   4.15.0-46-generic   docker://18.9.3
kuben3   Ready    <none>   39d   v1.13.0   192.168.178.79   <none>        Ubuntu 18.04.2 LTS   4.15.0-46-generic   docker://18.9.3

正如 P Ekambaram 所问：

root@kubem1:/tmp# kubectl get po -n kube-system
NAME                                   READY   STATUS    RESTARTS   AGE
calico-node-bgjdg                      1/1     Running   5          40d
calico-node-nwkqw                      1/1     Running   5          40d
calico-node-vrwn4                      1/1     Running   5          40d
coredns-69cbb76ff8-fpssw               1/1     Running   5          40d
coredns-69cbb76ff8-tm6r8               1/1     Running   5          40d
kubernetes-dashboard-57df4db6b-2xrmb   1/1     Running   5          40d
4

1 回答 1

2

我已经为我的“问题”找到了解决方案。
此行为是由 Docker v1.13.x 中的更改引起的，该问题已在 1.8 版的 kubernetes 中得到修复。

简单的解决方案是通过 iptables 更改转发规则。
在所有工作节点上运行以下 cmd：“iptables -A FORWARD -j ACCEPT”

为了以正确的方式修复它，我必须告诉 kube-proxy pod 的 cidr。理论上可以通过两种方式解决：

  • 添加“--cluster-cidr=10.0.0.0/16”作为kube-proxy命令行的参数（在我的例子中是systemd服务文件）
  • 将 'clusterCIDR: "10.0.0.0/16"' 添加到 kube-proxy 的 kubeconfig 文件中

在我的情况下， cmd 行参数没有任何效果。
当我将该行添加到我的 kubeconfig 文件并在所有工作节点上重新启动 kube-proxy 时，一切正常。

这是此“FORWARD”问题的 github 合并请求：链接

于 2019-03-11T16:36:09.213 回答