Почему Kubernetes возвращает странные результаты для ioctl - PullRequest
0 голосов
/ 01 ноября 2019

У меня есть устаревшее приложение, которое я запускаю в модуле в Kubernetes, развернутом с помощью kubeadm. ЦНИ фланелевый. Код вызывает ioctl с SIOCGIFBRDADDR, чтобы получить широковещательный адрес интерфейса контейнера. В ванильном Docker возвращается правильный широковещательный запрос. В Kubernetes это неправильно возвращает 0.0.0.0. Прямая строка показывает вызов из модуля Kubernetes ниже:

ioctl (4, SIOCGIFBRDADDR, {ifr_name = "eth0", ifr_broadaddr = {AF_INET, inet_addr ("0.0.0.0")}}) =0

Я ожидал широковещательную рассылку, рассчитанную из / 24, назначенного модулям, работающим на рабочем узле, т.е. 10.244.2.255 для IP-адреса модуля 10.244.2.70/24

SIOCGIFCONF возвращает адрес интерфейса правильно:

ioctl (4, SIOCGIFCONF, {100 * sizeof (struct ifreq) => 2 * sizeof (struct ifreq), [{ifr_name = "lo ", ifr_addr = {AF_INET, inet_addr (" 127.0.0.1 ")}}, {ifr_name =" eth0 ", ifr_addr = {AF_INET, inet_addr (" 10.244.2.70 ")}}]}) = 0

Есть ли причина, по которой широковещательный адрес не работает?

Обновление: В качестве тестового примера я скомпилировал описанный здесь код, который просто вызывает ioctl, как описано выше,https://gist.github.com/loderunner/ec7d4725daca39283606#file-getbroadaddr-c

При запуске двоичного файла в моем pod centos: 7 он дает результат:

sh-4.2$ ./getaddrs
Listing all interfaces:
lo
eth0
sh-4.2$ ./getaddrs eth0
eth0                    0.0.0.0
sh-4.2$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
3: eth0@if43: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 8950 qdisc noqueue
    link/ether 3e:b4:05:db:cf:41 brd ff:ff:ff:ff:ff:ff
    inet 10.244.4.7/24 scope global eth0
        valid_lft forever preferred_lft forever
    inet6 fe80::3cb4:5ff:fedb:cf41/64 scope link
        valid_lft forever preferred_lft forever

Это иллюстрирует проблему. Результат из ./getaddr eth0 должен быть 10.244.4.255, а не 0.0.0.0

1 Ответ

0 голосов
/ 15 ноября 2019

Кажется, это причуда фланели. При использовании weave-net возвращается правильная трансляция.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...