kubernetes容器的反应迷路了

我已经在openstack上安装了kubernetes。 该设置在coreos上有一个主节点和一个节点。

我有一个托pipe在UDP端口5060上的SIP应用程序的吊舱,并且我已经在5060上创build了服务NODEPORT

规格:

"spec": { "ports": [ { "port": 5061, "protocol": "UDP", "targetPort": 5060, "nodeport": 5060, "name": "sipu" } ], "selector": { "app": "opensips" }, "type": "NodePort" } 

IP地址

  • 公共IP的节点: 192.168.144.29
  • 节点的私有IP: 10.0.1.215。
  • 容器的IP: 10.244.2.4
  • docker0接口: 10.244.2.1

现在,这个问题。 我发送一个SIP请求到应用程序,并期望200 OK响应,我没有得到。

跟踪相同,我在容器和节点上安装了TCPDUMP。 在容器上,我可以看到在节点本身捕获的请求和响应数据包,我只是看到请求数据包。 不明白为什么包丢失。

下面是容器的tcpdump:

 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes 06:12:20.391171 IP (tos 0x0, ttl 64, id 13372, offset 0, flags [DF], proto UDP (17), length 1010) 10.244.2.1.50867 > 10.244.2.4.5060: [bad udp cksum 0x1ddc -> 0xe738!] SIP, length: 982 PUBLISH sip:service-1@opensipstest.org SIP/2.0 Via: SIP/2.0/UDP 192.168.144.10:5060;branch=z9hG4bK-5672-1-0 Max-Forwards: 20 From: service <sip:service-1@opensipstest.org>;tag=1 To: sut <sip:service-1@opensipstest.org> Call-ID: 1-5672@192.168.144.10 CSeq: 1 PUBLISH Expires: 3600 Event: presence Content-Length: 607 User-Agent: Sipp v1.1-TLS, version 20061124 <?xml version="1.0"?> <deleted presence xml to reduce size> 06:12:20.401126 IP (tos 0x10, ttl 64, id 11888, offset 0, flags [DF], proto UDP (17), length 427) 10.244.2.4.5060 > 10.244.2.1.5060: [bad udp cksum 0x1b95 -> 0xeddc!] SIP, length: 399 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.144.10:5060;received=10.244.2.1;branch=z9hG4bK-5672-1-0 From: service <sip:service-1@opensipstest.org>;tag=1 To: sut <sip:service-1@opensipstest.org>;tag=332ff20b76febdd3c55f313f3efc6bb8-ca08 Call-ID: 1-5672@192.168.144.10 CSeq: 1 PUBLISH Expires: 3600 SIP-ETag: a.1450478491.39.2.0 Server: OpenSIPS (1.8.4-notls (x86_64/linux)) Content-Length: 0 06:12:20.401364 IP (tos 0x0, ttl 64, id 13374, offset 0, flags [DF], proto UDP (17), length 427) 10.244.2.1.58836 > 10.244.2.4.5060: [bad udp cksum 0x1b95 -> 0x1bcc!] SIP, length: 399 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.144.10:5060;received=10.244.2.1;branch=z9hG4bK-5672-1-0 From: service <sip:service-1@opensipstest.org>;tag=1 To: sut <sip:service-1@opensipstest.org>;tag=332ff20b76febdd3c55f313f3efc6bb8-ca08 Call-ID: 1-5672@192.168.144.10 CSeq: 1 PUBLISH Expires: 3600 SIP-ETag: a.1450478491.39.2.0 Server: OpenSIPS (1.8.4-notls (x86_64/linux)) Content-Length: 0 

和tcpdump的节点:

 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes 06:12:20.390772 IP (tos 0x0, ttl 127, id 20196, offset 0, flags [none], proto UDP (17), length 1010) 192.168.144.10.5060 > 10.0.1.215.5060: [udp sum ok] SIP, length: 982 PUBLISH sip:service-1@opensipstest.org SIP/2.0 Via: SIP/2.0/UDP 192.168.144.10:5060;branch=z9hG4bK-5672-1-0 Max-Forwards: 20 From: service <sip:service-1@opensipstest.org>;tag=1 To: sut <sip:service-1@opensipstest.org> Call-ID: 1-5672@192.168.144.10 CSeq: 1 PUBLISH Expires: 3600 Event: presence Content-Length: 607 User-Agent: Sipp v1.1-TLS, version 20061124 <?xml version="1.0"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" /> 

来自Iptable的Nodeport规则

 Chain KUBE-NODEPORT-CONTAINER (1 references) pkts bytes target prot opt in out source destination 12 8622 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/opensips:sipu */ udp dpt:5060 redir ports 40482 3 95 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-udp-service: */ udp dpt:6000 redir ports 47497 Chain KUBE-NODEPORT-HOST (1 references) pkts bytes target prot opt in out source destination 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/opensips:sipu */ udp dpt:5060 to:10.0.1.215:40482 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-udp-service: */ udp dpt:6000 to:10.0.1.215:47497 

我很高兴分享更多的信息,如果需要的话。 我试图挖掘我的能力,但现在我不知道该看什么,因此在这里请求一些帮助。

编辑

我在TCP上做了相同的testing。 在TCP上,它按预期工作。

谢谢

5060在默认的服务节点端口范围之外: http : //kubernetes.github.io/docs/user-guide/services/#type-nodeport

服务的创build应该失败了。

您可以尝试使用不同的端口,也可以使用不同的范围创build群集,方法是在kube-apiserver上指定–service-node-port-range。

https://github.com/kubernetes/kubernetes/blob/43792754d89feb80edd846ba3b40297f2a105e14/cmd/kube-apiserver/app/options/options.go#L232

您还应该检查是否可以从其他节点看到响应。 在同一节点内进行通信时,存在“发夹模式”的问题。

此外,在报告问题时,请指定Kubernetes版本。