27.02.2021 16:15:57 |
Автор: Когда компании пора внедрять микросервисы? Как быть
разработчику, который хочет или которого заставляют использовать
Kubernetes? Где ответственность разработчика, а где админа? Кто
виноват, если после внедрения прилёг продакшен? Об этом говорили на
круглом столе учебного центра Слёрм и облачной платформы Mail.ru Cloud
Solutions.
Под катом текстовая запись разговора.
Участники круглого стола:
- Марсель Ибраев, CTO Слёрма, сертифицированный администратор Kubernetes.
- Сергей Бондарев, администратор с более чем 20 годами опыта, Southbridge.
- Павел Селиванов, senior DevOps engineer в MCS.
- Дмитрий Лазаренко, директор по продукту в MCS, разработчик на Java.
- Виктор Гамов, Developer Advocate в Confluent (ведущий митапа).
Встреча приурочена к старту онлайн-интенсива Kubernetes для разработчиков. В числе спикеров: Сергей Бондарев, Марсель Ибраев и Павел Селиванов. Интенсив начнётся 3 марта, успевайте!
Когда компании пора внедрять Kubernetes?
ВИКТОР ГАМОВ: В своих подкастах и шоу я всегда говорю, что мы как разработчики должны помогать бизнесу существовать. Все наши свистелки, моторчики и прочие клёвые штуки, которые мы сегодня нашли на GitHub, а завтра хотим отправить в прод, тоже должны работать на бизнес. Поэтому давайте подумаем, зачем компании Kubernetes и когда его пора внедрять?
ПАВЕЛ СЕЛИВАНОВ: У меня есть хороший ответ: когда CTO начитался Хабра и таки заметил слово Kubernetes. Срочно нужно тащить к себе!
ВИКТОР ГАМОВ: Отлично. Еще какие версии? На самом деле, ребят, не делайте так. Технические решения внедряют, чтобы решить какую-то конкретную проблему. Какую проблему решает Kubernetes?
ДМИТРИЙ ЛАЗАРЕНКО: В Mail.ru Cloud Solutions есть не только Kubernetes-как-сервис, но и Kubernetes внутри, для собственной разработки. Несколько лет мы жили просто деплоем на bare metal с помощью Ansible. У нас классическая эксплуатация: SRE-инженеры (как сейчас любят себя называть админы) и много команд разработки. Админы всё катили, всё верифицировали и стали узким горлышком. Разработчики перформили гораздо больше, чем могли выкатить админы.
Переход на Kubernetes решил проблему. Сейчас разработчики могут сами выкатывать и эксплуатировать свой сервис, разбираться, что происходит внутри. Фактически они выступают в роли DevOps/SRE, то есть отвечают в том числе и за успешность работы этого сервиса.
Когда мы работали в Ansible и делали подборки на Docker, такого не получалось. Перемены заняли примерно год. Паша [Павел Селиванов] как раз очень активно помогал с переходом на Kubernetes и внедрением идеологии в мозги как админов, так и разработчиков.
ВИКТОР ГАМОВ: Ты сейчас подставился, когда сказал, что разработчики могут доставлять кода больше, чем админы способны поддержать. Нужны ли нам админы, если они не могут поддержать и доставить годноту, которую выкатывают разработчики?
ДМИТРИЙ ЛАЗАРЕНКО: Это хороший вопрос для обсуждения, у меня есть мнение, но я не буду отвечать первым.
ПАВЕЛ СЕЛИВАНОВ: Всё зависит от специфики конкретной компании, инфраструктуры и области бизнеса. Понятно, что когда мы строим облако, мы категорически не можем обходиться без админов, причем админов в классическом смысле слова. Мы эксплуатируем железки в дата-центрах, и их нужно обслуживать: подключать, настраивать, задумываться о рейдах, дисках, процессорах, памяти и т. д.
При этом, учитывая развитие облаков, подходов DevOps и Infrastructure as a Code, многие компании могут обходиться без классических админов. Но скорее всего, без людей, которые отвечают за эксплуатацию и инфраструктуру, не могут. Всё же нужен тот человек, который это на себя возьмет. Но не факт, что он обязательно должен быть админом от сахи, человеком, который пришёл из железок.
ВИКТОР ГАМОВ: То есть если вы деплоите Kubernetes у себя, всё равно должны быть люди, которые немножечко в этом разбираются. Другой вопрос: должны ли разработчики иметь доступ к продакшену?
ПАВЕЛ СЕЛИВАНОВ: Отвечу по своему опыту. Я наблюдал не в одной компании, как это работает. Принцип разделения, когда к продакшену имеют доступ только отдельные люди, конечно, прекрасный. Но как происходит в реальности: есть разработчик, который знает, что ему надо сделать, как это работает, как это осуществить; есть админ с доступом; они объединяются. Разработчик ставит стульчик рядом с рабочим местом админа и на ухо рассказывает тому, что нужно делать. Админ нажимает кнопочки, при этом периодически нажимает что-то не то.
То есть на практике разделение ответственности приводит к лишним затратам человеческих ресурсов, потому что то, что может делать один человек, делают два. Плюс необходимость взаимодействия между специалистами увеличивает количество ошибок.
Отвечая на твой вопрос: мне кажется, что в очень небольшом количестве компаний безопасность выстроена так, что разработчик действительно не может получить доступ к продакшену. Здесь скорее Security through obscurity (безопасность через неясность) получается.
ВИКТОР ГАМОВ: Но если разделение обязанностей мешает, как найти виновного тогда? Вот деплоили, что-то не заработало, у нас убытки, кто виноват?
ПАВЕЛ СЕЛИВАНОВ: Расскажу, как мы в MCS решаем эту проблему. За сервис в любом случае отвечает разработчик, который его разрабатывал. Мы идём в таком направлении: команда разработки сервис пишет, она же за него и отвечает, и она же его эксплуатирует. Когда сервис сломался, задача разработки понять, что там сломалось и найти ответственных за этот компонент. Понятно, что если сломалась база данных, которую предоставляет команда сопровождения, то разработка вряд ли пойдёт поднимать эту базу данных, но задача разработки разобраться и поднять нужных людей.
ВИКТОР ГАМОВ: У нас как раз следующий вопрос связан с этим рассуждениями.
За что отвечают разработчики, а за что DevOps при работе с Kubernetes? Кто более компетентен?
ВИКТОР ГАМОВ: Вот Паша говорит, что разработчики должны поддерживать то, что они написали. Как по мне, это история не про поиск виноватых, а про делегирование и доверие команде. Когда людям предоставляют возможность доказать, что они могут, они начинают немного по-другому мыслить. Начинают работать не с девяти и до обеда, а ради цели.
ДМИТРИЙ ЛАЗАРЕНКО: Это про вовлечение разработчиков, когда они перестают быть кодерами и становятся архитекторами сервисов. Они становятся причастными к созданию чего-то великого, ну и к провалам в том числе, если что-то идет не так.
ВИКТОР ГАМОВ: Поэтому мне всегда больно видеть термин DevOps в значении человек, а не в значении культура. Необходимо изменять сознание и подходы к тому, как работают люди, иначе никакие технологии нам не помогут. Нам необходимо менять культуру и восприятие людей. Кто со мной поспорит?
СЕРГЕЙ БОНДАРЕВ: Культура, конечно, вещь хорошая, но не главная. Ты можешь быть сколь угодно культурным, но если у тебя нет компетенций, тебя ждут только великие провалы.
ВИКТОР ГАМОВ: То есть тот, кто более компетентен, тот и берёт на себя ответственность? Есть админы, есть опсы, кто из них важнее на проекте?
СЕРГЕЙ БОНДАРЕВ: Наверное, никто из них. Продукт оунер, скорее.
ПАВЕЛ СЕЛИВАНОВ: Архитектурный комитет.
ВИКТОР ГАМОВ: Ага, то есть никто. Если есть архитектурный комитет, то дело может сильно затянуться. Марсель, у тебя какие соображения?
МАРСЕЛЬ ИБРАЕВ: Соглашусь, что никто не главный, но зоны ответственности разные. Есть инфраструктурная команда, и все-таки ключевые решения по инфраструктуре, я думаю, за ними. А разработчики уже решают, что и как кодить под эту инфраструктуру, какие инструменты использовать. При этом в идеальном мире должна происходить синергия, и решаться всё это должно не лоб в лоб, а сообща.
ВИКТОР ГАМОВ: Я ждал, кто первым скажет слово синергия. Ты выбиваешь булшит-бинго!
ДМИТРИЙ ЛАЗАРЕНКО: Я добавлю. Паша говорил про архитектурный комитет. В чём сложность ситуации? Вот откройте карту CNCF: там сотни проектов, сотни сервисов, и все это новое. В реальности мало кто годами использовал, например, Istio. И на вопрос, кто главный при выборе Istio, ответ: да хрен его знает. Потому что кто глубже копнет, разберётся и аргументированнее даст ответ, тот и главный. Часто эти люди первопроходцы. И это одна из проблем.
ВИКТОР ГАМОВ: Я сейчас вброшу, а вы поспорьте со мной. В чём DevOps меняет восприятие разработки, так это в том, что можно проводить эксперименты и изучать технологии прямо в процессе. Благодаря Kubernetes мы можем делать AB-тестинг: например, на одной части контура использовать Istio, на другой части ещё какого-нибудь вендора. Таким образом обучение идёт сильно быстрее. Поэтому Kubernetes это не платформа, это базис для построения ваших платформ. В этом смысле он совершенно потрясающий.
ПАВЕЛ СЕЛИВАНОВ: Вот именно, что Kubernetes это не законченная вещь, это конструктор, который нужно собрать под себя. Я видел в нескольких проектах такое разделение: некие мифические DevOpsы строят платформу для разработки, чтобы разработчик мог как можно меньше заморачиваться на этапе разработки по поводу инфраструктурных моментов, меньше ломать, если что-то пойдет не так, и как можно более гибко её использовать. Вот DevOpsы строят платформу на основе Kubernetes, разработчики её эксплуатируют, то есть запускают там свои сервисы, деплоят то, что им нужно, настраивают между ними связи и так далее.
СЕРГЕЙ БОНДАРЕВ: Можно мне поныть на тему изучения новых технологий. Неумеренность в этом вопросе приводит к тому, что приходишь на проект, видишь кучу новых слов, начинаешь в них разбираться, и оказывается, что часть технологий уже прекратила своё развитие, часть из них ещё в глубокой альфе. Но разработчики категорически настаивают, что они хотят это использовать, им это необходимо, и вообще по-другому они никак не могут жить. И тут задача опсов убедить разработчиков, что какие-то вещи ещё рано использовать, а какие-то поздно.
ВИКТОР ГАМОВ: Тут речь как раз про культуру. Когда в команде есть доверие, сложные вопросы решаются легче.
Что для вас знать Kubernetes?
ВИКТОР ГАМОВ: Что для вас знание Kubernetes? Знание ключей и опций kubectl? Архитектуры? Компонентов? Отличий от Docker и Docker Compose? Сертификаты CKA/CKAD? Расшифруйте, чтобы, выровнять понятийный уровень. Что важнее: сертификаты или опыт?
МАРСЕЛЬ ИБРАЕВ: Знания, конечно. Но сертификат штука приятная. Вы можете указать длинный списочек: ваши регалии, грамоты школьные приложить.
ВИКТОР ГАМОВ: Какие сертификаты получат слушатели курса по Kubernetes для разработчиков? Или курс больше нацелен на получение практических знаний?
МАРСЕЛЬ ИБРАЕВ: Мы всегда делали акцент на практику. Наша цель не подготовить к сертификации, а подготовить к применению знаний на практике. В первую очередь знание, а нужен сертификат или нет, каждый решает сам.
СЕРГЕЙ БОНДАРЕВ: Система сертификации пришла к нам, наверное, с Запада. Она рассчитана на то, что незнакомый человек посмотрит на твою доску почета и проникнется, поймёт, что какой-то дядя проверил твои знания и выдал бумажку, что ты вот эту штуку знаешь хорошо. Если он этому дяде доверяет, значит, сертификат хороший. Если это выдано какой-нибудь Районной Академией Наук, то, наверное, сертификат не очень. Сертификация тоже бывает очень разная.
С тех пор как за сертификацию начали брать деньги, это стало отдельным бизнесом. Ситуация такая: если я сделаю нормальную сертификацию, на которой задаются действительно сложные вопросы, никто не придет ее сдавать, я не получу своих денег, поэтому сертификацию мы делаем по низу средних способностей, чтобы хотя бы 70-80% людей, которые к нам приходят, ее сдавали. Другая крайность брать за сертификацию большие деньги, делать ее сложной и ожидать, что придет мало людей, но за этих людей будет платить работодатель. А компаниям, в которых работают крутые специалисты, сертификация особо и не нужна: они уже знают, что у них есть крутые специалисты, зачем их сертифицировать.
ВИКТОР ГАМОВ: Дима или Паша, когда к вам приходят соискатели на вакансию SRE или разработчика, вы смотрите на сертификаты? Или делаете прожарку тестовым заданием?
ДМИТРИЙ ЛАЗАРЕНКО: В MCS мы не смотрим на сертификаты. А смотрим на то, как человек подходит к решению проблемы, насколько попытается разобраться в причине, как коммуницирует с другими людьми (это уже история про софт-скилы), и в целом, насколько разбирается в архитектуре, понимает репликацию в базах данных или как работает Kubernetes. Это лучше, чем просто формальная сдача экзамена на сертификат. Мы смотрим на problem-solving и на то, как ты коммуницируешь с другими людьми во время решения проблемы. Потому что герои-одиночки, которые могут быть токсичными, никому не интересны. Мы отказывали людям, которые не могут хорошо общаться с командой, но при этом очень крутые технические специалисты.
ПАВЕЛ СЕЛИВАНОВ: Когда проходишь собеседование и говоришь, что есть сертификат, обычно на это отвечают: Ага, давайте к следующему вопросу. Мне кажется, сертификаты, особенно кубернетесовские, в основном нужны компаниям. Я работал в двух компаниях, у которых есть сертификация Linux Foundation от CNCF. Соответственно, чтобы компании пройти такую сертификацию, в штате должно быть определённое количество специалистов, которые сертифицированы как администраторы или девелоперы Kubernetes. Это тот случай, когда реально стоит пройти CK или CKD. Если вы думаете, что CK или CKD поднимет зарплату или увеличит шансы устроиться на работу, то вы, вероятно, ошибаетесь. По крайней мере, в России на эту бумажку вообще никто не смотрит.
В какой момент среднестатистическому разработчику стоит задуматься об умении использовать Kubernetes?
ВИКТОР ГАМОВ: Стоит ли полагаться на разработчиков при внедрении или лучше найти DevOps-инженера?
ПАВЕЛ СЕЛИВАНОВ: Что касается внедрения Kubernetes и вообще любых инфраструктурных вещей Если вы стартап, вам надо просто запуститься и показать, какая ваша разработка крутая, то можно обойтись без выделенного человека. Дальше, я боюсь, если вы не наймёте такого человека, то у вас в команде быстренько найдется разработчик, на которого все это свалится. И тут всё зависит от того, хотел разработчик, чтобы на него это свалилось, или не хотел. Он может проклясть вас, а может, и наоборот, обрадоваться, что больше не надо писать эти дурацкие бизнес-приложения.
Отвечая на вопрос, насколько разработчику вообще необходимо уметь использовать Kubernetes, я бы не стал этим заморачиваться до тех пор, пока в компании нет Kubernetes или нет возможности его использовать. Но как только админы или DevOps припрут Kubernetes, вам так или иначе придётся с ним разобраться. Потому что вряд ли вам сразу же напишут красивые дашборд-кнопки, которые нажимаешь и всё разворачивается. Придётся узнать, что такое поды, реплика-сеты, деплойменты, зачем нужны стейтфул-сеты и почему не надо писать в Kubernetes базу данных.
ВИКТОР ГАМОВ: Ты ведь из облачного провайдера, почему ты не говоришь, что cloud-провайдер даёт тебе не просто голый Kubernetes, a managed-Kubernetes, снимает головняк?
ДМИТРИЙ ЛАЗАРЕНКО: Дьявол в деталях. Наверное, самое интересное начинается, когда вы внедрили Kubernetes и первый раз прилёг продакшен. Что происходит потом, можно долго описывать. Разработчик должен понимать все эти примитивы внутри Kubernetes, он должен понимать интеграцию с разными инструментами: зачем ему Prometheus, какие метрики нужно мониторить, как настроить алёрты, как использовать все фишки Prometheus и как правильно работать с логами.
Без понимания эксплуатации всё становится грустно, и приложение чинится сутками. DevOpsы не понимают бизнес-логику работы приложения, а разработчики не понимают, как работает Kubernetes и что там сломалось. Одна из ключевых проблем, которая была в начале с OpenShift, в том, что никто не понимал, как вся эта машина работает. С Kubernetes всё становится попроще, потому что там прям такие кубики. Но в кубиках нужно разбираться. Часть, которая связана с эксплуатацией и реальной жизнью, не менее важна, чем просто научиться ямлики писать.
ВИКТОР ГАМОВ: То есть ты хочешь сказать, что мало знать Java, например, или Golang, и разбираться, как алгоритмы на них написать, ещё нужно понимать, где и как это будет выполняться? Мало того что это будет выполняться в какой-то среде, так эта среда ещё не настоящая. Потому что вокруг этой среды ещё много всего.
ДМИТРИЙ ЛАЗАРЕНКО: Не совсем так. Kubernetes в этом отношении даёт унификацию. В целом понятно, какая среда повторяемая. Пускай даже используются разные облачные провайдеры, но в целом все работает более-менее одинаково. Но среда всё равно непривычная, другая. Там ещё много всего вокруг, и оно может стрельнуть.
ВИКТОР ГАМОВ: Может быть, стоит провайдеру снимать эти головняки? У нас есть админы, которые умеют готовить Kubernetes, есть разработчики, которые в принципе знают, как писать приложение, но ещё им нужно понимать, как варить Kubernetes. Может быть, их кто-то встретит как раз хорошим сервисом, чтобы уменьшить головняк?
ДМИТРИЙ ЛАЗАРЕНКО: Идея хорошая, но это как с безопасностью. Если всё будет безопасно, работать будет невозможно. За всё приходится платить. За автоматизацию, о которой ты говоришь, приходится платить очень жёсткими правилами. К сожалению или к счастью, у нас мультикультурное общество, каждый думает по-своему, и невозможно придумать унифицированные правила для работы приложения. Все пытаются это делать, изобретают фреймворки, но идея утопична. Всякие спинакеры и подобные продукты позволяют унифицировать и упростить процесс CI/CD. Но это не единственный процесс. Обилие open source инструментов делает задачу нерешаемой. Да, облачный провайдер упрощает жизнь и позволяет системным администраторам и DevOps экономить время на выполнении рутинных операций, но это не серебряная пуля. Невозможно всё автоматизировать, иначе люди не нужны будут. И плюс у облачных провайдеров не столько разработчиков, чтобы сделать эту магическую оптимизацию.
СЕРГЕЙ БОНДАРЕВ: Cloud-провайдеры предоставляют набор готовых решений, в которые ты волей-неволей должен упихиваться. Если тебя этот набор удовлетворяет, то в принципе жить в облаке не проблема. Но иногда есть потребности или идеи, которые в облаке реализованы не так, как ты хотел. И ты отказываешься от каких-то частей cloud-решений, потому что они тебя не удовлетворяет по своим возможностям и своим ограничениям. Кроме того, облачные решения консервативны. Если что-то сломалось, чинить это будут долго. А сам ты себе это можешь поставить и нормально работать.
ВИКТОР ГАМОВ: Да, такое будет в любой managed-системе.
Зачем перегружать разработчика информацией, когда можно просто дать ему кнопку?
ПАВЕЛ СЕЛИВАНОВ: Это такой комплексный вопрос, столько сразу слоев. Давайте представим ситуацию: у нас есть бизнес, техническая команда решила, что им нужен Kubernetes, и вся бизнес-разработка останавливается, пока DevOpsы не напилят кнопку, которая удовлетворит все потребности разработчиков. Я думаю, что это нереальная ситуация. В любом случае разработчики будут жить с Kubernetes, сами будут с ним разбираться. Со временем, наверное, это взаимодействие будет уменьшаться, но я не верю, что это произойдёт быстро и разработчик избавится от необходимости знакомиться с Kubernetes.
Опять же, Kubernetes, да и микросервисы вообще, позволяют выкатывать фичи быстро. Так быстро, как это нужно бизнесу, при этом не сильно заморачиваться, как что-то работает под капотом. Гораздо проще написать простой микросервис, какую-нибудь фиговину, которая будет базу данных перекладывать в информацию в формат Json, чем действительно разбираться с новыми или старыми технологиями и писать что-то низкоуровневое. Мне кажется, Kubernetes как раз-таки позволяет удовлетворять современные требования бизнеса.
МАРСЕЛЬ ИБРАЕВ: Тут, конечно, вопрос, как Паша сказал, многослойный. И без привязки к кому-то примеру сложно сказать. Но если мы хостим всё у себя, без облаков, и при этом мы говорим, что у нас DevOps, то, мне кажется, DevOps у нас не получится, если не будет тесной взаимосвязи и понимания, что делает разработка, а что админы.
Что будет на курсе?
ВИКТОР ГАМОВ: Давайте конкретики добавим: что будет на курсе, что поможет, например, Java-разработчику разбираться глубже в вопросе деплоя?
МАРСЕЛЬ ИБРАЕВ: Кстати, вопрос, который был на слайде: что есть Kubernetes? Мы как-то без конкретики его пробежали. Можем вернуться и поконкретнее рассказать.
Что нужно знать разработчику: это, разумеется, основные абстракции куба в чем ваше приложение запускается и какие инструменты поддерживаются. Далее, вы хотите, чтобы ваше приложение работало только со stateful-данными, или вы хотите, чтобы ваше приложение запускалась на каждой ноде кластера, все это разные абстракции. Их определенно нужно знать и админам, и разработчику. Банальный пример: что-то не заработало, надо срочно фиксить. Инфраструктура, конечно, полезет и на крайний случай откатит. Но факт, что проблема возникла после деплоя, намекает: проблема может быть в коде, надо садиться и разбираться. Разбираться лучше уже на стейдже, поэтому какая-то база в голове должна быть.
ПАВЕЛ СЕЛИВАНОВ: Про курсы любят спрашивать: а что мне на курсе расскажут такого, чего нет в документации? зачем мне эти курсы нужны?. Я могу ответить, что в этом курсе гарантированно есть вещи, которых нет в документации.
Среди присланных вопросов был вопрос, как дебажить Java или что-то такое. Это вообще распространенная в Kubernetes штука: у вас есть продакшен, и естественно разработчики хотят прийти на продакшен, залезть в контейнеры и начать там на живых пользователях что-то дебажить. Вот что нужно знать разработчику про Kubernetes.
Про абстракции, джобы, стейтфул-сеты можно почитать документацию недельки чтения будет достаточно. А вот реальная эксплуатация кластера Kubernetes и задачи разработки С этими задачами вам админы не пойдут помогать. Как ваше приложение дебажить, какие инструменты для этого есть, как вам построить локальную разработку так, чтобы код, который вы пишете, одинаково хорошо работал в Docker, Docker-compose, Kubernetres и так далее. Как это все собирать между собой. Вот это те вещи, которые мы хотим разобрать в курсе.
Что использовать для локальной разработки под Kubernetes?
ВИКТОР ГАМОВ: Давайте по тулам поговорим. Здесь был вопрос, мне очень он нравится самому: Что думаете по поводу k3s как способе развернуть кластер и разобраться в его устройстве?.
СЕРГЕЙ БОНДАРЕВ: Это детище компании Rancher. k3s заявлялся как Kubernetes, который будет запускаться на холодильнике.
ВИКТОР ГАМОВ: Это такая штука, которая полностью обрезана.
СЕРГЕЙ БОНДАРЕВ: У него отрезано не так уж и много. Вырезаны облачные контроллеры и прочее, но самое главное, у него вырезан etcd, вместо него используется SK Light, и всё это работало на одной-единственной машинке, грубо говоря. Использовать эту штуку для изучения Kubernetes не самый лучший вариант. Проще и быстрее поставить себе Minikube, или почитать документацию, взять kubeadm в зубы и поставить его на машину с Docker из одного узла и на нём изучать.
ВИКТОР ГАМОВ: То есть ты поклонник подхода Kubernetes the Hard Way? Когда нужно пойти и разобраться.
СЕРГЕЙ БОНДАРЕВ: Я поклонник установки с помощью kubespray.
ВИКТОР ГАМОВ: А ведь мы не сказали, что Сергей Бондарев один из тех, кто коммитит в kubespray.
СЕРГЕЙ БОНДАРЕВ: Я в нём разбираюсь, время от времени чиню баги и дополняю функционал.
ВИКТОР ГАМОВ: Раз уж мы заговорили про тулы внедрения. Какая там сейчас обстановка? Раньше был капс, теперь есть kubeadm, k3s, kubespray что их отличает и что взять? Ты упомянул Minikube, но по моему опыту он достаточно капризный. Под MacOS, например, он очень странно жил.
СЕРГЕЙ БОНДАРЕВ: Это не ко мне вопрос. У меня всегда есть несколько виртуалок с Docker, которые объединены в локальную сеть. Я на них могу поставить что угодно. Необходимости поставить что-то на локальном компьютере у меня не возникает.
ВИКТОР ГАМОВ: k3s был популярен, потому что в нём обрезаны многие лишние вещи. Например, обратная совместимость
СЕРГЕЙ БОНДАРЕВ: Ну как же! Обратная совместимость это самое важное, что есть в Kubernetes.
ВИКТОР ГАМОВ: Мы ведь не говорим про использование k3s в продакшене. Речь про локальную разработку. Паша, как вы в Mail.ru разрабатываете вещи, которые пишете под Kubernetes?
ПАВЕЛ СЕЛИВАНОВ: Очень просто. Если мне нужно сделать что-то локально с самим Kubernetes, то есть разработать то, что я буду запускать в Kubernetes, это Minikube. С MacOS недавно только одну проблемы заметил: они по умолчанию перешли на использование драйвера Docker, там теперь запускается контейнер в контейнере. И в таком случае у него не работают ingress-контроллеры. Они просто изнутри Docker недоступны становятся. Пришлось откатиться локально, использовать Virtualbox или X-hive (встроенную маковскую виртуализацию).
Если нужно решать какие-то админские задачи: нужно что-то в самом кластере проверить, протестировать, как конфигурации какие-то будут работать, взаимодействие между нодами, я использую какое-то облако. В Google, AWS или даже у нас за бонусные баллы его легко получить. Поднимаю на виртуалке, настраиваю там Kubernetes и так далее.
Что касается самих установщиков: Kops это утилита номер один для развёртывания Kubernetes в облаке, для остальных случаев Kubespray.
ВИКТОР ГАМОВ: Марсель, Дима, есть что добавить по поводу тулов, что мы посоветуем разработчикам использовать локально?
МАРСЕЛЬ ИБРАЕВ: Для разработки действительно удобнее Minikube чтобы что-то локально потестить, посмотреть, потыкать. А если есть задача поизучать его, поковырять, разобраться в логике, в компонентах, то поддержу Сергея: лучше взять какой-нибудь kubeadm и развернуть хотя бы однонодный кластер, там уже будет что-то близкое к продакшену.
А что с безопасностью?
ВИКТОР ГАМОВ: Самый важный вопрос обсудить забыли: что у нас с безопасностью? Что есть в Kubernetes, что позволяет обеспечить безопасность.
ПАВЕЛ СЕЛИВАНОВ: В чатике как раз был вопрос, как в синергию админов и разработчиков вписать безопасников, то есть как сделать DevSecOps как создавать тулы безопасников, как их встраивать в общий пайплайн.
Что вижу я: в крупных компаниях безопасник это какой-нибудь отставной подполковник ФСБ, и последнее, что он делал, это Эльбрусы кольцом собирал. Задача безопасника подписывать бумажки и брать на себя ответственность. Поэтому тут вообще вопрос: когда бизнес перестанет воспринимать безопасников как людей, которые подписывают бумажки, и начнет их как людей, которые должны интегрироваться с остальным техническим отделом и идти в ту же сторону, использовать какие-то инструменты.
Инструментов на сегодняшний день огромное количество. Мне как DevOps инженеру, человеку, который пишет пайплайны, было бы интересно всё это дело в свои пайплайны встраивать, просто времени не хватает. Я бы хотел, чтобы кто-то этим занимался. Но у самого Kubernetes есть airbag, это встроенная фишка. Можно подключить какой-нибудь hashicorp vault, чтобы хранить секреты, это, наверное, самое распространенное. Есть еще штуки типа Open Policy Agent, который позволяет просматривать и писать конкретные правила под всё, что запускается в Kubernetes, делать свои собственные политики безопасности, настраивается все это очень гибко, проверяется и так далее. Есть инструменты, которые добавляют просто авторизацию в кластер и делают это нормально, типа Keycloack, Dex. Есть штуки, которые позволяют анализировать содержимое контейнеров, то, что вы собираетесь деплоить на свои продакшен-серверы. Например, Harbor, JFrog и т д. Инструментов огромное количество. Вопрос: кто бы ими занимался, потому что отставные подполковники явно не станут это делать.
ВИКТОР ГАМОВ: Поддержу Пашу. Сегодня безопасность перестаёт быть чем-то загадочным из серии мы сгенерировали ключи, запечатали в конверты и разослали. Есть набор совершенно понятных решений, которые надо внедрять. А вот всеми любимый Kerberos. Как делать Kerberos на Kubernetes?
МАРСЕЛЬ ИБРАЕВ: В Kubernetes точно есть инструментарий, который может с LDAP-ами всякими дружить, и делает это достаточно хорошо. Kerberos я не пробовал.
СЕРГЕЙ БОНДАРЕВ: Для Kerberos мы слишком молоды.
ДМИТРИЙ ЛАЗАРЕНКО: В Keycloak есть штука, которая позволяет обменивать токены одного типа, например, самловские токены в open d connect токены. И за счёт такого пайплайна обмена токенов Kerberosа в open d connect, которые понимает Kubernetes, наверное, можно сделать подобный костыль.
ВИКТОР ГАМОВ. В завершение давайте ещё раз поговорим про тулы. Манифесты пишутся с использованием Helm, как разработчику упростить себе жизнь при работе с ним?
ПАВЕЛ СЕЛИВАНОВ: Могу поделиться, как мы сейчас делаем это в MCS. В третьем Helm есть библиотечные чарты, на базе которых мы собрали единый Helm-чарт. И фактически всё, что нужно знать разработчику, это посмотреть документацию к единому Helm-чарту, посмотреть, какие там есть вэльюсы, и в своем проекте заполнить просто один файлик с вэльюсами (на самом деле, не один, а по одному файлику на каждое окружение). Они еще между собой мёрджатся.
Благодаря этому разработчики не касаются Kubernetes, при этом мы применяем все best practices, которые хочется применять к манифестам, используемым разработчиками. Фактически мы из этих вэльюсов разработки генерим готовые чарты. Точнее, подставляем их в наш общий чарт и деплоим это в кластер. Вот как упрощается жизнь разработчика: они не касаются Helma и Kubernetesa вообще никаким образом.
ВИКТОР ГАМОВ: И хорошо! В конце разговора ещё раз напомню, что 3-5 марта будет проходить интенсив по Kubernetes для разработчиков на платформе Слёрм. Kubernetes можно будет не только изучить, но потрогать и пощупать, потому что ребята из Mail.ru дадут всем участникам бонусные баллы.
Категории: 
