Митап «Да кому он нужен, этот ваш Kubernetes?» Все, о чем Вы боялись спросить, но хотели узнать

Кто-нибудь может внятно объяснить что это такое?

k8s — средство оркестрации контейнеров, по поводу которого в мире третий год страшный шум стоит. Странно, что вы не слышали.

оркестрации

А это что такое? «Управление»?

Управление - это старт/стоп контейнера (брынчать/не брынчать кому-то конкретному). А оркестрация - это кого, где и когда запускать/останавливать (кому и когда брынчать) чтобы в целом все играло сладно.

Как systemd да? Кстати, а чоб тогда через systemd не оркестровать.

systemd - это когда ты оркестрируешь каким пальцем по какой клавише тебе надо жать

а k8s - когда определяешь в каком месте вступают скрипки, и где надо притушить громкость духовых

По сути - средство для управления набором контейнеров, так?

По сути весь мир - средство управления набором контейнеров )

k8s - это контейнерное облако, то есть он позволяет абстрагироваться от железа, так как в нем есть планировщик, управление ресурсами и квотами, балансировка нагрузки, auto-healing, auto-scaling, агрегация логов и метрик.. и т.п.

Скорее не от самого железа, а от топологии. То есть вместо того, чтобы думать: «вот эти 3 коробки для mysqld кластера, на этих двух крутится tomcat, и еще одна нужна для nginx frontned» просто регистрируешь их все в кластере, а потом в файлике описываешь желаемую топологию: какие сервисы должны на одной ноде находиться, и сколько экземпляров кого создавать, а кубернетес уже сам подбирает ноды и стартует на них контейнеры в правильном порядке.

Привязка контейнера к ноде - это скорее костыль для некоторых специфичных задач.

Для большинства приложений ты стараешься никаких явных привязок не делать. Либо «запусти 6 штук nginx-фронтендов», либо «разложи по одному инстансу на каждой ноде, сколько бы их ни было».

Выкатка приложения на конкретный хост противоречит концепции, и не дает использовать всю силу auto-healing и auto-scaling и прочих нужных примочек, ради которых это всё это затевалось.

Выкатка приложения на конкретный хост противоречит концепции, и не дает использовать всю силу auto-healing и auto-scaling

Да пребудет с нами сила auto-makaking.

k8s

Какой ещё «кейтс», в новости про него не было.

k8s

Какой ещё «кейтс», в новости про него не было.

http://edit.dialogic.com/glossary/kubernetes

The name Kubernetes originates from Greek, meaning helmsman or pilot, and is the root of governor and cybernetic. K8s is an abbreviation derived by replacing the 8 letters “ubernete” with “8”.

Сами создадим себе проблемы, потом сами будем городить костыли.

И часто в проекте применяется этот принцип?

Сами создадим себе проблемы, потом сами будем городить костыли.

И часто в проекте применяется этот принцип?

ХЗ... Я не пользую. Так и не придумал этому реального применения.

В хозяйстве было некое подобие - Docker Swarm — создаёт проблем больше чем решает... Снесли.

У кубернетеса главным преимуществом перед свормом видится сеть — большая часть проблем в сворме была именно из-за сети. Но в итоге дискуссий - перейти на кубернетес или на железо/виртуалки - отказались от «оркестрации контейнеров». Микросервисов у нас нет, а разворачивать «жЫрные» сервисы с персистентными данными в контейнерах — глупо. С учётом наличия персистентных данных вся эта «оркестрация» и вовсе лишняя, т.к. контейнеры привязаны к хостам где лежат данные (кластерные ФС - отдельная проблема).

IPv6 без оверлейных сетей и ручной раздачи адресов уже научились? Или всё так же на уровне IPv4 из RFC1918?

Но в итоге дискуссий - перейти на кубернетес или на железо/виртуалки - отказались от «оркестрации контейнеров»

Перешли на виртуалки или как?

Перешли на виртуалки или как?

В зависимости от сервиса... Некоторые оставили в докере, но без сворма, другие - да, на виртуалки.

В облачных вычислениях это всё было уже лет 20 как. Планировщики ресурсов, MPI для собственно запуска, distributed shell'ы...

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

Контейнер - это либо уродливое г*но «собери все зависимости приложения в кучу», либо это слои, которые чем тоньше, тем меньше различий между контейнером и приложением, в него упакованным. При этом вылезает обратно вся история с зависимостями и фактически появляется поверх нормального дистрибутива Linux «контейнерный дистрибутив». Вообще контейнеры поощряют бардак и отсутствие унификации в ИТ-инфраструктуре, плодят дыры в безопасности (поскольку содержимое контейнеров же трогать низзя ни в коем случае, даже если разработчик туда запихал отруби мамонта) и жрут в разы больше места на диске. По сути это статически собранные пакеты на стероидах, при этом ещё и работающие с ядром через слой контейнерной «абстракции», т.е. медленнее нормальных приложений. Почему они нужны бизнесу? Особенно однодневному быдло-рашн-бузинесу? Потому что облегчают сиюмоментный х*як-х*як-продакшн. А что там будет дальше и как это администрировать - никого не волнует. Зато разработчикам удобно ничего не знать про Linux. Просто бать какая высокая достойная цель достигнута!

