фф

как ни крути железа ещё дофигища у которого Ipv6 в зачатках или не работает или не так работает

как ни крути железа ещё дофигища у которого Ipv6 в зачатках или не работает или не так работает

в датацентрах - единицы коробок. даже десятилетние датацентровые свитчи умеют ipv6 отлично.

в диком интернете - да.

ну не у всех датацентры) есть куча ембедов, арм фермы и прочие soho

https://github.com/cilium/cilium

они реализуют overlay или другую коннективити на BPF?

да вот эта штука выглядит неплохо.

смущает чрезмерно bleeding edge. 4.8.0 а лучше 4.9 - сыровато для прода?

да вот эта штука выглядит неплохо.

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

ты хочешь совсем оверлей убрать? так работает? я видел только PoC такого

и то там то идёт то не идет

пинг

вообще идея норм, наплодили сущностей уже тыщу

ну не у всех датацентры) есть куча ембедов, арм фермы и прочие soho

он прибит гвоздями к ЦОД. И наружу можно и по 4-ке

ты хочешь совсем оверлей убрать? так работает? я видел только PoC такого

работает. на v4 я делал.

докер без оверлея? а можно где-то посмотреть? гитхуб?

но калико же без оверлея.

можно то же самое сделать на статической маршрутизации

calico то понятно

)

надо решать проблемы l3 агента, а их немало

нейтрон или openvswitch крутить

это уже сильно усложняет проект и поддержку

ээ. это ж чатик про k8s. neutron?

ну чатик просто поговорить)

ovs - та же инкапсуляция.

а canal че там

живой?

ээ. это ж чатик про k8s. neutron?

нейтрон вполне работает в кубе. JD используют, например

обещали опенсорц и доклад, но пока жмутся

нейтрон вполне работает в кубе. JD используют, например

но зачем? весь профит от него только в наполнении ovs данными. или я что-то не понимаю?

нейтрон старый, надежный, интегрируется с OVS (а OVS реально построить в железе)

плюс никаких тебе туннелей, полноценная сеть

плюс никаких тебе туннелей, полноценная сеть

откуда полноценная-то?

через openflow

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

а кто сказал, что не будет прямой связанности? опенфлоу напрямую интегрируется с ядром. Оно же напрямую поддерживается коммутаторами

в чем проблема?

если есть прямая связанность - уже не интересно :(

а как сделать без прямой связанности и без инкапсуляции? В принципе как?

меня это и удивило :)

нет, а это концептуально-то возможно?

гипотетически нельзя наверное называть инкапсуляцией ovs-dpdk, то есть можно, но негативных моментов (кроме оверхеда от лишних заголовков в полосе) не должно нести.

а как оно переправляет пакеты?

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

я к чему: основная боль, которую я имел от инкапсуляции в тестах - увеличение latency. полоса уменьшается - понятно, но latency и хождение внутри ядра несколько раз - боль. с DPDK гипотетически мы должны получить снижение тяжести отправки трафика и скомпенсировать тормоза от инкапсуляции.

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

каких?

сети?

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

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

самому k8s пофиг же, он же не ворочает ничего сам. зависит от того, какие технологии лежат под стораджем, под exec-driver'ом и под сетью.

мы не фиксировали статистически заметных потерь на cpu/ram от cgroups, и namespaces. network namespaces импактят, но не сами по себе а через veth до соседнего неймспейса. импакт от veth - десятки микросекунд на latency, на полосе/пакетрейте до 10 гбит/с и 200kpps заметную деградацию получить не удалось. linux bridge - говно, жрущее cpu и накидывающее еще несколько десятков микросекунд на задержку.

у меня немного оффтопный вопрос :) а в этом деревянном веб-интерфейсе кубернетеса как-то можно выводить не по 10 подов за раз а например по 100? или сортировать по потреблению памяти например? :)

Никак. Есть тикет на это

Но пока не сделал никто

Поиска там тоже нет

кстати, мне тут мегаполезную тулзу подогнали, спешу поделиться вдруг кто не знает еще: https://github.com/wercker/stern

если вкратце то это kubectl logs на стеройдах

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

graylog, извините

пора заводить чятик секты фанатов graylog

а че, лучше ELK?

а то я как-то по старинке все...

EFK

ERK

тут уже много ссылок присылали по настройке логов с кластера

R?

rsyslog

рсислог

ясно)

еще можно упороться и сделать EKK

Kafka

вместо рсислога актуально journald уже наверно

правда между приложением и кафкой нужно будет что-то запихать.

вместо рсислога актуально journald уже наверно

эээ, нет.

для кореос удобнее

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

грейлог это обычный аггрегатор логов. кафки все ваши логстеши

норм но надо пилить

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

а в грейлог придумал регулярку и пьёшь кофе с кровосанами