Сергей Бондарев, архитектор Southbridge и спикер курса «Kubernetes: Мега-поток» рассказывает в интервью, что делать, когда люди хотят закручивать шурупы молотком, как заглянуть в кишки кластера и почему open source-инструмент может погубить его же комьюнити.
— Начнём с того, что первая «Мега» у нас оказалась третьим мероприятием за десять дней и, соответственно, я на всех этих трёх мероприятиях выступал. К моменту начала «Меги» я уже полностью сорвал голос, и ребята, которые микшировали звук, постоянно увеличивали мне усиление на микрофоне. К третьему дню мне сказали: «Ты хотя бы погромче говори, потому что нам уже там некуда выкручивать».
Из других воспоминаний могу отметить, что место было хорошее. Это был дом отдыха, с баней и бассейном. Однако был ноябрь, погодка стояла не очень, но мы всё равно ведь целый день сидели в зале и посвящались в Kubernetes, так что невелика потеря. Было весело, все были молодые, всем было клёво.
С точки зрения посещения «Меги» — было много людей, и некоторые сразу после «Базы» оставались и на «Мегу». Честно говоря, по большей части то, что мы давали на «Меге» вызывало затруднения в понимании у этих студентов, потому что «Мега» была и по-прежнему рассчитана на более вдумчивое использование Kubernetes, на людей, которые имеют опыт работы с ним.
— Как сильно «Мега» изменилась сейчас?
— По большей части какие-то темы стали неактуальными, какие-то темы были переписаны и переделаны полностью, но процентов 50% тем осталось точно такими же. Мы перед каждым стартом курса проводим актуализацию материала, то есть проверяем, как практики работают в новых версиях Kubernetes, правим все манифесты, обновляем все версии, смотрим на новые фишки и добавляем это в лекции.
Грубо говоря, объяснить, как она изменилась, можно через фразу «берём ченджлог Kubernetes и вырезаем из него всё, о чём мы рассказываем на лекциях».
— Ты косвенно уже ответил, но всё же — в чём была идея «Меги» изначально?
— Курс мы задумали после самого первого образовательного проекта Слёрма, который позже эволюционировал в «Kubernetes Базу». Тогда к нам приехало много людей, которые работали с k8s.На первое мероприятие, которое было по сути пилотным, мы приглашали знакомых, знакомых знакомых и так далее. Так что контингент был продвинутый и фидбэк был такой: «Вы много и классно рассказали, но мы хотим большего, хотим кровь, кишки, залезть внутрь кластера и посмотреть, что там внутри происходит». Это нужно было, чтобы те, кто знал и понимал, как это устроено, устаканили бы свои знания, а те, кто не знал совсем, всё-таки влились в это дело.
Мы с Пашей сказали: хорошо, мы подумаем. И результатом нашего мыслительного процесса стала «Мега», где половина лекций была посвящена тому, как устроен внутри Kubernetes, какие там есть возможности, которые надо всегда использовать, потому что эти возможности повышают безопасность Kubernetes, но по умолчанию они отключены; и вторая половина — это как можно с помощью Куба делать такие вещи, как запуск баз данных внутри Kubernetes, интеграция с Vault, бэкапы в k8s и так далее.
— То есть можно сказать, что «Мега» ориентирована на практику с Kubernetes?
— Это, скажем так, тот этап знаний, который нужен для перевода тестового pet-проекта в жестокий продакшн.
— Люди же ленивые, поэтому видеокурс, который дали и сказали: вот тебе набор роликов и заданий, часто вызывает реакцию вроде «ну окей, на следующей неделе займусь, может быть через месяц». А когда весь этот набор информации вываливается на человека за три дня, как это было на интенсивах, это тяжело, и мозги к вечеру у людей кипят однозначно.
С другой стороны, в очном офлайн-формате было проще, потому что куда ты денешься из зала — приходилось усваивать информацию. В онлайн-формате приходилось посложнее, потому что ты сидишь перед камерой, рассказываешь и видишь только то, что люди пишут в чат. Соответственно, у тебя 150 человек на курсе, а в чат пишет человек 30 от силы. Где все остальные, ты можешь только догадываться, возможно, поставили на запись, возможно, отлучились покурить.
По поводу концепции потока — здесь мы постарались взять плюсы от обоих форматов, мотивировать дедлайном по изучению темы, чтобы успеть задать вопросы спикеру по пройденным темам, но в то же время не пытаться слишком форсировать обучение, как на интенсиве. То есть темп в один ролик раз в три дня всё же гораздо более лоялен к студенту, но в то же время не даёт расслабиться.
— Прямо сейчас это видится так: я очень боюсь, что Kubernetes куда-то скатится, потому что происходит полная вакханалия с open source, и в итоге, грубо говоря, половина усилий расходуется не на продуктивные вещи, а на всякие рюшечки, которые на скорость не влияют.
А вторая проблема — людей много, у людей много разных мнений, и очень часто происходит так, что какую-либо классную фичу, которую хотели и просили пару-тройку лет, что для срока жизни Kubernetes достаточно много, добавляют, а её хейтят.
Это я говорил про фичу добавки в клиент Kubernetes возможности указывать несколько адресов для API-серверов, чтобы клиент мог выбирать из них рабочие и слать запросы на них. То есть речь про встроенный в клиент балансировщик, чтобы было не так, как сейчас — у нас есть один IP-адрес в конфиге, и мы вынуждены для обеспечения отказоустойчивости городить какие-то дополнительные балансировщики.
Очень много странных, на мой взгляд, людей пишут негативные мнения о том, что этот встроенный балансировщик не нужен, им хватит того, что предоставляют облака, что он ломает обратную совместить и прочую ересь и бред.
В итоге получается, что хорошие начинания на корню губят сами же пользователи.
— Звучит как опасение, будто Kubernetes погубит его же комьюнити?
— Легко!
У нас вот какая проблема: комьюнити выросло большое, а ситуация как с демократией — у кого глотка громче, тот и прав.
— Есть ли серьёзная разница между русско- и англоговорящим комьюнити?
— Тут будет совершенно неполиткорректный ответ. Разница даже не в комьюнити. Умных людей и там, и здесь хватает, это не проблема. Можно даже сказать, что их примерно одинаковое количество. Различие в отношении людей, которые не обладают большим набором знаний и не стремятся их приумножать, количество таких людей тоже сопоставимо в обоих комьюнити.
Проблема здесь в том, что наше комьюнити объявляется токсичным, а их комьюнити объявляется дружелюбным, потому что на любой тупой вопрос, который задаёт человек, не желающий разобраться самостоятельно, ему дают примерно такой же тупой ответ, и он радостно уходит.
А наши говорят примерно так: «Чувак, ты тупой, потому что задал тупой вопрос и, пожалуйста, расскажи, что тебе надо на самом деле? Потому что ты решаешь странную проблему неправильными способами. Скажи, в чём была первоначальная проблема». Потому что люди часто приходят и спрашивают: а как мне молотком закрутить шуруп?
Друзья с того полушария, в самом лучшем случае, скажут: возьми ударную отвёртку за 100500 миллионов денег, вставь её в шуруп и бей по отвёртке молотком. А наши спросят зачем тебе молоток, чтобы закрутить шуруп?, а в итоге окажется, что человеку надо два листика бумаги склеить.
— Есть архитектор, который занимается продуктом. У него все задумки о том, как нарисовать продукт таким образом, чтобы пользователю было удобно с ним работать, чтобы техподдержке было удобно его тамагочить, чтобы разработчиков можно было толпой натравить на проект, они его по частям разобрали и сделали.
Есть архитектор, который будет строить инфраструктуру. Он думает о том, как сделать её такой, чтобы выход из строя какой-то части ни на что не повлиял, чтобы было удобно её восстановить из бэкапов, чтобы сами бэкапы удобно было делать.
Есть архитектор, который ближе к безопасности, он будет думать о том, как защититься от внешних угроз, как профильтровать входящий трафик, где хранить credentials и secrets и прочее тому подобное.
«Мега» даёт информацию к размышлению для всех этих трёх архитекторов, но полностью их запросы не покрывает. Допустим, архитектор программных решений может взять из курса какие-то фишки, которые позволят его продукт интегрировать с Kubernetes, использовать его механизмы, чтобы продукт работал, например, балансировку трафика и тому подобное.
Архитектор инфраструктуры, «железячник», найдёт информацию, как клонировать виртуалки с узлами, подключая их по мере необходимости, про скейлинг кластера, про то, как делать бэкапы, копируя все манифесты и так далее.
Для архитектора по безопасности коротко: Vault наше всё. Как можно, особо не светя нигде никакие токены от Vault, динамически разрешать конкретному приложению постучаться в конкретный кусочек, взять только те пароли, которые ему нужны, которые ему дозволены, и всё это делать автоматически, со временем жизни в 30 минут.
Так что всем трём типам архитекторов в каких-то областях деятельности «Мега» будет полезной, но целиком на все их вопросы не ответит.
— Последний вопрос: кому «Мега» откровенно не нужна?
— Людям, которые увидели Kubernetes 3 дня назад. Не нужна она, естественно, менеджерским и продуктовым позициям.
Избыточна «Мега» будет для фронтендеров, бэкендеров, которые пишут только бизнес-логику приложения и, соответственно, у них есть специальный джун-миддл-сеньор, который отвечает за доставку запросов к их бизнес-логике.
Можно пойти от обратного и сказать, что она нужна всем, кто будет запускать Kubernetes в продакшн. Тем, кто будет отвечать за то, как их проект будет работать в продакшене, если это не страничка-заглушка с посещением два человека в неделю, конечно.
habr.com
Раньше к нам приходили знакомые знакомых
— Расскажи, какой ты запомнил первую «Мегу» и как она изменилась сейчас?— Начнём с того, что первая «Мега» у нас оказалась третьим мероприятием за десять дней и, соответственно, я на всех этих трёх мероприятиях выступал. К моменту начала «Меги» я уже полностью сорвал голос, и ребята, которые микшировали звук, постоянно увеличивали мне усиление на микрофоне. К третьему дню мне сказали: «Ты хотя бы погромче говори, потому что нам уже там некуда выкручивать».
Из других воспоминаний могу отметить, что место было хорошее. Это был дом отдыха, с баней и бассейном. Однако был ноябрь, погодка стояла не очень, но мы всё равно ведь целый день сидели в зале и посвящались в Kubernetes, так что невелика потеря. Было весело, все были молодые, всем было клёво.
С точки зрения посещения «Меги» — было много людей, и некоторые сразу после «Базы» оставались и на «Мегу». Честно говоря, по большей части то, что мы давали на «Меге» вызывало затруднения в понимании у этих студентов, потому что «Мега» была и по-прежнему рассчитана на более вдумчивое использование Kubernetes, на людей, которые имеют опыт работы с ним.
— Как сильно «Мега» изменилась сейчас?
— По большей части какие-то темы стали неактуальными, какие-то темы были переписаны и переделаны полностью, но процентов 50% тем осталось точно такими же. Мы перед каждым стартом курса проводим актуализацию материала, то есть проверяем, как практики работают в новых версиях Kubernetes, правим все манифесты, обновляем все версии, смотрим на новые фишки и добавляем это в лекции.
Грубо говоря, объяснить, как она изменилась, можно через фразу «берём ченджлог Kubernetes и вырезаем из него всё, о чём мы рассказываем на лекциях».
— Ты косвенно уже ответил, но всё же — в чём была идея «Меги» изначально?
— Курс мы задумали после самого первого образовательного проекта Слёрма, который позже эволюционировал в «Kubernetes Базу». Тогда к нам приехало много людей, которые работали с k8s.На первое мероприятие, которое было по сути пилотным, мы приглашали знакомых, знакомых знакомых и так далее. Так что контингент был продвинутый и фидбэк был такой: «Вы много и классно рассказали, но мы хотим большего, хотим кровь, кишки, залезть внутрь кластера и посмотреть, что там внутри происходит». Это нужно было, чтобы те, кто знал и понимал, как это устроено, устаканили бы свои знания, а те, кто не знал совсем, всё-таки влились в это дело.
Мы с Пашей сказали: хорошо, мы подумаем. И результатом нашего мыслительного процесса стала «Мега», где половина лекций была посвящена тому, как устроен внутри Kubernetes, какие там есть возможности, которые надо всегда использовать, потому что эти возможности повышают безопасность Kubernetes, но по умолчанию они отключены; и вторая половина — это как можно с помощью Куба делать такие вещи, как запуск баз данных внутри Kubernetes, интеграция с Vault, бэкапы в k8s и так далее.
— То есть можно сказать, что «Мега» ориентирована на практику с Kubernetes?
— Это, скажем так, тот этап знаний, который нужен для перевода тестового pet-проекта в жестокий продакшн.
Как не откладывать обучение
— «Мега» пережила много разных форматов (офлайн- и онлайн-интенсив, видеокурс) и вот теперь запустили формат потока. Как тебе этот формат?— Люди же ленивые, поэтому видеокурс, который дали и сказали: вот тебе набор роликов и заданий, часто вызывает реакцию вроде «ну окей, на следующей неделе займусь, может быть через месяц». А когда весь этот набор информации вываливается на человека за три дня, как это было на интенсивах, это тяжело, и мозги к вечеру у людей кипят однозначно.
С другой стороны, в очном офлайн-формате было проще, потому что куда ты денешься из зала — приходилось усваивать информацию. В онлайн-формате приходилось посложнее, потому что ты сидишь перед камерой, рассказываешь и видишь только то, что люди пишут в чат. Соответственно, у тебя 150 человек на курсе, а в чат пишет человек 30 от силы. Где все остальные, ты можешь только догадываться, возможно, поставили на запись, возможно, отлучились покурить.
По поводу концепции потока — здесь мы постарались взять плюсы от обоих форматов, мотивировать дедлайном по изучению темы, чтобы успеть задать вопросы спикеру по пройденным темам, но в то же время не пытаться слишком форсировать обучение, как на интенсиве. То есть темп в один ролик раз в три дня всё же гораздо более лоялен к студенту, но в то же время не даёт расслабиться.
Токсичное комьюнити
— Следующий вопрос более глобален: какие тенденции ты видишь для Куба и отвечает ли «Мега» этим тенденциям?— Прямо сейчас это видится так: я очень боюсь, что Kubernetes куда-то скатится, потому что происходит полная вакханалия с open source, и в итоге, грубо говоря, половина усилий расходуется не на продуктивные вещи, а на всякие рюшечки, которые на скорость не влияют.
А вторая проблема — людей много, у людей много разных мнений, и очень часто происходит так, что какую-либо классную фичу, которую хотели и просили пару-тройку лет, что для срока жизни Kubernetes достаточно много, добавляют, а её хейтят.
Это я говорил про фичу добавки в клиент Kubernetes возможности указывать несколько адресов для API-серверов, чтобы клиент мог выбирать из них рабочие и слать запросы на них. То есть речь про встроенный в клиент балансировщик, чтобы было не так, как сейчас — у нас есть один IP-адрес в конфиге, и мы вынуждены для обеспечения отказоустойчивости городить какие-то дополнительные балансировщики.
Очень много странных, на мой взгляд, людей пишут негативные мнения о том, что этот встроенный балансировщик не нужен, им хватит того, что предоставляют облака, что он ломает обратную совместить и прочую ересь и бред.
В итоге получается, что хорошие начинания на корню губят сами же пользователи.
— Звучит как опасение, будто Kubernetes погубит его же комьюнити?
— Легко!
У нас вот какая проблема: комьюнити выросло большое, а ситуация как с демократией — у кого глотка громче, тот и прав.
— Есть ли серьёзная разница между русско- и англоговорящим комьюнити?
— Тут будет совершенно неполиткорректный ответ. Разница даже не в комьюнити. Умных людей и там, и здесь хватает, это не проблема. Можно даже сказать, что их примерно одинаковое количество. Различие в отношении людей, которые не обладают большим набором знаний и не стремятся их приумножать, количество таких людей тоже сопоставимо в обоих комьюнити.
Проблема здесь в том, что наше комьюнити объявляется токсичным, а их комьюнити объявляется дружелюбным, потому что на любой тупой вопрос, который задаёт человек, не желающий разобраться самостоятельно, ему дают примерно такой же тупой ответ, и он радостно уходит.
А наши говорят примерно так: «Чувак, ты тупой, потому что задал тупой вопрос и, пожалуйста, расскажи, что тебе надо на самом деле? Потому что ты решаешь странную проблему неправильными способами. Скажи, в чём была первоначальная проблема». Потому что люди часто приходят и спрашивают: а как мне молотком закрутить шуруп?
Друзья с того полушария, в самом лучшем случае, скажут: возьми ударную отвёртку за 100500 миллионов денег, вставь её в шуруп и бей по отвёртке молотком. А наши спросят зачем тебе молоток, чтобы закрутить шуруп?, а в итоге окажется, что человеку надо два листика бумаги склеить.
Три разных архитектора и те, кого мы на курсе не ждём
— Внезапно возник следующий вопрос: насколько архитектору будет полезна «Мега»?— Есть архитектор, который занимается продуктом. У него все задумки о том, как нарисовать продукт таким образом, чтобы пользователю было удобно с ним работать, чтобы техподдержке было удобно его тамагочить, чтобы разработчиков можно было толпой натравить на проект, они его по частям разобрали и сделали.
Есть архитектор, который будет строить инфраструктуру. Он думает о том, как сделать её такой, чтобы выход из строя какой-то части ни на что не повлиял, чтобы было удобно её восстановить из бэкапов, чтобы сами бэкапы удобно было делать.
Есть архитектор, который ближе к безопасности, он будет думать о том, как защититься от внешних угроз, как профильтровать входящий трафик, где хранить credentials и secrets и прочее тому подобное.
«Мега» даёт информацию к размышлению для всех этих трёх архитекторов, но полностью их запросы не покрывает. Допустим, архитектор программных решений может взять из курса какие-то фишки, которые позволят его продукт интегрировать с Kubernetes, использовать его механизмы, чтобы продукт работал, например, балансировку трафика и тому подобное.
Архитектор инфраструктуры, «железячник», найдёт информацию, как клонировать виртуалки с узлами, подключая их по мере необходимости, про скейлинг кластера, про то, как делать бэкапы, копируя все манифесты и так далее.
Для архитектора по безопасности коротко: Vault наше всё. Как можно, особо не светя нигде никакие токены от Vault, динамически разрешать конкретному приложению постучаться в конкретный кусочек, взять только те пароли, которые ему нужны, которые ему дозволены, и всё это делать автоматически, со временем жизни в 30 минут.
Так что всем трём типам архитекторов в каких-то областях деятельности «Мега» будет полезной, но целиком на все их вопросы не ответит.
— Последний вопрос: кому «Мега» откровенно не нужна?
— Людям, которые увидели Kubernetes 3 дня назад. Не нужна она, естественно, менеджерским и продуктовым позициям.
Избыточна «Мега» будет для фронтендеров, бэкендеров, которые пишут только бизнес-логику приложения и, соответственно, у них есть специальный джун-миддл-сеньор, который отвечает за доставку запросов к их бизнес-логике.
Можно пойти от обратного и сказать, что она нужна всем, кто будет запускать Kubernetes в продакшн. Тем, кто будет отвечать за то, как их проект будет работать в продакшене, если это не страничка-заглушка с посещением два человека в неделю, конечно.
Кровь, кишки и глубинные миры кластера Kubernetes. Как «Мега» помогает перевести тестовый pet-проект в жестокий продакшн
Сергей Бондарев, архитектор Southbridge и спикер курса «Kubernetes: Мега-поток» рассказывает в интервью, что делать, когда люди хотят закручивать шурупы молотком, как заглянуть в кишки кластера и...
habr.com