+Star Patrol I+ by ERA7
Привет, я Павел Селиванов, Architect и Developer Advocate в VK Cloud Solutions. Современные тенденции в отрасли приводят меня к убеждению, что Kubernetes становится чем-то вроде Linux, и в этой статье хочу объяснить свою позицию.
Перед началом VK Kubernetes Conference мы провели опрос среди участников Вечерней школы Kubernetes. Спросили, используют ли они Kubernetes в своих компаниях: ответили «да» 73% участников.
Сообщество К8s растет, альтернативные решения — Docker Swarm, Nomad и другие — столь же массово не применяют. Похоже, мы вплотную подходим к моменту, когда Kubernetes де-факто становится стандартом. Давайте разберем основные факторы, которые на это повлияли.
Статья написана на основе моего выступления на VK Kubernetes Conference — вы можете посмотреть его в записи.
1. Docker стандартизовал управление пакетами
Превращение Kubernetes в стандарт — во многом заслуга создателей Docker. Если бы эта технология была просто средством запуска контейнеров, заметную долю рынка сейчас занимал бы, к примеру, LXC.
Однако причина, по которой революцию в ИТ совершил Docker, в стандартизации. Именно он стал универсальным менеджером пакетов, который одинаково работает где угодно. Все, что запускается у разработчика локально, можно запустить на stage, на production и даже на ноутбуке с Windows у менеджера, который хочет познакомиться с системой.
2. Все есть YAML-манифест
Стандартизация — сильная сторона и самого Kubernetes, где подход к решению некоторых задач во многом похож на подход Linux. Например, в Linux (а до него — в UNIX) реализована гениальная идея, что в операционной системе все есть файл. В Kubernetes же все есть YAML-манифест. Если раньше вы имели дело с разнотипными объектами в DevOps-инструментах, с юнитами systemd, с jar, c Tomcat-серверами, кластерами, то сейчас у вас все управляется через манифесты.
Благодаря способности Kubernetes к расширению концепции вездесущности и универсальности YAML-манифестов мы можем продвинуться гораздо дальше простого управления контейнерами.
3. Дистрибутивы Kubernetes упрощают развертывание кластеров
Следующий важный момент — тенденция к упрощению развертывания Kubernetes. Сейчас эту процедуру, конечно, уже не сравнить с установкой Gentoo Linux, но на Arch Linux это все еще похоже: скачайте вот эти бинарники, сгенерируйте для них сертификаты, сложите вот сюда конфигурационные опции и т. д.
Установка Kubernetes сегодня — это как Arch Linux
Все это говорит о том, что у Kubernetes, как и раньше у Linux, в большом количестве будут появляться дистрибутивы. Их задача — упростить установку кластеров и управление ими, а также решить другие задачи. Поэтому можно смело утверждать: Kubernetes перерос оркестрацию контейнеров. Сегодня его было бы намного корректнее называть ядром кластерной операционной системы.
Эта тенденция хорошо заметна в мире большого энтерпрайза. Приведу известный пример. Несколько лет назад компания IBM купила компанию Red Hat. Перед сделкой были слухи о том, что IBM не против рассмотреть и Canonical — создателей самого популярного серверного дистрибутива Linux под названием Ubuntu. Почему IBM все-таки выбрали не их? Я думаю, свою роль здесь сыграло то, что у Red Hat был собственный популярный дистрибутив Kubernetes под названием OpenShift, а у Canonical такого решения не было.
4. Вокруг Kubernetes API формируется экосистема
API в Kubernetes, по сути, является аналогом POSIX в Linux. Он очень логично устроен: есть адрес API-сервера, API, версия API, неймспейсы, объекты — Pod, имя Pod и т. д. Все это представлено с точки зрения API в формате JSON, а с точки зрения того, как мы с этим обычно работаем, — в формате YAML. И все это стандартизировано.
Сам факт, что Kubernetes API — аналог POSIX для кластера, говорит нам о том, что Kubernetes со временем отойдет на дальний план. Ведь когда мы разрабатываем приложения, мы не думаем о POSIX. Все знают, что он из себя представляет и как устроен, все пользуются им по умолчанию. С Kubernetes примерно то же самое.
В итоге все идет к тому, что мы перестаем говорить об устройстве Kubernetes и построении кластера на нем. Вместо этого мы говорим о Kubernetes Native Big data и Kubernetes Native DBaaS, у нас появляются Kubernetes Native DevOps инструменты и другие.
Уже сейчас складывается картинка, похожая на известную инфографику CNCF Landscape, потому что Kubernetes превращается в большую платформу для запуска чего угодно.
Один из авторов Kubernetes как-то сказал: если мы правильно делаем свою работу, то лет через пять люди должны вообще перестать разговаривать о Kubernetes. И не потому, что он перестанет быть актуальным или станет слишком скучным. Просто он превратится в нормальный инструмент, на базе которого мы получим множество других, инновационных инструментов. И тогда конференции о Kubernetes уйдут в прошлое так же, как в прошлое ушли конференции про ядро Linux.
Команда VK Cloud Solutions развивает собственный Kubernetes aaS, о нем рассказывали в этой статье. Будем признательны, если вы его протестируете и дадите обратную связь. Для тестирования всем новым пользователям начисляем при регистрации 3000 бонусных рублей.
Что почитать по теме:
Комментарии (34)
ilia_reist
19.01.2022 12:17+32Перед началом VK Kubernetes Conference мы провели опрос среди участников Вечерней школы Kubernetes. Спросили, используют ли они Kubernetes в своих компаниях: ответили «да» 73% участников.
Опрос в интернете показал, что 100% людей пользуются интернетом)
pauljamm Автор
19.01.2022 15:34-2Как бы там ни было, но все же количество компаний использующих k8s в своих инфраструктурах с момента появления этой технологии только растет, снижения пока еще замечено не было.
gecube
20.01.2022 04:38+3Как и любая технология - кубернетес имеет свои ограничения, свою область применения. А ещё логично, что у многих компаний есть задачи, которые покрываются куберенетесом. Но это совершенно не означает, что 100% задач покрывается кубом. Точно так же, другой пример, во многих компаниях прекрасно сосуществует инфраструктура и на железе, и на виртуализации, и на кубере. Нет необходимости выбирать что-то одно, если можно использовать все и выбирать наиболее подходящий инструмент под конкретную проблематику.
gecube
19.01.2022 12:53+1На самом деле выводы статьи абсолютно верные, но сами тезисы немного передернуты.
2. Все есть YAML-манифест
не ЯМЛ как таковой (это форма репрезентации, точно так же можно и json), а объект определенного типа в кубернетесе. Конечно, это объяснить гораздо сложнее, чем "YAML манифест", но кубер именно что предлагает набор каких-то базовых Kind, причем которые можно расширять. И еще важно - они все строго типизированы.
а у Canonical такого решения не было.
microk8s? Ну, конечно, это не такой дистрибутив, как OpenShift и не такой популярный, но тем не менее - тянет на дистрибутив.
Один из авторов Kubernetes как-то сказал ...
полностью согласен :-)
pauljamm Автор
19.01.2022 15:32Согласен про YAML. Так же как и в Linux на самом деле все не файл, а файловый дескриптор. Но простые аналогии помогают лучше передать суть, как мне кажется.
По microk8s у них прям на сайте написано для чего предназначен этот дистрибутив – "A quick install, easy upgrades and great security make it perfect for micro clouds and edge computing."
То есть все таки сравнивать его с таким комбайном как OS не совсем корректно.
vsb
20.01.2022 04:17А как вы посоветуете сегодня разворачивать кубернетес на своих серверах, если особых предпочтений к конкретному дистрибутиву нет? Именно через установку этого OpenShift?
pauljamm Автор
20.01.2022 15:21-1Очень зависит от задачи. Если вы хотите получить весь функционал ванильного k8s, то вам нужен ванильный k8s. Если ваша задача получить в кратчайшие сроки с минимальными трудозатратами и погружением готовую среду для запуска ваших приложений, то да, смотрите на OS или Rancher.
typ6o0jiehb
20.01.2022 05:23А как k8s поможет с 1с?
Файловые хранилища?
Я могу понять какой смысл в виртуализации ОС для мелкого и среднего бизнеса, а что даст k8s ?
vp7
20.01.2022 07:50+1Как уже писали выше, есть огромный пласт задач, где кубер - серебряная пуля, позволяющая решить массу проблем и очень серьёзно помочь.
Главное - не забывать, что этот пласт не занимает даже 50% от имеющихся в IT проблем. Поэтому правильный ответ - с 1С не поможет никак. Как и с файловым хранилищем. Как и с массой других задач и это совершенно нормально.
Тут как с облаками. Никто, наверное, не спорит, что облака это круто, полезно и может помочь экономить время и деньги. Но пихать вообще всё в облака - хороший способ выстрелить себе в ногу.
gecube
20.01.2022 12:06А как k8s поможет с 1с?
поможет, если надо запускать инстансы на скейле. Как минимум - может ускорить разработку под 1С. Для стандартного 1С в виде 2-х серверов фронта + балансировщика + 2 серверов БД на MSSQL или постгрес - да, наверное, толку особо не будет.
Файловые хранилища?
сюрприз, но крупные файловые хранилища под собой имеют какую-нибудь распределенную бд. А распределенную бд типа кассандру любо-дорого засунуть в что-то типа кубера (вопрос автоматизации управления инстансами)
jh7
21.01.2022 09:21Я смотрел их конференцию и другие видео, как раз базы данных для продакшена настоятельно не рекомендуют пихать в кубер.
gecube
21.01.2022 12:56Еще раз - продакшен базы можно пихать, если понимать, как с этим работать (там действительно есть нюансы именно по работе БД в кубере). Если не понимать - даже размещение баз на платформе виртуализации может аукнуться.
Уточню - я не предлагаю оголтело пихать базы в кубер, а скорее предлагаю пользоваться managed DB (DB-a-a-S). Но иногда вариантов нет
jh7
21.01.2022 13:56Если понимать, то конечно. В кубере большой оверхед, около 50% ресурсов кластера может сжирать сам кубер на свои нужды. И тут надо думать.
gecube
21.01.2022 14:03это не так, точнее не совсем так.
Давайте на пальцах.
Вот вам нужно поднять два кластера патрони. Поднимаем на каждый 3 етсд, 2 инстанса под постгрес, еще 2 под балансировщики. И это все на *2, потому что два кластера. Что можем улучшить? Сделать общий етсд. Уже оверхед меньше, но мы пожертвовали изоляцией.
Еще нам нужен мониторинг. Отдельно ставим заббикс или прометеус. Еще сколько-то серверов
Надо логирование - мы же хотим видеть логи обращений к базе и slow_log? окей. поднимаем кластер эластика.
И в результате получается, что если это все в инфраструктуре есть - мы молодцы, мы этим пользуемся, но если у нас ничего нет - все равно это приходится притаскивать и мы внезапно И БЕЗ кубера получаем оверхед 50%.
А если нам еще нужен SCM - это получается, выделенные узлы под salt или puppet. Из хороших новостей - это делается кластер на 1000-2000 узлов, которые мы менеджмим, т.е. оверхед не такой большой. Но инфра продолжает расплываться.
Теперь смотрим кубер. Репликация данных и обеспечение надежности их хранения - апи-сервера и етсд (все есть, SCM не нужен). Мониторинг и логирование из коробки (ну, если мы например тащим опеншифт, в ванилке надо доустанавливалить, но это делается по крайней мере унифицированным способом). Удобство управления и все такое. При этом даже оверхед может получиться меньше.
Короче, надо сравнивать apples to apples, чтобы сравнение было честным. И все не так плохо. Если Вы имеете в виду оверхед на конкретных узлах - т.е. сравниваем голую виртуалку с постгрес и рабочий узел кубера с постгрес, то опять же оверхед будет не такой большой. Процентов 5-10 может. От типа нагрузки зависит. Но в целом, это далеко не 50%. Потому что сама по себе контейнеризация ничего не ест - более того - тот же системди по умолчанию пользуется теми же механизмами ядра - cgroups & namespaces... Разве что файловая система может поднасрать... но это вообще отдельная история
jh7
21.01.2022 14:14Я честно не имею никакго отншения к куберу, смотрел для общего развитя.
Вот конкретная ссылка https://youtu.be/0z_kSrdvlaU?list=PL8D2P0ruohOBSA_CDqJLflJ8FLJNe26K-&t=1584
Видео немного рекламное, но не думаю, что они сильно врали.
gecube
21.01.2022 15:03понимаете, в чем дело... Это смотря что сравнивать. Я, например, видел статьи bare-metal vs виртуализация vs контейнеризация. Понятное дело, что контейнеризация по оверхеду между виртуализацией и береметал.
С другой стороны. Мы берем виртуализацию или кубер - и там, и там сеть будет виртуализирована. В первом случае какой-нибудь опенвсвитч. Во втором - какой-нибудь cni с туннелированием ipip/vxlan. Можно ли лучше? Ну, да, в кубере можно выкинуть сеть и пользоваться сетью хоста. В виртуализации, ну, никак - все равно упрешься в эти виртуальные сети, роутеры. С другой стороны - а может у вас кубер поверх виртуалок и ехала виртуализация через контейнеризацию и наборот? Зато удобно и одноообразно :-) Но вот облака выходят из положения тем, что свои CNI предлагают (амазон, ажур).
В общем - нет единого конфига, который бы всех устроил. Но опять же смотрите - практически весь веб живет на линукс. Где там фрибсд? Где винда? Где какие-то кастомные дистрибутивы? Мы в свое время слезли с генту на убунту и были очень рады - стоимость поддержки резко упала. Поэтому, к сожалению, или к счастью, кубер становится одним из стандартов для инфраструктуры.
Если есть конкретные вопросы - давайте пообсуждаем :-)
jh7
21.01.2022 15:11Я особо не спорю.
В кубере есть еще такой фактор - постоянный мониториг нод и подов. Постоянное обновление всех параметров в базе etcd. База тоже отказоустойчивая, на нескольких нодах.
Отвалилась нода, надо все поды перезапустить на других нодах.
Как я понимаю, основные ресурсы кушает вот этот самый мониторинг и обеспечение отказоустойчивости.
gecube
21.01.2022 15:16давайте определимся - ресурсы ЧЕГО? Рабочих узлов? Вряд ли.
Мастеров? Так и пофиг - они для этого нужны и выбираются с запасом. Повторюсь с аналогией для SCM - там те же самые проблемы: централизованная база с конфигурацией всех узлов, резервирование мастеров, распределение конфигураций по minion/slave/etc.
Поэтому в общем-то все не так страшно.
К тому же это становится проблемой только на реально больших кластерах (1000 узлов и 10000 подов). Вы свой бизнес до такого размера еще развейте сначала ))))
pauljamm Автор
20.01.2022 15:17Ни в коем случае не спорю ни с вами ни со всеми комментариями выше.
Возвращаясь к аналогии с Linux, он так же никак не решал задачу запуска Oracle DB при своем появлении. Но по мере роста его популярности, производителям ПО пришлось адаптировать свои продукты для возможности их запуска на этой ОС.
Я думаю то же самое ждет и Kubernetes. Уже сейчас можно видеть, что во многие продукты добавляется нативная поддержка k8s. Появляются продукты, которые специально написаны для k8s и используют его встроенные возможности.
А что касается
Я могу понять какой смысл в виртуализации ОС для мелкого и среднего бизнеса, а что даст k8s ?
то естественно это вопрос задач. Так же как Linux ничего не даст например условному геймеру для решения его задач. Точно так же, если у вас нет задач, которые нужно решать кластерной операционной системой, то она вам ничего и не даст.
Boozlachu
20.01.2022 14:41Я извиняюсь, вы сравниваете прикладное ПО и ядро ОС?? и считаете что одно в принципе может заменить другое? Как твёрдое заменит тёплое?
Ок, допустим для Вас linux это не ядро, а вся ОС(но рекомендую узнать что такое GNU). А на чем запуститься kubernes? А что внутри контейнера?
В общем, мой посыл, не путать хрен с трамвайной ручкой. КГ/АМ
PS да, докер головного мозга
pauljamm Автор
20.01.2022 14:52+1Я кажется нигде не упомянал слово "заменить". Ествественно Kubernetes не может заменить Linux. Так же как Linux не может заменить процессор или оперативную память.
Это вещи работающие совершенно на разных уровнях. И вопрос не про замену, а про то что так же как сегодня подавляющее большинство инфраструктур работает на серверах с Linux, в будущем кажется большинство инфраструктур будут работать в Kubernetes. Но все так же поверх серверов с Linux, в которых все так же будут стоят процессоры и RAM.
mc2
20.01.2022 18:12А куда ушли конференции Linux? Имхо каждый год и не одна проходит.
pauljamm Автор
21.01.2022 11:49Проходят. Но, во-первых, очень многие конференции именно по Linux закрылись за 2010-ые, во-вторых, те что остались это в основном "kernel developers summits", то есть как раз специфичные мероприятия для конкретного узкого круга специалистов занимающихся разработкой ядра, в-третьих, конференции с более широкой аудиторией концентрируются на продуктах и подходах в Linux, а не на самой ОС.
mfenderov
21.01.2022 11:43+1Кубер УЖЕ является стандартом, если мы говорим, про что-то более менее современное.
Деплоить как-то на какие-то железки - на мой взгляд, это допустимо только для on-premise решений, когда есть физические ограничения в виде человека, который не желает это обслуживать. Да и то, даже на таких сумасшедших есть всякие Rancher, EKS-anywhere от Амазона и т.п.
Shaz
Это уже кубернетес головного мозга.
MockBeard
Первый раз в этом году встретил слово Kubernetes. Наконец-то! Как хорошо, что есть вот такие восторженные статьи ни о чем. Люди брызжат радостью от использования очередного молотка, которым они могут эффективнее забивать гвозди, и делятся с окружающими своими позитивными эмоциями. Можно только порадоваться за них.
paxlo
проблема лишь в том, что теперь на всё они будут смотреть как на гвоздь.
pauljamm Автор
Мне кажется тут вопрос не про эмоции, а про то что мы сейчас наблюдаем появление некого стандарта дефакто в нашей области. Такого же, каким когда то стал Linux. Но для решения современных задач при современных подходах к архитектуре.
gecube
именно так!
MockBeard
Возможно мы с вами работаем в очень разных областях разработки. Я читаю это как: "Наблюдаем появление некого стандарта дефакто в области оркестрации контейнеров. На сегодня это лучший выбор для архитектуры современных микросервисных приложений на Linux. Хотя вопрос оркестрации это 0,0ххх% от проекта, появление такого стандарта это круто."
gecube
кубер еще притаскивает с собой хорошие архитектурные практики и заставляет задуматься, например, что будет
если приложение запущено в несколько реплик (некоторые приложения в это не умеют и это проблема)
как правильно снимать метрики с приложения
как обеспечить отказоустойчивость приложения
и всякое такое
несомненно - можно и БЕЗ кубера сделать надежную и удобную инфру. Вот только вопрос того - насколько это будет какое-то местечковое решение, насколько дорого будет его поддерживать.
Как пример - в одной из компаний, где я работал, был разработан СВОЙ СОБСТВЕННЫЙ "оркестратор" для управления виртуальными машинами поверх гипервизора KVM... Насколько мне известно, он до сих пор работает... Но вот зачем, если можно было сразу взять условный опенстек и потом не переизобретать те же виртуальные сети и прочее
MockBeard
ясно, спасибо за пояснения
pauljamm Автор
Вот в том то и дело, что не "оркестрации контейнеров", а управления инфраструктурой и построения архитектуры.
Запускать контейнеры отлично могут и Nomad и Docker Swarm. Но ни тот ни тот инструмент стандартом как Linux не станут.