грешил на фланнел, пробовал откатывать flannel до 0.6.2 такая же картина, конфиг проверенный, на другом кластере работает норм, из отличий версия кореос

также заметил, что docker inspect для непингующихся контейнеров не показывает ип в NetworkSettings, хотя из контейнера ип видно и docker network inspect bridge их показывает

хотя последнее видимо совпадение, сейчас нашел нормальный непингующийся контейнер с ип в NetworkSettings, arp -a на такие ip пишет <incomplete> on docker0

хотя последнее видимо совпадение, сейчас нашел нормальный непингующийся контейнер с ип в NetworkSettings, arp -a на такие ip пишет <incomplete> on docker0

если у вас сеть через CNI , то с точки зрения докера это всё net=none

если у вас сеть через CNI , то с точки зрения докера это всё net=none

сеть flannel, что еще заметил разницу ip addr sh

13: veth893da0a@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default link/ether 12:f6:91:c5:71:80 brd ff:ff:ff:ff:ff:ff inet6 fe80::10f6:91ff:fec5:7180/64 scope link valid_lft forever preferred_lft forever 15: veth84e29ce@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue master docker0 state UP group default link/ether 7a:82:c3:e3:e9:32 brd ff:ff:ff:ff:ff:ff inet6 fe80::7882:c3ff:fee3:e932/64 scope link valid_lft forever preferred_lft forever

у тех что без сети нет master docker0

сеть flannel, что еще заметил разницу ip addr sh

flannel кажется по-разному может конфигурироваться. речь о том как kubelet настроен?использует CNI плагины?

нет, не использует чистый фланнел

фланнел сеть работает, я могу пинговать с одной машинки подсеть другой машины, тут скорее глюки докера, он не всегда добавляет к сети master docker0

вот еще dmesg инициализацию на disabled state

worker02 core # dmesg -T|grep veth4b0 [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered blocking state [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered disabled state [Sun Apr 30 02:58:36 2017] device veth4b02130 entered promiscuous mode [Sun Apr 30 02:58:36 2017] IPv6: ADDRCONF(NETDEV_UP): veth4b02130: link is not ready [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered blocking state [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered forwarding state [Sun Apr 30 02:58:36 2017] device veth4b02130 left promiscuous mode [Sun Apr 30 02:58:36 2017] docker0: port 4(veth4b02130) entered disabled state [Sun Apr 30 02:58:36 2017] IPv6: ADDRCONF(NETDEV_CHANGE): veth4b02130: link becomes ready worker02 core # dmesg -T|grep veth839 [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered blocking state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered disabled state [Sun Apr 30 02:58:49 2017] device veth839a387 entered promiscuous mode [Sun Apr 30 02:58:49 2017] IPv6: ADDRCONF(NETDEV_UP): veth839a387: link is not ready [Sun Apr 30 02:58:49 2017] IPv6: ADDRCONF(NETDEV_CHANGE): veth839a387: link becomes ready [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered blocking state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered forwarding state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered disabled state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered blocking state [Sun Apr 30 02:58:49 2017] docker0: port 10(veth839a387) entered forwarding state

виновником оказалась преднастройка от ovh - линк в /dev/null в /etc/udev/rules.d/80-net-setup-link.rules

крутая преднастройка 👍

господа, а кто как мапит исходники в контейнеры? на текущем шаге способы собирать что-то в дженкинсе и грузить напрямую из гита не подходят, интересуют альтернативные варианты

Я чет не понимаю при чем тут куб вообще

И какие альтернативы монут быть

почему не подходят?

чтобы что то собирать надо иметь все для сборки

а этот набор даже интерна админа доведет до инсульта

в проде ничего этого быть не должно никогда

и как вы это тестить будете?

или тут петонист пришёл, щас пипом все поставим ачотаково

кубернетис типа прод. там должен быть чистый протестеный бинарь и все

чём плох обычный подход с дженкинсом, кучей тестов и возможно стейджинг ом?

а стопицот плагинов для дженкинса и заточеный под него джава программист позволяет дженкинс использовать везде и для всего. даже воду в туалете смывать при желании.

а если кажется, что это не подходит, то в консерватории проблемы, кажется.

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

нет, конечно

ну а если исключить сборку контейнеров с исходниками и всем-всем-всем, то какие альтернативы?

Никаких нормальных

Это все напоминает проблему ХУ. Что мешает билдить образы?

Билдить и выкатывать куча вариантов, а вот делать в бою лайврелоад из примапленой директории, меняя код через самбу или sshfs - прямой путь в ад. Разрабатывать можно локально

