Всем привет!
Я очень консервативный веб дев, в области давно но только недавно начал вникать в некоторые популярные технологии, в т.ч. контейнеризацию.
Освоил +- docker и docker compose, все идет хорошо, но остались незакрываемые вопросы документацией (либо потому что слишком глупые, либо возможно холиварные), и их может закрыть мне помочь только сообщество.
В корпах я не работал, представляю как делают там - смутно, поэтому палками прошу не бить.
1) docker compose умеет в виртуальные сети, перезапуск умирающих нод по любым причинам, логи, вся фигня - зачем существует кубернетес? допустим, запускать ноды по мере роста нагрузки и балансировать, чтоб не писать свои костыли для этого через апи докера? условно, собирая с нгинкса колво хитов и запуская с каждой новой тысячей отдельную ноду на которые нгинкс это всё балансит. именно с подобными задачами призван справляться кубер, давая удобный интерфейс?
2) допустим, сделал я проект в виде docker compose. сейчас чешу на впс, качаю докер, запускаю и все. удобство в том, что не нужны мои простыни инструкций, в которых иногда что-нибудь да идет не так. но православный ли это путь?)) как будто не просто ускорять развертывание и структурировать хранение проектов докер придумывали.
3) что делать, если внезапно такой изначально небольшой проект сильно разросся и пора распределяться на пару-тройку серверов? Сиди переписывай на кубер или почему не сделал сразу как надо?
Мои вопросы связаны с тем чтоб не попасть в оверкилл. Кажется, нахрена nginx'у с пхп, мариадб и паре утилитарных нод какие-то там куберы. Я в целом привык залетать на bare-metal с парой своих инструкций по установке lemp, но затем прочувствовал кайф докера, и сейчас хотелось бы использовать его грамотно, но без оверкиллов, и не использовать там где он вовсе не нужен.
Пока что сложилось впечатление что кубер нужен только тем, у кого железяк больше одной. Прав ли я?
Кубер для крупных микросервисных проектов, где сервисов, ну, хотя бы десяток. Для одного маленького монолита преимуществ не будет.
Кубер нет смысла эксплуатировать в проде всего на одной ноде - все преимущества отказоустойчивости минус.
Какие преимущества кубера - развертывание сервисов в N инстансов на K серверов, выживаемость этих серивсов при отказе нескольких нод или инстансов, балансировки, обновления без даунтаймов (rolling update)... Там еще много всего что касается массированных развертываний.
Съехать с композов в кубер проблема незнаичительная, можно развиваться по мере необходимости
bronzeev, если особых требований по аптайму, частоте поставок и нагрузке нет, да или вовсе вы один разработчик и ops в одном лице на проекте - композа хватит)
Drno, тогда супер
значит не настолько я и устарел со своими подходами))
колво инструментов и подходов пугает просто, статей на хабре как грязи
они раздули фронтенд сделав из него отдельную огромную область со своими spa, вот было ощущение что с развертыванием так же, хотя для большинства средних и малых проектов хватает простых вещей
Дмитрий Шицков, в целом так и есть, понял! спасибо. тогда как придется в команде работать - тогда и уткнусь в кубер и прочее)
Valentin Barbolin, смотрел, кстати, он тоже неплох
боюсь правда что в моем случае это тоже оверкилл, т.к. сейчас либо вообще в соло делаю, либо сразу большим командам проект уходит, где они уже сразу на супер пупер технологиях фигачат с выделенным девопсом) и как правило приходится выбирать то, под что специалиста найти легче, и так понимаю под кубер их все равно больше в силу того что авторам докера по хорошему все рекомендуют именно на самом докере концентрироваться
Кубернетес - в первую очередь инструмент эксплуатации. Можете оставаться "консервативным веб девом", вообще практически его не касаясь - это забота админов.
Главное, чтобы вы представляли, чем разработка контейнеризованного приложения отличается - сборка в Докере, стейтлесс, пробы и т. д.
да вот боюсь в том и дело
докерфайлы все равно собирают сами кодеры, поэтому понимать как работает кубер точно не помешает, в здравом коллективе где админы и девы не враги друг другу
сейчас со статьями преисполнился уже за пару часов что к чему) кубер это действительно область организаций состоящих не из одного меня и не из одной впски (или в целом не из вмок), так что имеет смысл разве что поверхностно пока ознакомиться. Зато, попробую погрузиться в lxc/lxd и освоить иной способ упаковки ПО - вот в эту сторону мне сейчас двинуться будет куда полезнее из за пары проектов.
а по докеру да, тоже глубокое его понимание не помешает, но это уже документацией закрою, не кажутся остальные мои вопросы негуглибельными))
хотелось именно понять рациональность гипотетического пользования кубера в одиночку, в целом теперь ясно
bronzeev, во многих компаниях кубер вам предоставляется "как сервис". То есть админы развернули ноды, кластер, control plane, и иже с ними. Загнать свой код в кубер задача разработчика. Helm чарты написать и тд. Не везде так конечно, но много где именно такой подход встречается.
Если утрировать, то кубер - это сервис по запуску контейнеров + виртуальная сеть поверх всех машин в кластере.
1. Если копнуть чуть глубже - вы можете в конфиге указать "хочу постоянное хранилище для базы". Какое именно это хранилище будет (S3, файлопомойка, перфокарты) - уже задача того кто кластер обслуживает. Или "запускать 1 веб и 1 редис на каждом физическом сервере" - этим будет заниматься кубер. Или "хочу 8 ядер для каждого экземпляра приложения". Заведовать ресурсами тоже будет кубер, как и перетаскивать приложения с сервера на сервер в отсутствии ресурсов (и перестраивая при этом сетевые запросы). И запускать новые экземпляры приложения в зависимости от нагрузки на процессор - тоже будет он. Считайте что это docker swarm на стероидах.
2. Если вам достаточно docker-compose и одного-двух серверов - ничего страшного в этом нет. Это не "зашквар" жить без кубера - он вообще специализированный инструмент, как и сами контейнеры.
3. Если вам хватает пары тройки серверов где вы можете запустить docker compose - вы в порядке (если можете нагрузку балансировать). Если уже не хватает - ну, пора запастись кофе и на пару недель впереться в мир Подов и Деплойментов
В любом случае, Kubernetes - это не серебряная пуля как некоторым кажется. Можно, конечно, и одно приложение туда перетащить, но надо ли вам тратить ресурсы на поддержку - решать вам.
Кубер это оркестратор с достаточно широкими возможностями автоматизации.
Он не имеет смысла если у вас парочка компонентов, которые вы запускаете на одном хосте.
В первую очередь кубер это кластер, то есть предполагается отказоустойчивость если одна из нод выйдет из строя.
Во вторую очередь это огромное количество сущностей кубера, типа секреты, конфигмапы, которые позволяют оркестрировать енвайрнменты с десятками и сотнями подов, с возможностью автоматического масштабирования в декларативном виде.
В третью, большое количество интеграций с внешними системами при помощи раннеров, что позволяет сделать ci/cd, разграничить его по правам и так далее, объединиться с каким-нить hashicorp vault при помощи парочки аннотаций и так далее.
1 нет задачи он решает другие
2 а если ты пишешь 100 проектов, или проект большой и на 100 серверов, а если людей сотни? В разрезе одного небольшого проекта кубер не нужен
3 2-3 сервера это такой домашний пет проект если что
Простой
Сложный