Причем здесь рашн? Это общемировая тенденция к отуплению (и вытекающему удешевлению) разработчиков. Собственно, отсюда и появился девопс.

Вообще контейнеры поощряют бардак и отсутствие унификации в ИТ-инфраструктуре, плодят дыры в безопасности (поскольку содержимое контейнеров же трогать низзя ни в коем случае, даже если разработчик туда запихал отруби мамонта)

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

и жрут в разы больше места на диске.

Официальный образ с перлом занимает 37 Мб https://hub.docker.com/r/library/perl/tags/

Есть образы на основе дистрибутива alpine. Чистый образ alpine https://hub.docker.com/r/library/alpine/tags/ занимает 2 Мб(!)

Образ с перлом на основе alpine - 11 Мб https://hub.docker.com/r/avastsoftware/alpine-perl/tags/

при этом ещё и работающие с ядром через слой контейнерной «абстракции», т.е. медленнее нормальных приложений

Нет, контейнеры системные вызовы ни как не проксируют, системные вызовы делаются напрямую в ядро. Контейнеры используют фичи типа namespaces и cgroup, которые находятся в ядре.

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

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

настроенный руками сервер, где кто-то кода-то что-то >редактировал, но никто уже не помнит что и где.

Ну руками сервера большими количествами уже редко настраивают, тоже используют систему «оркестрации» типа Ansible, Salt, Puppet ..

В пользу контейнеров, можно сказать что «бинарник» и всякие либы на серваке те же что у разработчика. Для отладки количество внешних эффектов резко сокращается.

Ну а так же можно довольно легко запускать приложения на разном стеке: где-то python, где-то java, где-то python3, где-то С++ и так далее.

Лично у нас были проблемы, когда мы запаковывали приложения в DEB и разным приложениям был нужен разные либы, например python-requests, и разные версии на один бокс не поставить.

Ну руками сервера большими количествами уже редко настраивают, тоже используют систему «оркестрации» типа Ansible, Salt, Puppet ..

Я не говорю что контейнеры единственный или лучший способ сделать infrastructure as code, про другие инструменты я не упомянул т.к. тут речь шла про контейнеры и с другими инструментами я не работал. Когда подправлял ansible playbook создалось впечатление, что у подобных систем порог входа выше, чем у докера т.к. там свой синтаксис, свои модули и т.д., а в докере можно использовать обычные linux команды они мне гораздо привычнее. Еще проблема может быть в том, что если делать ansible надо все делать ansible и что-то подправить из консоли уже нельзя, если для серверов это норм, то на девелоперской машине так сделать не получится + у девелопера может быть сразу несколько проектов. Тогда выходит, что нужна полноценная виртуалка с чистой осью на которой все будет делаться ansible. Или использовать в разработке докер + ansible, а на проде тот же ansible, но уже без докера.

погляди к появлению каких личностей приводят докеры:

docker под chroot, выдает ошибку failed to register layer

В облачных вычислениях это всё было уже лет 20 как. Планировщики ресурсов, MPI для собственно запуска, distributed shell'ы...

Не только было, но и есть. Вот только при чем тут MPI и к8с?

Почему они нужны бизнесу?

Именно потому, что ты описал выше: «бардак и отсутствие унификации в ИТ-инфраструктуре»

А что там будет дальше и как это администрировать - никого не волнует.

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

Ты сам то перестал цеплять контейнеры к dhcp серверу? Личности без докера сделают такую же хрень.

Лично у нас были проблемы, когда мы запаковывали приложения в DEB и разным приложениям был нужен разные либы, например python-requests, и разные версии на один бокс не поставить.

LD_LIBRARY_PATH. Не слышали?

Через пакетный менеджер не получится поставить несколько версий одной и той же библиотеки. Придется ставить руками так дебиан можно в слаку превратить постепенно :)

Библиотеки таскать с приложением как часть пакета.

Так делается например в software collections.

Но без изоляции это сложно тестировать и отслеживать.

Контейнейрные immutable-образы - это более простой, надежный и удобный формат для такого пакета.

Так делается например в software collections.

AFAIK, software collections гораздо более сложная вещь.

Но без изоляции это сложно тестировать и отслеживать.