Если появится проект на компилируемом языке, то там сразу ой всё

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

в кубе единица работы - это контейнер. контейнер неделим, и для куба нет разницы, завалился контейнер из-за недочетов сборки или ошибки синтаксиса в приложении

но в общем вся контейнерная философия пиравнивает приложение к образу

все это "работает локально - работатет в проде"

и ответственность все-таки обычно делят горизонтально, а здесь получается вертикально

в кубе единица работы - это контейнер. контейнер неделим, и для куба нет разницы, завалился контейнер из-за недочетов сборки или ошибки синтаксиса в приложении

Ты конечно же про pod в роли единицы неделимой а не docker container?

ладно, спасибо за советы) глупо идти против best practiсe, поэтому пока вместо понимания смирюсь)

интересно было бы послушать мнение @idvoretskyi как разработчика, так сказать, из первых уст

ладно, спасибо за советы) глупо идти против best practiсe, поэтому пока вместо понимания смирюсь)

Нельзя мириться. Сломай систему, наступи на грабли, а уже только потом смирись )

Нельзя мириться. Сломай систему, наступи на грабли, а уже только потом смирись )

бросьте вы, я уже вырос из этого)

Ты конечно же про pod в роли единицы неделимой а не docker container?

Про контейнер (

Тогда я наверно контекста не понял, сори

Все равно под состоит из контейнеров и "ой, завалилось" начнется с выхода контейнера

Так ладно прекращаю писать непонятное

Не факт что падение контейнера приведет к решедулингу или ещё каким реакциям

Повиснет в статусе completed и все ;(

Я про "падение" с кодом 0

интересно было бы послушать мнение @idvoretskyi как разработчика, так сказать, из первых уст

@zhukva я не разработчик

и вопроса я не понял (точнее какой из них)?

в кубе единица работы - это контейнер. контейнер неделим, и для куба нет разницы, завалился контейнер из-за недочетов сборки или ошибки синтаксиса в приложении

для Kubernetes атомарная единица - pod, не контейнер.

вопрос, как задумывалось - билдить приложение в образ all-in-one или настраивать микросервисы и мапить туда исходники?

зависит от приложения, но по-нормальному - микросервисы

для Kubernetes атомарная единица - pod, не контейнер.

для оператора куба

зависит от приложения, но по-нормальному - микросервисы

вот и у меня сейчас на микросервисах, но сообщество отговаривает)

да, я понимаю, что под переподнимается целиком в случае чего

для оператора куба

да без разницы. Кубернетес не оперирует контейнерами непосредственно

как он тогда работает-то? )

мало того, в случае с решениями типа virtlet - даже о контейнерах речь не идет

да, контейнеры под капотом. Но если мы говорим именно о единице для operations - это pod. Внутри него контейнеры, но это другой уровень абстракции

с виртлетом не работал, но я все-таки глубокую внутрянку тогда имел в виду.

да, тогда контейнеры (или что там внутри пода)

@idvoretskyi подскажите способы мапить, если не сложно. в идеале, хотелось бы собирать volume, давать ему label с версией и монтировать в контейнер

Оффтоп: аналогично люди заблуждаются когда говорят что с помощью Kubernetes управляют приложениями. Kubernetes менеджит сервисы, не приложения. Приложения - на уровень выше сервисов

@idvoretskyi подскажите способы мапить, если не сложно. в идеале, хотелось бы собирать volume, давать ему label с версией и монтировать в контейнер

исходники?

да

вот и у меня сейчас на микросервисах, но сообщество отговаривает)

мы все-таки не микросервисы проговаривали

а зачем их мапить в вольюм? Есть же git и прочие svn

мы все-таки не микросервисы проговаривали

попробую и так и так)

а зачем их мапить в вольюм? Есть же git и прочие svn

с фронтом не всё так гладко выходит, там extjs, его предварительно собирать надо, и в планах так и сделаю, но пока хотел просто собраные файлы замапить и попал в тупик

Ложи в configmap (шутка, не надо ;)

-_-

не до такой уж степени я и профан)

ну можно в вольюм, почему​ б и нет

но лучше собирай готовый имейдж - так проще будет (если я правильно понимаю проблему)

ну так и советуют. только сейчас у меня имейдж nginx, на котором фронт, и все урлы api и rest перенаправляются на fpm, на котором бэк. а придется из всего этого один образ собирать

что по идее идет вразрез с философией докера, где один сервис - один образ