Павел Селиванов — основной спикер на интенсивах по Кубернетес (Слёрм-2 для тех, кто только знакомится с технологией и МегаСлёрм для тех, кто уже работает с Кубернетес).
25–27 октября — Слёрм-2
29–31 октября — МегаСлёрм
Если вы зарегистрируетесь до 18 октября, скажите менеджеру «я с вебинара», и вам сделают скидку 10%.
Слёрм-3 намечен на июнь '19.
TL;DR вебинара:
1. Если вы рассчитываете на волшебную таблетку, которая сама по себе решит ваши проблемы, то Kubernetes вам не нужен. На этом можно закончить просмотр/чтение.
2. Мой первый опыт с k8s
Было 50 микросервисов, хаос в эксплуатации, Docker, отсутствие оркестрации, выкатка сервисов в духе «сегодня релиз, даунтайм 2 часа».
Внедрили Kubernetes (параллельно внедряли Docker Swarm и Nomad, Docker Swarm не прижился):
Мы строили инфраструктуру, а не Кубернетес.
3. Плюсы и минусы Кубернетес относительны: то, что для одного — плюс, для другого — минус. Поэтому холивар о них никогда не утихнет.
4. «Минусы» Кубернетес
— На сегодня Кубернетес — не вполне цельное и готовое решение, скорее конструктор. Там можно допилить под себя любой функционал, но его кто-то должен пилить, а если нужный функционал не создать, кластер будет неполноценным. Поэтому команда сопровождения потратит кучу времени на сопровождение Кубернетес.
— Кубернетес покрывает огромное количество аспектов инфраструктуры. Придется изучить, как они работают и как их чинить. Узкий специалист (сетевик, SRE инженер) вынужден превращаться в специалиста по Кубернетес.
— Кубернетес из-за внутренней подвижности требует особенного отношения к мониторингу и хранению логов.
5. Приложения должны разрабатываться под Kubernetes или по крайней мере под Docker. Кубернетес рассчитан на микросервисы. Запускать в кластере монолиты проблематично.
6. Кубернетес позволяет контролировать огромное количество аспектов жизненного цикла приложений. Мое мнение: хорошо бы этот контроль передать разработке. Самое страшное, что я слышал от разработчика: «Почему я должен думать о ресурсах, я хочу просто писать код».
7. Вам не нужен Кубернетес, если вы думаете:
— Кубернетес изменит мой бизнес (или как минимум IT-департамент) и все заработает.
— Я читал о Кубернетес на хабре, интересная тема.
— Хочу как у Google…
8. Есть пессимисты Кубернетес, которые им попользовались, сказали «говно» и выкинули.
Есть оптимисты Кубернетес, готовые бороться с чем угодно, лишь бы у них был Кубернетес.
И есть реалисты Кубернетес, готовые к тому, что огромное количество вещей нужно будет контролировать через Кубернетес, нужно будет его глубоко изучать и допиливать. Реалисты получают:
— встроенные решения для многих задач;
— единообразие (например, больше нет проблемы, что staging разошелся с production);
— self-healing и как следствие 99,9% SLA.
9. О наболевшем: об ожидании от курсов
Я постоянно сталкиваюсь с тем, что люди рассчитывают на выходе с курсов получить специалиста. Так это не работает.
Курсы (в частности Слёрм) — это хороший старт в технологии. Сам я курсы не люблю, был на них два раза в жизни, но именно после курсов заинтересовался Docker и начал с ним разбираться. После курсов у вас появляются вопросы, по которым вы занимаетесь саморазвитием.
Курсы — это опыт лекторов, уже сделавших свои ошибки и собравших свои шишки.
Курсы — это возможность задавать вопросы и получать ответы. В отличие от комьюнити, я как лектор вынужден отвечать на вопросы и нести ответственность за свои слова.
Приятный бонус — общение с коллегами.
10. 3 дня обучения на Слёрме заменяют 3 дня чтения документации + 1 месяц практических экспериментов + полгода эксплуатации. То есть экономят время. Но Слёрм (как и самостоятельное изучение) не гарантирует, что вы станете специалистом по Кубернетес.
На 37 минуте начинаются ответы на вопросы участников.
Комментарии (10)
stul5tul
16.10.2018 20:35Кубернетес рассчитан на микросервисы. Запускать в кластере монолиты проблематично.
Вы про заморочки со stateful?
aSkobin Автор
17.10.2018 00:00Павел пишет:
Я про очень большое количество заморочек.
Взять тот же вордпресс — очень много модулей просто ломается когда приложение запущено в несколько инстансов (что очень желательно для k8s).
Ну или то же потребление ресурсов. Согласитесь что распихать по нодам пяток небольших микросервисов проще чем один жирный монолит.gecube
17.10.2018 02:36Вообще я не очень уверен, что это правильная идея. Объясню — запускать куб на маленьких нодах изначально гиблая идея. Для теста = ок. Для прода — такое себе. Получается — либо куб будет на жирном bare-metal, либо куб будет на (относительно) жирных VMках. Иначе смысл какой?
И понятия «жирный монолит» у всех свои. Одно дело — 4 ядра/8ГиБ ОЗУ (средненько так по нынешним меркам) или нечто, что ест процессоры и ОЗУ не в себя (>32ГиБ).
stul5tul
17.10.2018 15:24Взять тот же вордпресс — очень много модулей просто ломается когда приложение запущено в несколько инстансов (что очень желательно для k8s).
Дык это о другом, вовсе не о
Кубернетес рассчитан на микросервисы. Запускать в кластере монолиты проблематично.
А о том, что монолит некий не предназначен для запуска на нескольких инстансах.
Вполне себе гоняем монолиты под Kubernetes не первый год. В нескольких инстантсах. Полет нормальный. Разумеется, при их создании учтена возможность работы таковой.
stul5tul
16.10.2018 20:40Внедрили Kubernetes (параллельно внедряли Docker Swarm и Nomad, Docker Swarm не прижился)
Зачем параллельно Kubernetes'у Consul — еще могу понять.
Но зачем ему «параллельный Nomad»?
Можно пояснить, — что вы имели ввиду?gecube
16.10.2018 20:43+1Я так понимаю, что пробовали разные, альтернативные варианты оркестратора. Куб победил (это данность, но я не могу сказать, что я, например, в восторге от его кода — реально индусы писали )))
На самом деле я открою Америку: кубернетес — это не просто оркестратор. По сути — это менеджер ресурсов. Также как и Yarn, Nomad, Mesos, Consul Connect и пр. Просто в случае того же Yarn — нагрузкой выступают java-приложения. А k8s — распределенный менеджер ресурсов, который принимает нагрузку в виде докер-образов, т.е можно писать на своем любимом языке программированияaSkobin Автор
17.10.2018 00:03Зачем параллельно Kubernetes'у Consul — еще могу понять.
Но зачем ему «параллельный Nomad»?
Я так понимаю, что пробовали разные, альтернативные варианты оркестратора.Именно так. Параллельно с кубом (причем это решение в том числе перешло и в продакшен тестирование) использовался Nomad. На тот момент (2 года назад) для нас не было очевидно какое из двух решений лучше себя покажет и больше нам подойдет.
© Павел Селиванов
KirEv
17.10.2018 03:06отталкиваться, в любом случае, нужно от амбиций бизнеса (в контексте клиент\потребитель\etc), и если приложение изначально не подразумевает масштабирование (горизонтальное\вертикальное), особенно если оно впихнуто в докер (компосер) и запускает инстанс бд в докере и приложение в докере — всеравно k8s не решит задачу масштабирования из коробки.
технологии, конечно, прекрасны (без сарказма, искренне), но тем не менее с несколькими миллионами очень активных клиентов вполне справится VDS в количестве менее десяти (ессно в зависимости от сложности приложения и его архитектуры)… так как гляда на цены aws, gc, etc — раскошелиться на это может себе реально крупная компания… выгднее при большой активности — несколько vds, чем тот же aws, который, к слову, может вдруг взять и регион отрубить от www (были приценденты).
оттого с любопытством и читаю публикации от мейл груп, баду, убер (хоть 95% перевод), етс.
PS: у меня локально, с debian 9, с трудом еле еле получалось заставлять работать k8s, устаканилось страшное впечатление как ЭТО использовать в проде, так как на сранном, хоть и топовом (i7 8700k, 32gb 3600Mhz ram) ПК это удавалось с большим трудом (собсна из-за докеров и т.п. на 100% перешел на линукс)…
PS^ а дота и из под линукса норм канает… больше от винды и не надо
PS^^ а фоношоп, коль макет прилетит рас в тыщу лет — так виртуалка с вин10 есть из под VMware
gecube
Резюме вебинара прекрасная (во всех смыслах и без шуток).
Покажу-ка я его коллегам ;) Вдруг начнут работать.
Еще очень интересная тема (и не затронутая) — использование minikube/minishift и OKD именно ТОЛЬКО для разработки. Потому что одно дело production, а другое — скорость тестирования. К тому же, иногда можно пожертвовать однообразностью production/dev/staging.
gecube
За сольт — тоже палец вверх.