Comments 42
Это уже кубернетес головного мозга.
Первый раз в этом году встретил слово Kubernetes. Наконец-то! Как хорошо, что есть вот такие восторженные статьи ни о чем. Люди брызжат радостью от использования очередного молотка, которым они могут эффективнее забивать гвозди, и делятся с окружающими своими позитивными эмоциями. Можно только порадоваться за них.
проблема лишь в том, что теперь на всё они будут смотреть как на гвоздь.
Мне кажется тут вопрос не про эмоции, а про то что мы сейчас наблюдаем появление некого стандарта дефакто в нашей области. Такого же, каким когда то стал Linux. Но для решения современных задач при современных подходах к архитектуре.
Но для решения современных задач при современных подходах к архитектуре.
именно так!
Возможно мы с вами работаем в очень разных областях разработки. Я читаю это как: "Наблюдаем появление некого стандарта дефакто в области оркестрации контейнеров. На сегодня это лучший выбор для архитектуры современных микросервисных приложений на Linux. Хотя вопрос оркестрации это 0,0ххх% от проекта, появление такого стандарта это круто."
Хотя вопрос оркестрации это 0,0ххх% от проекта, появление такого стандарта это круто."
кубер еще притаскивает с собой хорошие архитектурные практики и заставляет задуматься, например, что будет
если приложение запущено в несколько реплик (некоторые приложения в это не умеют и это проблема)
как правильно снимать метрики с приложения
как обеспечить отказоустойчивость приложения
и всякое такое
несомненно - можно и БЕЗ кубера сделать надежную и удобную инфру. Вот только вопрос того - насколько это будет какое-то местечковое решение, насколько дорого будет его поддерживать.
Как пример - в одной из компаний, где я работал, был разработан СВОЙ СОБСТВЕННЫЙ "оркестратор" для управления виртуальными машинами поверх гипервизора KVM... Насколько мне известно, он до сих пор работает... Но вот зачем, если можно было сразу взять условный опенстек и потом не переизобретать те же виртуальные сети и прочее
Вот в том то и дело, что не "оркестрации контейнеров", а управления инфраструктурой и построения архитектуры.
Запускать контейнеры отлично могут и Nomad и Docker Swarm. Но ни тот ни тот инструмент стандартом как Linux не станут.
Полностью согласен, кубернетес не панацея и не серебрянная пуля.
Перед началом VK Kubernetes Conference мы провели опрос среди участников Вечерней школы Kubernetes. Спросили, используют ли они Kubernetes в своих компаниях: ответили «да» 73% участников.
Опрос в интернете показал, что 100% людей пользуются интернетом)
Как бы там ни было, но все же количество компаний использующих k8s в своих инфраструктурах с момента появления этой технологии только растет, снижения пока еще замечено не было.
Как и любая технология - кубернетес имеет свои ограничения, свою область применения. А ещё логично, что у многих компаний есть задачи, которые покрываются куберенетесом. Но это совершенно не означает, что 100% задач покрывается кубом. Точно так же, другой пример, во многих компаниях прекрасно сосуществует инфраструктура и на железе, и на виртуализации, и на кубере. Нет необходимости выбирать что-то одно, если можно использовать все и выбирать наиболее подходящий инструмент под конкретную проблематику.
На самом деле выводы статьи абсолютно верные, но сами тезисы немного передернуты.
2. Все есть YAML-манифест
не ЯМЛ как таковой (это форма репрезентации, точно так же можно и json), а объект определенного типа в кубернетесе. Конечно, это объяснить гораздо сложнее, чем "YAML манифест", но кубер именно что предлагает набор каких-то базовых Kind, причем которые можно расширять. И еще важно - они все строго типизированы.
а у Canonical такого решения не было.
microk8s? Ну, конечно, это не такой дистрибутив, как OpenShift и не такой популярный, но тем не менее - тянет на дистрибутив.
Один из авторов Kubernetes как-то сказал ...
полностью согласен :-)
Согласен про YAML. Так же как и в Linux на самом деле все не файл, а файловый дескриптор. Но простые аналогии помогают лучше передать суть, как мне кажется.
По microk8s у них прям на сайте написано для чего предназначен этот дистрибутив – "A quick install, easy upgrades and great security make it perfect for micro clouds and edge computing."
То есть все таки сравнивать его с таким комбайном как OS не совсем корректно.
А как k8s поможет с 1с?
Файловые хранилища?
Я могу понять какой смысл в виртуализации ОС для мелкого и среднего бизнеса, а что даст k8s ?
Как уже писали выше, есть огромный пласт задач, где кубер - серебряная пуля, позволяющая решить массу проблем и очень серьёзно помочь.
Главное - не забывать, что этот пласт не занимает даже 50% от имеющихся в IT проблем. Поэтому правильный ответ - с 1С не поможет никак. Как и с файловым хранилищем. Как и с массой других задач и это совершенно нормально.
Тут как с облаками. Никто, наверное, не спорит, что облака это круто, полезно и может помочь экономить время и деньги. Но пихать вообще всё в облака - хороший способ выстрелить себе в ногу.
А как k8s поможет с 1с?
поможет, если надо запускать инстансы на скейле. Как минимум - может ускорить разработку под 1С. Для стандартного 1С в виде 2-х серверов фронта + балансировщика + 2 серверов БД на MSSQL или постгрес - да, наверное, толку особо не будет.
Файловые хранилища?
сюрприз, но крупные файловые хранилища под собой имеют какую-нибудь распределенную бд. А распределенную бд типа кассандру любо-дорого засунуть в что-то типа кубера (вопрос автоматизации управления инстансами)
Еще раз - продакшен базы можно пихать, если понимать, как с этим работать (там действительно есть нюансы именно по работе БД в кубере). Если не понимать - даже размещение баз на платформе виртуализации может аукнуться.
Уточню - я не предлагаю оголтело пихать базы в кубер, а скорее предлагаю пользоваться managed DB (DB-a-a-S). Но иногда вариантов нет
это не так, точнее не совсем так.
Давайте на пальцах.
Вот вам нужно поднять два кластера патрони. Поднимаем на каждый 3 етсд, 2 инстанса под постгрес, еще 2 под балансировщики. И это все на *2, потому что два кластера. Что можем улучшить? Сделать общий етсд. Уже оверхед меньше, но мы пожертвовали изоляцией.
Еще нам нужен мониторинг. Отдельно ставим заббикс или прометеус. Еще сколько-то серверов
Надо логирование - мы же хотим видеть логи обращений к базе и slow_log? окей. поднимаем кластер эластика.
И в результате получается, что если это все в инфраструктуре есть - мы молодцы, мы этим пользуемся, но если у нас ничего нет - все равно это приходится притаскивать и мы внезапно И БЕЗ кубера получаем оверхед 50%.
А если нам еще нужен SCM - это получается, выделенные узлы под salt или puppet. Из хороших новостей - это делается кластер на 1000-2000 узлов, которые мы менеджмим, т.е. оверхед не такой большой. Но инфра продолжает расплываться.
Теперь смотрим кубер. Репликация данных и обеспечение надежности их хранения - апи-сервера и етсд (все есть, SCM не нужен). Мониторинг и логирование из коробки (ну, если мы например тащим опеншифт, в ванилке надо доустанавливалить, но это делается по крайней мере унифицированным способом). Удобство управления и все такое. При этом даже оверхед может получиться меньше.
Короче, надо сравнивать apples to apples, чтобы сравнение было честным. И все не так плохо. Если Вы имеете в виду оверхед на конкретных узлах - т.е. сравниваем голую виртуалку с постгрес и рабочий узел кубера с постгрес, то опять же оверхед будет не такой большой. Процентов 5-10 может. От типа нагрузки зависит. Но в целом, это далеко не 50%. Потому что сама по себе контейнеризация ничего не ест - более того - тот же системди по умолчанию пользуется теми же механизмами ядра - cgroups & namespaces... Разве что файловая система может поднасрать... но это вообще отдельная история
понимаете, в чем дело... Это смотря что сравнивать. Я, например, видел статьи bare-metal vs виртуализация vs контейнеризация. Понятное дело, что контейнеризация по оверхеду между виртуализацией и береметал.
С другой стороны. Мы берем виртуализацию или кубер - и там, и там сеть будет виртуализирована. В первом случае какой-нибудь опенвсвитч. Во втором - какой-нибудь cni с туннелированием ipip/vxlan. Можно ли лучше? Ну, да, в кубере можно выкинуть сеть и пользоваться сетью хоста. В виртуализации, ну, никак - все равно упрешься в эти виртуальные сети, роутеры. С другой стороны - а может у вас кубер поверх виртуалок и ехала виртуализация через контейнеризацию и наборот? Зато удобно и одноообразно :-) Но вот облака выходят из положения тем, что свои CNI предлагают (амазон, ажур).
В общем - нет единого конфига, который бы всех устроил. Но опять же смотрите - практически весь веб живет на линукс. Где там фрибсд? Где винда? Где какие-то кастомные дистрибутивы? Мы в свое время слезли с генту на убунту и были очень рады - стоимость поддержки резко упала. Поэтому, к сожалению, или к счастью, кубер становится одним из стандартов для инфраструктуры.
Если есть конкретные вопросы - давайте пообсуждаем :-)
давайте определимся - ресурсы ЧЕГО? Рабочих узлов? Вряд ли.
Мастеров? Так и пофиг - они для этого нужны и выбираются с запасом. Повторюсь с аналогией для SCM - там те же самые проблемы: централизованная база с конфигурацией всех узлов, резервирование мастеров, распределение конфигураций по minion/slave/etc.
Поэтому в общем-то все не так страшно.
К тому же это становится проблемой только на реально больших кластерах (1000 узлов и 10000 подов). Вы свой бизнес до такого размера еще развейте сначала ))))
Ни в коем случае не спорю ни с вами ни со всеми комментариями выше.
Возвращаясь к аналогии с Linux, он так же никак не решал задачу запуска Oracle DB при своем появлении. Но по мере роста его популярности, производителям ПО пришлось адаптировать свои продукты для возможности их запуска на этой ОС.
Я думаю то же самое ждет и Kubernetes. Уже сейчас можно видеть, что во многие продукты добавляется нативная поддержка k8s. Появляются продукты, которые специально написаны для k8s и используют его встроенные возможности.
А что касается
Я могу понять какой смысл в виртуализации ОС для мелкого и среднего бизнеса, а что даст k8s ?
то естественно это вопрос задач. Так же как Linux ничего не даст например условному геймеру для решения его задач. Точно так же, если у вас нет задач, которые нужно решать кластерной операционной системой, то она вам ничего и не даст.
Я извиняюсь, вы сравниваете прикладное ПО и ядро ОС?? и считаете что одно в принципе может заменить другое? Как твёрдое заменит тёплое?
Ок, допустим для Вас linux это не ядро, а вся ОС(но рекомендую узнать что такое GNU). А на чем запуститься kubernes? А что внутри контейнера?
В общем, мой посыл, не путать хрен с трамвайной ручкой. КГ/АМ
PS да, докер головного мозга
Я кажется нигде не упомянал слово "заменить". Ествественно Kubernetes не может заменить Linux. Так же как Linux не может заменить процессор или оперативную память.
Это вещи работающие совершенно на разных уровнях. И вопрос не про замену, а про то что так же как сегодня подавляющее большинство инфраструктур работает на серверах с Linux, в будущем кажется большинство инфраструктур будут работать в Kubernetes. Но все так же поверх серверов с Linux, в которых все так же будут стоят процессоры и RAM.
А куда ушли конференции Linux? Имхо каждый год и не одна проходит.
Проходят. Но, во-первых, очень многие конференции именно по Linux закрылись за 2010-ые, во-вторых, те что остались это в основном "kernel developers summits", то есть как раз специфичные мероприятия для конкретного узкого круга специалистов занимающихся разработкой ядра, в-третьих, конференции с более широкой аудиторией концентрируются на продуктах и подходах в Linux, а не на самой ОС.
Кубер УЖЕ является стандартом, если мы говорим, про что-то более менее современное.
Деплоить как-то на какие-то железки - на мой взгляд, это допустимо только для on-premise решений, когда есть физические ограничения в виде человека, который не желает это обслуживать. Да и то, даже на таких сумасшедших есть всякие Rancher, EKS-anywhere от Амазона и т.п.
Все есть YAML-манифест
NixOS ?
Canonical — создателей самого популярного серверного дистрибутива Linux под названием Ubuntu.
Самым популярным серверным его называть сложно. Его и предпочтительным-то рука не поднимается назвать.
Какая альтернатива, на Ваш взгляд?
Ни то, ни другое не являются "самыми популярными".
Тем более в энтерпрайзе, которому необходимо подложить соломки в виде возможности купить коммерческую поддержку. А она у убунту есть, в отличии от дебиан и центос. Ну, и бинарно "убунту бесплатный" и "убунту с поддержкой" абсолютно идентичны. Еще я не представляю себе как шло бы развитие дебиан, без убунту. Все таки последняя популяризировала deb based дистры.
Centos тоже, кстати, сдал позиции. После недавних всем известных событий. Мы в целом RHEL используем (а могли бы более дешевый oracle linux), но для бесплатных задач смотрим в сторону Alma или Rocky - но это не будет прод...
"качайте бинарники"
а кто и что положил в эти бинарники - спрашивать уже не стоит. джентельменам надо верить на слово.
а еще лучше тащить вообще все готовое, иногда подправляя стартовый конфиг. и не задавать лишние вопросы.
Почему Kubernetes — это новый Linux: 4 аргумента