Ответы от контейнеров kubernetes теряются

Я установил кубернеты на openstack. В установке есть один мастер и один узел на ядрах.

У меня есть модуль, на котором размещено приложение SIP на UDP-порту 5060, и я создал службу как NODEPORT на 5060.

Спецификация:

"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:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.144.10:5060;branch=z9hG4bK-5672-1-0
        Max-Forwards: 20
        From: service <sip:[email protected]>;tag=1
        To: sut <sip:[email protected]>
        Call-ID: [email protected]
        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:[email protected]>;tag=1
        To: sut <sip:[email protected]>;tag=332ff20b76febdd3c55f313f3efc6bb8-ca08
        Call-ID: [email protected]
        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:[email protected]>;tag=1
        To: sut <sip:[email protected]>;tag=332ff20b76febdd3c55f313f3efc6bb8-ca08
        Call-ID: [email protected]
        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:[email protected] SIP/2.0
        Via: SIP/2.0/UDP 192.168.144.10:5060;branch=z9hG4bK-5672-1-0
        Max-Forwards: 20
        From: service <sip:[email protected]>;tag=1
        To: sut <sip:[email protected]>
        Call-ID: [email protected]
        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 от 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

Я рад поделиться дополнительной информацией, если потребуется. Я пытался копать в своих силах, но теперь я не знаю, что искать, поэтому прошу здесь некоторую помощь.

РЕДАКТИРОВАТЬ

Я проделал тот же тест на TCP. По TCP работает как положено.

Спасибо


kubernetes docker flannel coreos
person user3275095    schedule 19.12.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

5060 находится за пределами диапазона портов узла службы по умолчанию: http://kubernetes.github.io/docs/user-guide/services/#type-nodeport

Создание службы должно было закончиться неудачей.

Вы можете попробовать другой порт или создать кластер с использованием другого диапазона, указав --service-node-port-range в kube-apiserver.

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

Вы также должны проверить, можно ли увидеть ответ от других узлов. Есть проблемы с "режимом шпильки" при обмене данными внутри одного узла.

Также, сообщая о проблемах, указывайте выпуск Kubernetes.

person briangrant    schedule 09.03.2016
comment
Я создал кластер, используя настраиваемый диапазон узлов и портов, поэтому создание службы не удалось. При более глубоком расследовании я обнаружил, что проблема была в развернутом приложении. - person user3275095; 09.03.2016