Сложнее, чем контейнерный образ? Серьезно?

Контейнейрные immutable-образы - это более простой, надежный и удобный формат для такого пакета.

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

AFAIK, software collections гораздо более сложная вещь.

Ну так если разворачивать твою мысль там тоже простым LD_LIBRARY_PATH не обойдешься. Software collections - это идея о параллельной установке софта силами пакетного менеджера, доведенная до реальной, production-ready реализации.

Сложнее, чем контейнерный образ? Серьезно?

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

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

Контейнерные образы - это гораздо более сложный способ сделать то, что делают пакеты с включенными библиотеками

Ты с точки зрения разработчика конкретного приложения смотришь. Если смотреть на приложение как на черный ящик - ситуация иная.

AFAIK, software collections гораздо более сложная вещь.

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

Для меня LD_LIBRARY_PATH - это как бы метафора. Без собственно LD_LIBRARY_PATH я при необходимости обойдусь - вобью в бинарь относительный RPATH.

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

Я думаю, что смогу без проблем собрать приложение, гарантированно не цепляющее системные библиотеки. Повторюсь, что сложность контейнеров может тупо не окупаться (подразумеваем, что их позволено использовать).

Ты с точки зрения разработчика конкретного приложения смотришь. Если смотреть на приложение как на черный ящик - ситуация иная.

Но речь-то шла именно о приложении. Понятно, что, если приходится иметь дело с «черными ящиками», то надо изолировать их и молиться.

Но речь-то шла именно о приложении. Понятно, что, если приходится иметь дело с «черными ящиками», то надо изолировать их и молиться.

Приложение переходит в статус черного ящика достаточно быстро. Практически сразу после выпуска.

Даже скорее так: не черным ящиком оно является исключительно для автора и только в период активной разработки.

Всё остальное время - изолируем и молимся.

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

Думаю, это профдеформация девопса.

Профдеформация девопса против профдеформации разработчика :)

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

Отсутствие разработчика - это важная часть этой проблемы. Иначе бы правильным решением было просто адаптироваться и выпустить новую версию софта, а не придумывать костылей ни с bundled-зависимостями, ни с чем либо ещё.

Профдеформация девопса против профдеформации разработчика :)

Но я-то прав! %)

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

Ну, скорее не проблему отсутствующего разработчика, а проблему разработчика, который выпустил приложение ровно для одной версии одной системы. И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами. Что выгоднее - зависит от ситуации. Если разработчик пропал без вести, оставив критический бинарь, зависящий от libc5 - думаю, даже контейнер не поможетБ придется городить VM.

Пакетный менеджер не препятствует установке каких угодно файлов куда угодно. Но да, в дистрибутивах разные версии библиотек опакечивают редко. Тем не менее, никто не мешает сделать свой пакет deb, пихающий либу нужной версии в какой-нибудь /opt/libs/mylib/$version

И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами.

Что делать, когда выйдет бюллетень по безопасности с описанием уязвимости в «упакованной» куда угодно библиотеке и ссылками на эксплойты для эксплуатации уязвимости? Особенно это забавно может оказаться в том случае, если софт, упаковываемый в docker/статичный пакет - разрабатывается вполне себе открыто или какая-то его открытая версия есть на github, gitlab и т.п. В этом случае злоумышленнику достаточно знать: а) о «внезапной» (крайне предсказуемой) приверженности docker'у разработчиков приложения; б) о том, что нужные приложению библиотеки подключаются не извне (отдельным докер-слоем), а просто статично пакуются внутрь контейнера - и это тоже весьма предсказуемо, потому что разработчики как правило «выше этого», у них «более важные задачи» (чем забота о том, чтобы их приложение могло с минимальным ручным оверхедом работать с обновляемыми версиями библиотек).

При этом никакой реальной объективной проблемы с библиотеками общего пользования нет и в помине. Она реально просто придумана людьми, которые либо умозрительно делают заключение о том, что проблема может возникнуть, либо когда у них возникала такая проблема - даже не пытались разобраться в её причинах, свалив всё на «разные же версии». Почему так? Да потому что любые common used популярные библиотеки поддерживают ABI back compatibility на протяжении десятилетий. А если разработчик использует какую-то редкую библиотеку от Васи Пупкина - то здесь возникают вопросы совершенно иного характера (и её в общем-то можно упаковать в контейнер/пакет, предварительно всё-таки выяснив, почему вообще в проекте используется загадочная сторонняя библиотека).

И пакет с включенными библиотеками тоже решает эту проблему, просто другими средствами.

Что делать, когда выйдет бюллетень по безопасности с описанием уязвимости в «упакованной» куда угодно библиотеке и ссылками на эксплойты для эксплуатации уязвимости?

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