Responses from kubernetes containers getting lost

无人久伴 提交于 2019-12-10 23:41:55

问题


I have installed kubernetes on openstack. The setup has one master and one node on coreos.

I have a pod hosting an SIP application on UDP port 5060 and I have created service as NODEPORT on 5060.

The spec:

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

IPs

  • Public IP of node: 192.168.144.29.
  • Private IP of node: 10.0.1.215..
  • IP of the container:10.244.2.4.
  • docker0 interface: 10.244.2.1.

Now, the problem. I send a SIP request to the application and expect a 200 OK response, which I am not getting.

To trace the same, I installed TCPDUMP on the container and the node. On the container, I can see the request and response packet captured while on the node itself I just see the request packet. Don't understand why the packet is getting lost.

Below is tcpdump of container:

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

And tcpdump of node:

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" />

Nodeport rules from Iptable

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

I am happy to share more info if required. I have tried to dig in my capacity, but now I don't know what to look therefore requesting some help here.

EDIT

I did the same test on TCP. On TCP, it works as expected.

Thanks


回答1:


5060 is outside the default Service Node Port Range: http://kubernetes.github.io/docs/user-guide/services/#type-nodeport

Creation of the service should have failed.

You can try a different port, or create a cluster using a different range, by specifying --service-node-port-range on kube-apiserver.

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

You should also check whether the response can be seen from other nodes. There are issues with "hairpin mode" when communicating within the same node.

Also, when reporting problems, please specify the Kubernetes release.



来源:https://stackoverflow.com/questions/34368093/responses-from-kubernetes-containers-getting-lost

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!