Слёрм

2729 мая пройдёт онлайн-интенсив Kubernetes Мега. Чему учить будем?



Мы не сделаем из вас продвинутого специалиста за три дня, а само участие в интенсиве не поднимет вашу зарплату. Но вы получите практические навыки управления инфраструктурой, с которыми можно уверенно работать с Kubernetes в продакшене.

Павел Селиванов, Senior DevOps Engineer в Mail.ru Cloud Solutions, Сергей Бондарев, архитектор в Southbridge и Марсель Ибраев, CTO в Слёрм будут разбирать тонкости установки, конфигурации production-ready кластера (the-not-so-easy-way) и отвечать на ваши вопросы.

Отказоустойчивость

Познакомимся с архитектурой отказоустойчивого кластера, поговорим об утилите, с помощью которой разворачивается кластер, и дополнительных компонентах.

А для того чтобы защитить кластер от падения метеорита на дата-центр, покажем инструмент, позволяющий организовать резервное копирование в кластере Kubernetes.

Тема 1: Процесс создания отказоустойчивого кластера изнутри

• Работа с Kubeadm,
• Тестирование и траблшутинг кластера.

Тема 9: Резервное копирование и восстановление после сбоев

• Методы резервного копирования,
• Бэкап и восстановление кластера с применением Heptio Velero (бывш. Ark) и etcd.

Говоря про кластер, мы думаем о некой распределённой отказоустойчивой системе, в которой задублировано практически всё: диски, процессоры, память, сетевые линки, системы хранения данных.

Подобный уровень резервирования позволяет снизить риски простоя при аппаратных сбоях.

Безопасность

Все компоненты кластера между друг другом аутентифицируются с помощью сертификатов. Мы расскажем, что делать, если сертификаты просрочились и как предотвратить такие ситуации.

Но для живых пользователей этот вариант подходит не очень хорошо, так как сложен в применении, обязательно расскажем про лучшие варианты: Authentication proxy и OIDC.

Ещё есть безопасный вариант с паролями или токенами, но это уже в теме хранения секретов, для пользователей он не очень удобен в реализации, особенно в случае с несколькими мастер-нодами.

Тема 2: Авторизация в кластере при помощи внешнего провайдера

• LDAP (Nginx + Python),
• OIDC (Dex + Gangway).

Тема 4: Безопасные и высокодоступные приложения в кластере

• PodSecurityPolicy,
• PodDisruptionBudget,
• PriorityClass,
• LimitRange/ResourceQuota.

Тема 7: Хранение секретов

• Управления секретами в Kubernetes,
• Vault.

Тема 10: Ежегодная ротация сертификатов в кластере

• Сертификаты компонентов кластера,
• Продление сертификатов control-plane с помощью kubeadm.

В целом важно понимать, как с помощью инструментов обеспечить не только безопасность пользователей, но и своих приложений, а также конфиденциальные данные.

Устройство Kubernetes

Осознанный выбор наиболее эффективных инструментов приходит с пониманием устройства Kubernetes, его компонентов, устройства сети и процесса её создания.

Тема 3: Network policy

• Введение в CNI,
• Network Security Policy.

Тема 5: Kubernetes. Заглядываем под капот

• Строение контроллера,
• Операторы и CRD.

Более глубокое понимание, как работает Kubernetes, сеть в кластере позволит решать задачи продвинутого уровня, такие как, например, написание собственного контроллера, оптимальная организация сети в кластере Kubernetes.

Базы данных в Kubernetes

Можно ли запустить базу данных в Kubernetes можно, но есть нюансы. Надо задуматься: стоит ли запускать Stateful приложения, какие есть от этого выгоды и с какими проблемами вам предстоит столкнуться. Посмотрим на реальном примере, как можно запустить базу данных в Kubernetes.

Тема 6: Stateful приложения в кластере

• Нюансы запуска базы данных в Kubernetes,
• Запуск кластера базы данных на примере RabbitMQ и CockroachDB.

Единственный положительный момент это простота и скорость запуска stateful приложения, поэтому production базы, которые работают под нагрузкой, надо запускать на отдельных, выделенных серверах.

Но не всё так плохо. Для разработки и тестирования вполне можно запускать базы данных в kubernetes.

Масштабирование

Один из самых частых запросов в Kubernetes автоматически скейлить количество инстансов приложений в зависимости от нагрузки и других показателей.

Спикеры расскажут об инструменте Kubernetes, который позволит вам динамически управлять количеством реплик приложения.

Тема 8: Horizontal Pod Autoscaler

• Скейлинг на основе встроенных метрик,
• Кастомные метрики.

Деплой приложения

Существует шесть самых популярных стратегий деплоя, некоторые реализованы в Kubernetes нативно, для других нужно использовать специальные инструменты и пляску с бубном.

Тема 11: Деплой приложения

• Инструменты темплэйтирования и деплоя,
• Стратегии деплоя.

Знание и использование разнообразных стратегий деплоя позволит более гибко подходить к развёртыванию вашего приложения. Использовать преимущества одних стратегий и не обойти недостатки других, там, где это необходимо. Можно выбирать.

Service mesh

Обзорное представление технологии service mesh и её конкретной реализации Istio необходимо, чтобы понять, какие проблемы может решать service mesh, какими инструментами и когда её можно использовать.

Тема 12: Service mesh

• Установка Istio,
• Обзор основных абстракций.

Сертификация

Итоговая практическая работа

Сертификация от учебного центра Слёрм подтверждает, что вы действительно владеете материалом. Чтобы получить сертификат, нужно сдать внутренний экзамен: мы дадим задание и предоставим стенд для выполнения.

Выполнив задание, вы отправляете настроенный кластер на ревью. Мы оцениваем качество настройки, выставляем баллы по теме. Если вы набрали достаточно баллов, мы выдаём вам номерной именной сертификат.

Формат

Практические задания и сертификация будут выполняться из личного кабинета, трансляция со спикерами пройдёт в zoom, а для общения дополнительно будет telegram-чат.

До интенсива осталось 2 недели, регистрируйтесь по ссылке: slurm.club/megamay21
Вопросы по интенсиву в комменты.

Инженеру нужен не только bash, да вы и сами в курсе. Наверняка в закладках пара курсов по основам python, может и книжку Марка Лутца купили.

На курсе Python для инженеров вы НЕ будете решать абстрактные задачки вроде: переверните список, не используя reverse(). В нашей практике только то, что применимо в работе, примеры:
Написать агент, который будет опрашивать систему управления правам и вносить изменения в конфигурации прав внутри установленных сервисов.
Написать скрипт для извлечения данных из биллинга и передачи данных в Prometheus. Формат данных не подходит. Необходимо ещё реализовать коннектор.
Генерация change log из заголовков коммитов.

На все строчки кода получите подробную обратную связь и код-ревью от спикера.
А чтобы полученные знания не ушли в стол закрепим проектом. На выбор будет несколько вариантов для инженера или свой проект. Будет круто, если захотите решить задачу с вашего рабочего проекта.


Первый поток стартует с июня, места ограничены, так что велком.
Цена курса 30к, в рассрочку на 4 месяца 7,5к.

Прочитать подробности и оставить заявку.

Что такое Kafka? Где стоит, а где не стоит применять этот инструмент? Чем Kafka отличается от RabbitMQ и других брокеров сообщений? Как её правильно эксплуатировать? Всё это обсудили на митапе Apache Kafka в вопросах и ответах, который Слёрм провёл в ноябре 2020. В разговоре участвовали спикеры из Авито, Stripe, ITSumma и Confluent. Запись митапа доступна на YouTube, а текстовую версию разговора читайте ниже.

Знакомство со спикерами

МАРСЕЛЬ ИБРАЕВ: Сегодня мы говорим о Kafka, но не про философию, а про приложение. У нас очень крутые спикеры, разрешите мне их представить и сразу задать каждому приветственный вопрос: какой RPS на вашем проекте?

Анатолий Солдатов lead engineer в Avito, много работал с базами данных, Kafka, Zookeeper, ClickHouse и много выступает на митапах и конференциях. Если не секрет, какой RPS на вашем проекте?

АНАТОЛИЙ СОЛДАТОВ: У нас около 600 RPS и порядка 25 Гб/с. Это в сумме все кластера.

МАРСЕЛЬ ИБРАЕВ: Огонь! Также с нами Александр Миронов, Infrastructure Engineer из компании Stripe, занимается развитием системы CI, работал в таких компаниях, как 2ГИС, Lingualeo и 4 года возглавлял инфраструктурную команду разработки сервисов стриминга данных в Booking.com. И это нам о чём-то да должно говорить: стриминг, большие данные, и вот это вот все наверняка как-то связано. Правильно я понимаю, Александр? И какой RPS?

АЛЕКСАНДР МИРОНОВ: Да, ты понимаешь все совершенно правильно, на середину 2020 года в Booking.com RPS получалось около 60 Гб входящего трафика и около 200 Гб исходящего, в миллионах сообщений я, честно говоря, не помню. Но это десятки миллионов сообщений в секунду.

МАРСЕЛЬ ИБРАЕВ: Супер.

АНАТОЛИЙ СОЛДАТОВ: Мы, кстати, у ребят из Booking.com учились. У нас Kafka помоложе, и Саша нам очень сильно помогал затащить всё это. Делились опытом.

МАРСЕЛЬ ИБРАЕВ: Далее у нас Виктор Гамов, Developer Advocate в Confluent. Специализируется на обработке потоковых данных с помощью Kafka. Также спикер российских, международных IT-конференций.

ВИКТОР ГАМОВ: И стример. Стал стримить, вот до чего жизнь довела! На конференции не пускают, приходится стримить. Всем привет! Какой RPS я не знаю, потому что я бездельник, маркетолог, я Kafka только продаю, не замеряю её вес. На самом деле, у нас свой Public Cloud, и у нас есть и большие, и маленькие клиенты. Не могу конкретно о цифрах говорить, но клаудный бизнес растет достаточно хорошо, люди приходят за managed-решениями. Есть SLA до трех девяток, не всегда дело в RPS, а еще иногда и в SLA, и в других вещах, которые связаны с reliability, не только со скоростью.

МАРСЕЛЬ ИБРАЕВ: Не RPS единым.

ВИКТОР ГАМОВ: Да.

МАРСЕЛЬ ИБРАЕВ: Ну и наконец Иван Сидоров, Chief Technology Innovation Officer из компании ITSumma. Самое интересное, что Иван прошел путь от простого разработчика к архитектору и обратно несколько раз, совместив это с менеджментом. Более того, вдохновившись книгой по Kafka, он инициировал создание технического издательства в компании. К Ивану вопрос такой же: как используете Kafka, какие есть максимально нагруженные проекты? Есть ли такие данные и можно ли их озвучить?

ИВАН СИДОРОВ: Отвечу немного уклончиво. По должности я исполнительный директор компании и занимаюсь внедрением различных инноваций, моя работа узнавать про новые технологии, применять их в своей деятельности. Компания у нас сервисная, поэтому своя Kafka нам если и нужна, то только какая-то карманная. Но мы поддерживаем около половины Рунета крупного точно, и Kafka мы видели очень много, в разных конфигурациях, в разных вариантах использования. И RPS тут совершенно неважен. Тут важно, как используется Kafka, для чего она нужна. Конкретные цифры сказать не могу, но очень большие бывают тоже.

МАРСЕЛЬ ИБРАЕВ: Теперь, я думаю, наша уважаемая аудитория понимает, что компетенции участников достаточно высоки. Определенно будет, о чем поговорить.

АНАТОЛИЙ СОЛДАТОВ: Чем больше RPS, тем выше компетенция. Саша выиграл здесь, мне кажется.

АЛЕКСАНДР МИРОНОВ: Не, ну, Public Cloud от Confluent, я думаю, выиграет в любом случае.

АНАТОЛИЙ СОЛДАТОВ: Наверное, да, выиграет.

МАРСЕЛЬ ИБРАЕВ: Сам придумал такую линейку, сам решил.

ВИКТОР ГАМОВ: Вот мы это и делаем. Появилась Kafka, давайте из нее сделаем Kafka для всего, вот. У нас теперь Kafka для всего.

Что такое Kafka

МАРСЕЛЬ ИБРАЕВ: Много раз звучало слово Kafka, и я бы хотел, чтобы наша аудитория вышла на один уровень понимания, что же такое Kafka и чем оно не является. В определениях часто встречается такое слово, как брокер сообщений. И для меня, человека рефлексирующего по 2007 году, это словосочетание вызывает ассоциации с Jabber, ICQ и прочим. Все-таки хочется понять, что же такое на самом деле Kafka и для чего она предназначена.

АНАТОЛИЙ СОЛДАТОВ: Давайте по вариантам, чтобы было интереснее. Это лог, это стриминговая платформа, это база данных, свой вариант?

ВИКТОР ГАМОВ: Свой вариант. В книжке от Бена Стоффеда есть замечательная метафора: слепые встретили слона и начали его ощупывать. И в зависимости от того, что они трогали, у всех складывалось определенное впечатление. Кто-то потрогал за хвост и подумал, что это опоссум. Кто-то потрогал за хобот и подумал, что это удав. Кто-то потрогал за кожу и вообще ничего не понял. Такая же история и с Kafka. Все зависит от того, откуда вы пришли, от вашего изначального опыта и того, как вы ее начали трогать. Толя дал варианты: лог, стриминговая платформа, база данных? Я скажу так это всё. Попробуйте переубедить меня.

С Kafka интересная история. Можно сказать, что пришли маркетологи и заставили нас думать, что Kafka это такая панацея от всего. На самом деле, Kafka появилась из одной простой идеи. Эта идея не нова, но её решили выкатить в первый ряд. Это идея лога, и она всегда присутствовала в любой системе, где есть персистентность, будь то база данных или система обмена сообщениями. Лог это простая идея: у тебя есть файлик, ты в него пишешь просто в конец и читаешь с начала. Эту идею имплементировали сами не раз руками. Поэтому, когда приходит слепой (из той метафоры), эксперт из мира очередей, он смотрит: ну, это же очередь! Мы же пишем в конец и читаем из начала. Это же очередь. Значит, месседжинг, правильно? Правильно.

Дальше приходит человек из мира баз данных и говорит: погодите, но мы же в Kafka данные размазываем по брокерам. Там есть партицирование, там есть consistent hashing, когда мы по какому-то ключу вынимаем, по значению знаем, куда класть. Когда клиенту не надо иметь какого-то внешнего load balancer, чтобы договориться. Это же распределенная база данных, это же NoSQL во все поля. Плюс, потому что там есть persistence, это точно база данных.

Потом приходят люди из мира ESB (enterprise service bus) и говорят: ну, там же есть коннекторы, которые позволяют нам перетаскивать данные отсюда сюда. Это ж ESB! Есть небольшой коннектор, на коннекторе есть какие-то определенные SMT (single message transforms), которые позволяют раутить в минимальном объеме. Точно ESB!

Получается неразбериха. Поэтому решили остановиться на таком определении, как Event Streaming Platform платформа для захвата и обработки стримов, потоков сообщений, потоков событий. Событие это какая-то иммутабельная запись, которая не меняется, и в идеале постоянно лежит в Kafka.

ИВАН СИДОРОВ: Дополню. Ты перечислил много применений, а если у нас замешаны датчики, то это уже IoT интернет вещей. Kafka тоже там! А вообще, это такая же категория, как операционная система. Что делает операционная система? Все что угодно. Kafka это система для работы с данными. Соответственно, в каком контексте её используют, такие возможности она и предоставляет.

АНАТОЛИЙ СОЛДАТОВ: Да, еще забыл вариант труба. И ещё вопрос: встречали ли вы сетапы, где Kafka используется как база данных самостоятельно? Без всяких PostgreSQL, MongoDB и так далее. Вот есть приложение, есть Kafka, и больше ничего нет.

ИВАН СИДОРОВ: Мы да.

АНАТОЛИЙ СОЛДАТОВ: То есть, такие кейсы вполне себе есть?

АЛЕКСАНДР МИРОНОВ: Да, встречали.

АНАТОЛИЙ СОЛДАТОВ: А с ksqlDB что-то такое уже пробовали, чтобы это была полноценная замена реальной базе данных: с индексами, с селективными запросами, которые могут ходить в прошлое?

ИВАН СИДОРОВ: Кейсы, которые видели мы, были чем-то вроде хранилища логов. Сложные запросы не нужны были.

ВИКТОР ГАМОВ: В чате пишут, что я еще забыл самый правильный юзкейс, который Kafka использует RPS строить поверх нее.

ИВАН СИДОРОВ: А чем он отличается от ESB, например?

МАРСЕЛЬ ИБРАЕВ: Все зависли над твоим вопросом.

ВИКТОР ГАМОВ: Накручиваешь, накручиваешь, и получается сборка того, что тебе нужно. Года три назад была статья от The New York Times о том, как они используют Kafka в качестве хранилища. Но у них такое, каноническое хранилище источник информации, из которого все забирают и потом каким-то образом модифицируют. Тут нужна СMS, она все это вычитает и в какие-то форматы обернёт, чтобы отрисовать это всё на экране. Если это система каталогизации, она Kafka берёт как исходник, а поверх строит какой-то индекс.

В чате пишут, что Kafka это винегрет. Kafka это Kafka.

АЛЕКСАНДР МИРОНОВ: Такое количество способов использования системы, в очередной раз подчеркивает, что перед тем как начинать пользоваться Kafka, вам нужно чётко понимать, что именно вы от неё ожидаете, какую пользу для бизнеса вы планируете извлечь. Будь то open source Kafka или managed-решения вроде Confluent, и так далее.

Может быть, вы хотите обрабатывать данные и получать репорты для ваших аналитиков в реальном времени, а не через сутки это один способ использования. Или, может быть, как в Times, вы хотите сохранить всю историю изменений вашей базы данных. Возможно ли это для вашего юзкейс, разумеется, невозможно заранее ответить, потому что у Times, все топики занимали несколько терабайт, по-моему, а если у вас петабайты данных, вам наверняка будет намного сложнее это сделать.

ВИКТОР ГАМОВ: Но все ещё возможно, есть способы.

АНАТОЛИЙ СОЛДАТОВ: Возможно-то всё, вопрос здравого смысла.

ВИКТОР ГАМОВ: Это самое главное. Спасибо, что есть Толик, который приходит и говорит правильные мысли. Вопрос не в RPS, а в здравом смысле.

МАРСЕЛЬ ИБРАЕВ: Получается, Kafka это действительно комбайн, который сочетает в себе различную функциональность. Это может быть обработчик сообщений (брокер), база данных

Где стоит, а где не стоит применять

МАРСЕЛЬ ИБРАЕВ: В каких областях Kafka можно применить? Я так понимаю, это анализ данных. Ещё я сталкивался с системой логирования мониторинга. Где помимо этих сфер можно применять Kafka?

АНАТОЛИЙ СОЛДАТОВ: В чатике было дополнение, что Kafka хорошо подходит для обмена сервисов, то есть notification туда отлично ложатся.

Давай я перечислю, для чего Kafka используется в Avito, а то фантазировать много можно. Для аналитики, для всяких кликстримов, для стриминга, для message broker, для того, чтобы вставлять различные буферы перед системами типа Elastic или ClickHouse. У нас это хорошо задружилось с трейсингом, например. Такие в основном паттерны: аналитика, message broker, буфер, база данных.

АЛЕКСАНДР МИРОНОВ: Fanout еще, такой классический кейc.

ИВАН СИДОРОВ: Аналитика в каком плане?

АНАТОЛИЙ СОЛДАТОВ: Самый простой кейс это когда на платформу входит весь входящий трафик кликстримовый, а нашим аналитикам весь трафик не нужен, потому что там очень много ботов. И мы прямо в Kafka берём и фильтруем всё это. У нас появляется отфильтрованный топик, в котором содержится только чистый трафик, и он идёт, например, дальше в ClickHouse.

АЛЕКСАНДР МИРОНОВ: Еще один классический кейс это security-анализ, анализ фишинга. Потому многие фреймворки для реал-тайм анализа из коробки позволяют использовать sliding window пятиминутное, которое автоматически за вас будет пересчитывать счетчики. Это очень удобно.

МАРСЕЛЬ ИБРАЕВ: Огонь! У каждого инструмента есть лучшие/худшие практики: молоток хорошо забивает гвозди, но замешивать им тесто не очень удобно, хотя и возможно. Есть ли области, где Kafka не ложится никак?

ВИКТОР ГАМОВ: High-Frequency-Trading (HFT). Здесь Kafka ни о чём, потому что, где диск привязан, там начинаются проблемы. Плюс, это распределённые системы. Там, где начинаются всякие сетевые вопросы, скорее всего, Kafka не подойдет. Если нужен простой месседжинг с простым раутингом (без внедрения тех вещей, о которых мы уже поговорили вкратце, KSQL, Kafka-streams, флипинг и т.д), здесь Kafka тоже не подходит. Потому что нужен просто message broker. Можно, конечно, использовать Kafka. Но потом люди приходят и говорят: вот, Kafka для нашего HFT не подходит. Ну, естественно не подходит. Для этого есть какой-нибудь Aeron или ZeroMQ, которые были создан для того, чтобы не бежать по распределёнке, а
локально.

АНАТОЛИЙ СОЛДАТОВ: Тут в целом, если тебе нужны и очереди, и супер low latency, и 100% гарантия доставки, и у тебя поток данных небольшой, то лучше не искать огромных инструментов типа Kafka...

ИВАН СИДОРОВ: а использовать хардварные решения.

АНАТОЛИЙ СОЛДАТОВ: Ну, я подводил к RabbitMQ, конечно, но можно и так.

ИВАН СИДОРОВ: Нет, это долго.

ВИКТОР ГАМОВ: Правильное, на самом деле, уточнение по поводу хардварных решений. Я раньше трудился в компании, которая делала небольшой распределенный кэш, назывался Hazelcast. И мы делали такую интеграцию интерпрайзную со всякими балалайками, чтобы делать кросс-датацентерную (как вы по-русски говорите?) Multi-Datacenter Replication.

АЛЕКСАНДР МИРОНОВ: Очень по-русски сказал.

ВИКТОР ГАМОВ: И мы как раз перед тем, как запилить адаптер для Kafka, мы запилили адаптер для Solace, который давал хардварное решение. Люди с большими деньгами покупали платы, которые давали супербыстрый latency. Там вопрос был именно передачи информации между океаном, между Чикагской биржей и Лондонской, поэтому Solace давал какие-то дикие цифры, потому что лежал поверх кастомной сети и кастомного железа. Поэтому шутки шутками, но если хочется скорости, всегда можно опуститься, как Ваня сказал, на уровень железки.

ИВАН СИДОРОВ: Если ты в HFT, у тебя уже есть деньги для того, чтобы сделать кастомную железку.

ВИКТОР ГАМОВ: Или деньги инвесторов.

ИВАН СИДОРОВ: Да, а если нет, то HFT не будет.

АЛЕКСАНДР МИРОНОВ: Ну, и еще одна холиварная тема это использование Kafka в качестве базы данных. Теоретически это возможно и даже практически мы видим какие-то кейсы, но чтобы сделать это правильно, потребуется значительное количество времени, и во многих случаях, возможно, имеет смысл продолжить спокойно использовать PostgreSQL или что-то еще, что позволяет делать простые запросы по любым ключам. Потому что Kafka все-таки да, имеет выборку по офсету ID, но даже эта операция значительно медленнее...

ВИКТОР ГАМОВ: Вот ты правильно говоришь, но для слушателей надо немного пояснить. Почему Kafka ассоциируется с известным докладом Мартина Клеппмана (Martin Kleppmann) Turning the database inside-out (если вы не видели, сходите посмотрите). Отличие Kafka от базы данных в том, что и там, и там есть лог и durable-хранилище, которое обеспечивает хранение данных на долгий срок, но в обычной базе данных для вас в API есть Query Engine, с которым вы взаимодействуете посредством какого-то DSL: SQL, в данном случае, если noSQL, там тоже какой-то свой, JSON, не знаю, что-нибудь в MongoDB. В Kafka всё немного иначе. Там storage, собственно, вот этот лог, и ваш Query language разнесены. Поэтому абсолютно непрактично использовать какой-то стандартный low level кафковский API для того, чтобы бегать по апсету. Это не нужно, неправильно и вообще вредно.

Обычно смысл Kafka в том, что вы можете насадить туда любое приложение, и оно становится вот этим Query Agent, и вы дальше накручиваете. Вы хотите иметь какой-то хитрый язык запроса? Вы можете это сделать. Речь идет о том, что стандарта нет такого, чтобы вот взять и сделать из Kafka k-value какой-то Storage. Вам нужно все равно что-то либо написать, например, взять Kafka Streams, написать там две строчки, и у вас получается из топика сделать материализованный View и отдать его через REST. Это достаточно просто сделать. Такой же процесс использует skim-registry. Вот мы сделали балалаечку, которая позволяет хранить схемы, данные. Skim-registry не нужно ничего, кроме Kafka. Она внутри Kafka хранит все ваши схемы. Она наружу отдаёт REST-интерфейс. Если вы пришли и сказали: вот у меня есть такой тип схемы, вот мой номер ID, отдай мне всю схему, всё это реализовано внутри Kafka. Kafka используется как хранилище.

Kafka Сonnect использует Kafka как базу данных. Там тыща параметров всяких, настроек лежит внутри Kafka. Когда вы стартует, Сonnect голый, он все настройки хранит внутри Kafka. То есть, здесь ничего не надо. Это к вопросу о том, что Марсель сказал про молоток. Можно молотком помешать тесто? Можно. Можно ли на Kafka сделать базу данных? Можно. Можно ли на ней сделать серьезную базу данных? Можно. Вопрос в уровне упоротости. Насколько глубоко вы готовы пойти.

ИВАН СИДОРОВ: Kafka и база данных это звучит дико из-за того, что не сходится с парадигмой обычной базы данных, где язык запросов и база данных неотделимы друг от друга. Но это достаточно просто показывается на примере того же самого Hadoop, который стал уже достаточно расхожей технологией. Что такое Hadoop? Обычно, когда говорят Hadoop, говорят HDFS. Это просто файловая система, а поверх нее можно накручивать схемы, разные движки запросов, Hive, HBase, все что угодно. И в Kafka, как я понимаю, просто пока вот этих Query Engine которые бы уже закрепились в индустрии, пока нет. И поэтому Kafka для базы данных
воспринимается так.

И если вопрос о том, где Kafka применяется неправильно, чуть переиначить и спросить: а где нерационально или слишком дорого применять Kafka это логирование. Можно делать логирование на Kafka и писать вокруг что-то или можно взять готовый ELK, который ты клик и установил. Зачем тут Kafka? Нерационально. Но если нужна система логирования, которая потом обрабатывает кучу микросервисов, отправляется через Сonnect в какой то-то data warehouse и так далее, то тут уже надо подумать, что ELK не принесёт пользы, а принесет
больше вреда, пока будешь ковыряться внутри Elastic.

МАРСЕЛЬ ИБРАЕВ: Супер, с этим вопросом разобрались. Теперь понятно, что за инструмент такой Kafka. Пойдем дальше.

Kafka vs RabbitMQ

МАРСЕЛЬ ИБРАЕВ: На круглый стол зарегистрировались около полутора тысяч человек, они задали порядка 200 вопросов, 90-95% которых были про RabbitMQ.

И первый вопрос: в чем отличие? Как я понял, Kafka это многофункциональный инструмент. RabbitMQ работает с очередями и для этого предназначен. Так ли это?

АНАТОЛИЙ СОЛДАТОВ: По большому счету, наверное, да. RabbitMQ планировался в первую очередь для очередей, и по-другому мы его не использовали. Kafka дизайнилась как бы с другой парадигмы, что ли. Вопервых, там очереди и топики это разная семантика, они не повторяют свои свойства. Во-вторых, у Kafka была изначально цель высокая пропускная способность, реально высокая. RabbitMQ, я и на своем примере знаю, и от разных компаний слышал, что 20-30 K RPS для RabbitMQ это предел. Как очередь он в принципе и не должен выдерживать больше. Наверняка, есть какой-нибудь мастер RabbitMQ, который его так соберёт, что это будет суперскоростной реактивный RabbitMQ, но это тоже вопрос: а зачем он такой, если есть технологии под этот кейс? А для Kafka перемалывать сотни, миллионы RPS это нормально. Она дизайнилась именно для этих целей. Но, с другой стороны, если нужен low latency и вам важно, чтобы одно сообщение быстренько долетело до консюмера, нигде не потерялось, то здесь RabbitMQ может и лучше подойти.

АЛЕКСАНДР МИРОНОВ: Тут нужно уточнить, что Kafka всё равно можно затюнить под low latency, чтобы у вас были миллисекундные задержки. Но для этого нужно постараться.

АНАТОЛИЙ СОЛДАТОВ: Надо потрудиться, да. И это будет, скорее всего, выделенный кластер. Не получится сделать один кластер и под high-throughput и под low latency.

АЛЕКСАНДР МИРОНОВ: Самое главное, действительно, в разной семантике топиков и очередей. Виктор уже назвал десяток технологий подобных очередей. В концепции очереди у вас есть возможность удалить сообщение или пометить его как прочитанное. Вы можете это сделать в любом порядке. Kafka это лог, которому всегда аппендятся записи. Из него ничего удалить нельзя. Соответственно, единственная метка того, где сейчас находится ваш консюмер это текущий upset, который всегда монотонно возрастает (monotonic increasing). Соответственно, вы не можете просто взять и без дополнительных инструментов пропустить какое-то сообщение, чтобы потом к нему вернуться и прочитать. Вам пришло 10 сообщений, вы должны дать Kafka ответ: вы их все обработали или нет.

АНАТОЛИЙ СОЛДАТОВ: Не могу удержаться и не сказать, что так тоже можно

АЛЕКСАНДР МИРОНОВ: Можно, да. У Uber есть большая статья: Dead Letter Queues with Apache Kafka. Про то, как они сделали Dead letter queue.

АНАТОЛИЙ СОЛДАТОВ: Кстати, в чем отличие того же Dead letter queue в RabbitMQ оно встроено в брокер, а в Kafka клиенты или что-то там над брокерами реализует эту всю логику.

АЛЕКСАНДР МИРОНОВ: Вам понадобится ещё дополнительный функционал, чтобы это сделать. И возможно, можно взять просто out of the box инструменты, а уж тем более, если вы находитесь где-то в Public Cloud, в Amazon или в Google, у вас уже есть очереди, которые доступны из коробки.

АНАТОЛИЙ СОЛДАТОВ: Опять же, различия есть. Они тоже из топиков вытекают, как Саша сказал, что есть offset consumer-groups, в RabbitMQ ты не особо почитаешь несколькими консюмерами из одной очереди. Это можно сделать, размножив очередь. А в Kafka ты читаешь один и тот же лог, и у тебя апсеты трекаются независимо для разных consumer-groups. Это вполне себе легко работает.

ВИКТОР ГАМОВ: Вот это, кстати, такой очень интересный момент, который не всегда все до конца понимают. Люди спрашивают: как мне сделать так, чтобы кто-то другой не прочитал мое сообщение? Или наоборот, чтобы смог. Я думаю, это опять все связано с тем, что Kafka не появилась из научного института, где все было сразу продумано, она появилась от сохи: люди решали собственную проблему. Вот эта категория имен, которая пришла из месседжинга, и вызывает определенные вопросы. Топик, брокер это же все месседжинг. И люди накладывают поверх этого какой-то свой предыдущий бэкграунд.

Соответственно, когда у тебя есть возможность репроцессить лог и возвращаться к каким-то вещам, например, ты получил данные и знаешь, что у твоего поставщика данных нет возможности их перечитать. Они у тебя уже лежат в системе, и ты их можешь просто препроцессить, может быть, применить алгоритм. Или ты просто пытаешься что-то новое из этих документов получить. Какую-то информацию. Это уникальная вещь, которая есть в Kafka, и зачастую о ней забывают.

Но, как только мы начинаем говорить про вещи, как Event Sourcing, QSRs, вот эти все микросервисы обмена сообщениями, вот тут люди начинают видеть бенефиты. Если они приходят в Kafka из мира обмена сообщениями, какого-то там ивентсорсинга (хотя это тоже не чистая Event Sourcing система, можно накрутить и добавить, есть там определенные решения, которые это все реализуют), люди видят бенефит. И опять же, при добавлении каких-то клевых штук, например, хранилища, которое позволяет хранить всю историю сообщений в системе, которое позволяет в любой момент в любой новой системе перечитать эти данные по новой и получить репорт.

Например, у нас есть система, которая захватывает все заказы, и нам в конце года нужно подвести итоги запустить большую джобу (от англ. job), которая выдаст репорт. Эта джоба запускается один раз в год, но данные нужно откуда-то брать. Чтобы не переливать из одного места в другое, она вычитывает данные из Kafka один раз и получает отчёт.

АНАТОЛИЙ СОЛДАТОВ: Иногда бывают вопросы: у меня в компании RabbitMQ, мы слушали, что Kafka крутая и модная, давайте мы ее поставим на замену, потому что она лучше. Хотя RabbitMQ не хуже в каких-то своих кейсах, и вообще отличная штука для очередей.

ВИКТОР ГАМОВ: Самое лучшее программное обеспечение это то, которым вы умеете пользоваться. Если вы умеете хорошо варить RabbitMQ, и он у вас не падает, по ночам вам не звонят админы, а если вы админ, то не звонят пользователи-разработчики, то вообще нет проблем.

ИВАН СИДОРОВ: Я вот все ждал, когда уровень абстракции поднимется, потому что, вот как я написал про свою должность, от разработчика к архитектору и обратно

В: Ты как Хоббит туда и обратно.

ИВАН СИДОРОВ: Да, и каждый раз с приключениями. Вообще, разница между RabbitMQ и Kafka это то, что одна машина красная, другая синяя. Если в общем говорить. В архитектурном плане. У меня есть теория, откуда начались эти холивары, которые достаточно жестко цепляются за незначительные нюансы. Kafka и RabbitMQ стартовали примерно в одно время. RabbitMQ был написал на Erlang. Тогда был фетиш, все верили, что Erlang это потрясающая система, которая спасёт мир технологий и ускорит всё, а Java это кровавый интерпрайз, мол, чтобы мне запустить на моей VPS-ке с 16-ю мегабайтами памяти Java, придется купить еще 10 таких VPS.

Дальше закон Мура работает, вычислительная мощность позволяет не думать о том, что внутри (если не HFT, а там вычислительные мощности китайских полупроводниковых заводов справляются). Сейчас это абсолютно одинаковые технологии, которые разошлись уже с точки зрения бизнеса.

АНАТОЛИЙ СОЛДАТОВ: Ты вот подводишь, что Kafka и RabbitMQ это одно и то же, но нет. Напомню, на всякий случай.

ИВАН СИДОРОВ: Я говорил с точки зрения архитектуры.

МАРСЕЛЬ ИБРАЕВ: Итак, мы обсудили, что разница у Kafka и RabbitMQ есть. И всегда нужно идти от продукта, от задачи и от умения пользоваться инструментом. Не стоит слепо верить статьям, где написано, что Kafka это круто, и у вас сайтик на WordPress взлетит после её установки.

АНАТОЛИЙ СОЛДАТОВ: Я добавлю ещё про RabbitMQ. Бывает ещё, что ты просто упираешься в технологию. У нас были случаи, когда RabbitMQ приходилось отключать реплику, чтобы он успевал. И это уже звоночек, что надо что-то другое. Плюс всякие истории с нестабильными сетями. Там тоже RabbitMQ разваливается хорошо, и стоит сразу смотреть другие технологии. Даже если вы сейчас умеете с ним работать, то Multi-DC с нестабильными сетями и высокие нагрузки не очень подходят для RabbitMQ.

Как правильно эксплуатировать Kafka

МАРСЕЛЬ ИБРАЕВ: Предположим, мы решили, что проект подходит для Kafka, мы его поставили. Но поставить и настроить это полдела. Дальше его надо эксплуатировать. Как правильно эксплуатировать Kafka? На что стоит обратить внимание? Какие метрики собирать?

АЛЕКСАНДР МИРОНОВ: Надо начать с вопроса, А на чём вы собираетесь запускать Kafka: на виртуальных машинах, на Kubernetes, на bare metal? И от этого способы развёртки и инсталляции будут кардинально меняться. Multi-DC и прочие сетапы добавляют проблем.
Классическая инсталляция Kafka это некий кластер с минимум тремя нодами, чтобы данные копировались как минимум дважды. То есть у вас будет три брокера. Как вы будете их запускать, это зависит от вас: можете с помощью Puppet, можете попробовать сделать это в Kubernetes, что будет намного сложнее. Kafka это распределённая система, у Kafka есть один небольшой недостаток, который постепенно устраняется, это зависимость от ZooKeeper.

ZooKeeper это ещё одна распределённая система, с ещё одним сетом собственных особенностей (мониторинговых, инсталляционных и всего остального), который вам придётся тоже развернуть и использовать.

АНАТОЛИЙ СОЛДАТОВ: Почему недостаток?

АЛЕКСАНДР МИРОНОВ: Ну не знаю, если ты садомазохист, то тебе может быть прикольно запускать две системы, чтобы какого-то продуктового кейса добиться, но вообще

АНАТОЛИЙ СОЛДАТОВ: Ну слушай, ты этот ZooKeeper один раз описываешь в Puppet, и потом тебе уже не важно будет, Kafka одна или с ZooKeeper.

АЛЕКСАНДР МИРОНОВ: Мы же обсуждаем это с точки зрения DevOps? Для любого DevOps-инженера это ещё одна система, которую нужно знать, алертить, мониторить, которая у вас будет падать.

АНАТОЛИЙ СОЛДАТОВ: С другой стороны, ZooKeeper может не только для Kafka использоваться, он вполне может жить в компании в каких-то других системах.

АЛЕКСАНДР МИРОНОВ: А этого, кстати, лучше не делать. Лучше не использовать ZooKeeper для нескольких систем.

АНАТОЛИЙ СОЛДАТОВ: С этим я согласен, но я про другое. Я про то, что ты где-то в Puppet имеешь описанные модули под ZooKeeper, и сетапишь ты его для Kafka или для ClickHouse не важно. Понятно, конфигурация изменится, нагрузка будет другая, но ты уже умеешь с ним работать и у тебя уже мониторинг настроен (немного что-то другое появится, конечно). Я не разделяю нелюбовь к ZooKeeper.

АЛЕКСАНДР МИРОНОВ: Никакой нелюбви нет, просто нужно отдавать себе отчёт, вот и всё

АНАТОЛИЙ СОЛДАТОВ: Да ладно!

АЛЕКСАНДР МИРОНОВ: К слову сказать, в моей команде в Booking.com за всё время эксплуатации Kafka не было каких-то больших проблем с ZooKeeper. Но, чтобы их не было, нам пришлось его подробно изучить.

АНАТОЛИЙ СОЛДАТОВ: ZooKeeper очень старая система. У нас тоже с ним никогда не было проблем.

АЛЕКСАНДР МИРОНОВ: Но у нас в компании всё же были проблемы с ZooKeeper. Не в моей команде, но в других командах. И когда они случаются, они обычно очень серьёзные.

В чём ещё особенность Kafka для людей, которые приходят из managed-сервисов? Например, когда вы работаете с SQS в Amazon, вы чётко знаете лимиты вашей очереди. Вы не можете записать, условно, больше тысячи сообщений в секунду; не можете записать больше чем 1 Мб сообщений в секунду. И вы можете выстраивать приложение, отталкиваясь от этих очень чётких лимитов. С Kafka такого нет. Это зависит и от того, как зависит ваше приложение и продюсеры, и консюмеры; от того, как настроен ваш кластер. Если придёте к админу и скажете: Заведи мне топик и скажи, сколько я смогу записать сообщений в одну партицию. Скорее всего, он не сможет дать вам простой ответ. Это ещё одна особенность Kafka, с которой мы сталкивались очень часто. Потому что приходят люди с очень разным бэкграундом, особенно из продуктовых команд, и последнее, что им нужно это думать про Кб и Мб в секунду, которые они могут пропустить через одну партицию с какой-то latency. Придётся прописывать какие-то гайдлайны для разработчиков. Нужно будет запускать бенчмарки. Нужно будет понимать, вот на вашем сетапе, на вашем железе, сколько данных за какой интервал времени вы можете пропустить.

Что ещё нужно знать про Kafka? Клиенты на каком языке вы пишете, и чем вы пользуетесь. Kafka изначально написана на Scala, теперь уже больше на Java. Соответственно, последний vanilla-клиент, которые поддерживает это всё, это джавовый клиент. Если вы используете C#, то официальный клиент Confluent, например, сделан поверх C-библиотеки librdkafka, которая тоже поддерживается человеком, который работает в Confluent, но всё равно у вас будет задержка с фичами, они будут приходить позже.

Клиенты C Sharp, Java, Go, Python, Ruby мы в Booking.com ещё Perl любили использовать, как вы знаете, нам пришлось свой клиент поверх librdkafka писать. Это достаточно большая боль, которая может возникнуть в тех компаниях, которые используют разные языковые экосистемы.

АНАТОЛИЙ СОЛДАТОВ: Да, но здесь можно либо пользоваться вот этими клиентами или писать свои, либо второе какие-то прокси комплементить или использовать, там уже нет привязки к языку.

АЛЕКСАНДР МИРОНОВ: Совершенно верно! И мы опять приходим к тому, что это ещё один возможный компонент, который придется внедрить, чтобы эту систему развязать. Это всё подчеркивает то, Kafka, она как брокер сообщений, как бы мы его ни называли, достаточно бесполезна сама по себе. Самый большой бенефит Kafka по сравнению с RabbitMQ или Pulsar это её экосистема. Это количество коннекторов, приложений, проприетарных решений, которые просто из коробки будут работать с Kafka. Я знаю даже кейсы из других компаний, где интегрировали данные из нескольких компаний с помощью Kafka. Просто потому, что у них уже она была, и им было намного проще таким образом запродюссить друг другу сообщения в кластере, прокинуть сетевые доступы условные, чем городить свои собственные проприетарные http-протоколы или ещё что-то. Вот именно эта инфраструктура и её распространенность вот это самая главная мощь Kafka, на мой взгляд.

АНАТОЛИЙ СОЛДАТОВ: Мне тоже так кажется. Более того, есть ребята из разных компаний, в том числе российских, которые из Kafka используют только коннекторы. Всё вот это вот связали, поставили Kafka, и за счет этой экосистемы не пишут вообще никакого кода. На конфигах у них всё взлетает, всё работает. Здесь иногда цена внедрения очень маленькая. Она вся упирается в инфраструктуру, по сути.

Чем глубже Kafka прорастает в компанию, есть у нее такая фишка, кластера начинают плодиться с большой силой после первого, инфраструктура тоже разрастается и порой становится очень сложной. Всё что мы перечислили: коннекторы, Zookeeper, репликаторы, мониторинги, штуки, которые позволяют легче администрировать кластера Kafka (потому что администрирование это довольно большой объём toil work). И очень быстро. Стандартная история когда у нас есть Kafka, а вокруг нее еще 10 инфраструктурных сервисов или технологий вращается.

АЛЕКСАНДР МИРОНОВ: На эту тему еще можете посмотреть как раз в Avito мы в январе этого года делали доклады, я и Толя, и мы подробно обсуждали экосистемы. То, как мы делали это в Booking.com и Толя рассказывал, как ребята делают коннекторы в Avito, и можно посмотреть, какое количество дополнительных компонентов нужно для того, чтобы эффективно ранить эту систему, чтобы ваши девелоперы занимались продуктовой разработкой, а не разработкой для Kafka.

Я еще хотел по-быстрому ответить на вопрос из чата: Лучше Kafka Connect или NiFi? В NiFi нет репликации. Если у вас падает нода в NiFi перед тем, как она прокинула данные ещё куда-то, если вы не поднимите её обратно (не знаю, помолитесь или пойдёте диск собирать руками), то не сможете эти данные восстановить.

ИВАН СИДОРОВ: Хочу всё же про мониторинг резюмировать. С коллегами я полностью согласен. Единственная метрика, которую нужно мониторить на инфраструктуре это теряем мы деньги или не теряем, а дальше уже спускаться до самого нижнего компонента. Если рассматривать Kafka как вещь в себе, то её нужно мониторить как обычное Java-приложение. Побольше памяти поставил, она не вылетает всё хорошо.

АЛЕКСАНДР МИРОНОВ: Это, кстати, плохое решение для Kafka, ну да ладно.

ИВАН СИДОРОВ: Мы же в отрыве от инфраструктуры, нам же не сказали данные. А дальше нужно смотреть, выполняет ли выбранная часть инфраструктуры, реализованная на Kafka, свою бизнес-задачу. Самый простой кейс, когда мы используем Kafka как очередь и кидаем с одной стороны сообщение в другое, то смотрим: они отправляются и принимаются? с какой скоростью принимаются? с какой отправляются? почему так мало или много принимается? есть ли аномалии? Аномалии в том бизнес-процессе, который технологически реализует Kafka.

АНАТОЛИЙ СОЛДАТОВ: Ты говоришь про ISO-мониторинг, насколько я услышал, это штука крутая. Кажется, из неё нужно исходить, и всякие там алёрты на пейджеры присылать, когда начинаются всякие такие проблемы, потому что у Kafka отказ одной, пяти или десяти машин это не проблема, можно спать дальше, если всё остальное выполняется.

Но все равно нужно еще иметь инфраструктурный мониторинг, который внутри самой Kafka смотрит, что происходит, потому что когда там проблемы начинаются, в Kafka очень много метрик, это не только то что Java дает, для Kafka их там миллион.

Мы сделали себе три окна. Первое на уровне всех кластеров смотрим, что вообще происходит там, сколько брокеров живых/неживых в процентном соотношении, есть ли офлайн-реплики, например, сколько у нас не выполняется isr.

Дальше спускаемся на уровень конкретного кластера, смотрим, сколько у него входящих сообщений сейчас, сколько исходящих. Сколько было неделю назад в этот же день, в это же время. Количество топиков партиций можно посмотреть, ну, просто серверные метрики, очевидно, в первую очередь надо смотреть сеть, наверное.

АЛЕКСАНДР МИРОНОВ: Сеть, файловые дескрипторы, disk io.

АНАТОЛИЙ СОЛДАТОВ: Файловые дескрипторы можно поставить 1 млн, и не смотреть их. Но у нас они тоже выведены, на самом деле.

АЛЕКСАНДР МИРОНОВ: Ну да, к вам просто придёт 1 млн коннекшенов, вы даже не узнаете об этом.

АНАТОЛИЙ СОЛДАТОВ: Я думаю, мы узнаем об этом быстро. Все пользователи Avito узнают об этом.

И самый низкий уровень это уже когда ты на уровне брокера смотришь специфичные какие-то метрики, сколько там в Q висит это сообщение, как часто меняются shiring expand. Там много всего, что может позволить помочь понять, где проблема (с ДЦ что-то произошло, не вывозят рейды, и их надо увеличить). Такой мониторинг тоже должен быть. Я не вижу кейса, когда вы без него можете понять, что происходит.

ИВАН СИДОРОВ: Есть проблема овермониторинга. Как ты классно рассказал, что вы спускаетесь фактически с SLA-мониторинга на процессы конкретных систем, на конкретный кластер, на конкретную джобу. Если мы спускаемся на конкретную джобу и видим экран из тысячи метрик, и 30 из них горят красными, сделать вывод, что происходит, невозможно. Исчерпывающим мониторингом можно считать тот, который срабатывает в большинстве случаев. А с верхнего уровня у нас стоит все сломалось. И все сломалось запускает ресеч до расширения списков алертов.

АЛЕКСАНДР МИРОНОВ: Мне кажется, что мы просто приходим к топику white box VS black box мониторинг, насколько я знаю у Слёрма есть всякие курсы на эту тему.

АНАТОЛИЙ СОЛДАТОВ: Самый простой путь это взять какой-то проприетарный мониторинг, который работает уже долго (например, от Confluent). Посмотреть, как у них работает, и понять что вам нужно. Там всё довольно-таки красиво, в картинках. Не надо это покупать, но заимплементить через Prometheus, Consul, Grafana, Graphite точно можно.

АЛЕКСАНДР МИРОНОВ: У Kafka в главной документации есть описание критических метрик, за которыми надо следить.

Особенности разработки приложений для работы с Kafka

МАРСЕЛЬ ИБРАЕВ: Есть ли особенности разработки приложения для работы с Kafka? Какие-то подходы?

АЛЕКСАНДР МИРОНОВ: Хочется как-то сформулировать, чтобы опять это не превращать в часовую дискуссию, потому что очень широкие вопросы. Мы уже затронули клиенты. В зависимости от того, какой клиент вы используете, он будет вести себя по-разному. Давайте обсудим Java vanilla клиент, потому что он наверняка самый популярный. В Java vanilla клиенте у вас есть две части этой библиотеки: producers и consumers. Обе эти части тюнятся совершенно по-разному. У каждой свой набор конфигураций, который вы можете настроить в зависимости от того, под какие продуктовые цели используете Kafka. Продюсер вы можете затюнить либо под low latency, чтобы он как можно быстрее отправлял сообщения с высокой гарантией доставки, либо вы можете сказать: мне нужно медленно, но много, или мало, но качественно, либо что-то среднее (in the middle).

По умолчанию, кстати, это касается и настроек брокера тоже, Kafka настроена как система in the middle: она не дает вам супергарантии доставки и не заточена под супер low latency, она где-то посередине, чтобы удовлетворять 80% юзкейсов. Это важно упомянуть, потому что если вы не видите проблем с продюсерами, с консюмерами или брокерами, скорее всего, вам не нужно трогать эти настройки.

Приведу пример. В Booking.com в первые несколько лет мы, может быть, 3 или 4 из сотни top level конфигов меняли. То есть вот этот дефолт действительно очень same в Kafka. Если возвращаться к producer side. Джавовый producer это мультитредное приложение, которое внутри открывает n тредов, коннектится к брокерам, начинает слать сообщения. Лучшая практика его применения это переиспользование одного и того же инстанса в Java. Не нужно открывать тред-сейф, соответственно, вы можете успешно пользоваться одним и тем же инстансом.

С консюмером совершенно другая история, он не тред-сейф. Мало того, что, когда вы делаете какие-то запросы типа poll, если в данный момент в буфере у этого консюмера нет сообщений, которые он вам может отдать напрямую, он заблокирует ваш main trap и начнет делать запросы Kafka. Это уже совершенно два разных поведения вроде как одной и той же библиотеки.
Но я уверен, что в 80-90% вам не надо будет ничего тюнить, вам просто нужно понять, с какой гарантией вы хотите доставить ваше сообщение. Вам, например, без разницы, дойдет оно или нет (поскольку это метрика или log line), или вам важно не потерять его (сообщение о заказе на сайте). Для этого есть одна top level настройка, которая будет фактически контролировать, на какое количество реплик будет записано сообщение, и ответ в ваше приложение вернётся только тогда, когда n реплик подтвердили запись. Соответственно, вы можете сказать, что я просто послал по сети сообщение, и мне даже TCP-акт не нужен, (это акт 0, по-моему).
Про всю эту тему есть отличная статья How to Lose Messages on a Kafka Cluster. И там достаточно большое исследование проведено. Там в Docker чувак поднимал разные конфигурации кластеров, писал в них сообщения, валил эти ноды и смотрел, где какие сообщения теряются. Пойдите почитайте и вы поймёте, что нужно и не нужно делать.

АНАТОЛИЙ СОЛДАТОВ: Я с Сашей полностью согласен. Единственное, добавил бы, что вы, скорее всего, в какой-то момент придёте к коробочкам. У вас будут как раз эти конфиги и вы можете их всех загнать в какой-нибудь фреймворк и использовать всё время одни и те же, чтобы не давать клиентам сильно много ручек, чтобы они не крутили и не портили сами себе жизнь случайно.

АЛЕКСАНДР МИРОНОВ: Согласен. У нас в Booking.com примерно так же и было сделано: ты мог затюнить все конфиги, которые хотел, ничего не ограничивали, но мы давали набор пресетов или коробочек, как ты сказал. У них было human-readable название типа low latency, No AX, high-throughput и мы затюнивали 3-5 параметров в бэкграунд за тебя.

АНАТОЛИЙ СОЛДАТОВ: Да, потому что кажется, что это проблема со всеми системами, где много клиентских настроек, что если у вас сотни сервисов или клиентов, скорее всего, кто-то из них сделает неправильно.

АЛЕКСАНДР МИРОНОВ: Наверное, тут еще про консюмеры нужно упомянуть. Самая главная теория, которую нужно знать про консюмера когда вы отправляете offset, коммитите offset. Гарантия обработки сообщения это: at least once, at most once или exactly once. Это важно для того, чтобы не потерять ваши данные, не потерять результаты обработки ваших данных и, по сути, по большому счету это все сводится к тому, что вот вы считали сообщение, вы получили сообщение из Kafka, после этого вы проводите работу над этим сообщением (неважно, что вы делаете), и перед вами стоит ключевой вопрос: в какой момент вы будете коммитить этот offset обратно в Kafka. Вы будете коммитить его как запроцешенный до того, как вы сделаете процессинг или после? И в зависимости от этого у вас будут разные гарантии доставки и обработки этих сообщений.

АНАТОЛИЙ СОЛДАТОВ: Я бы еще добавил про консюмера то, что он скейлится, их параллелизм зависит напрямую от количества партиций в топике, тоже такая базовая штука. Саша сказал про механику офсетов, есть еще вторая базовая механика: не нужно консюмеров больше делать, чем количество партиций, потому что в Kafka так сделано там больше, чем один консюмер на одну партицию не намапится. Если у вас их будет, условно, 10, а партиций всего три, то никакой пользы вы из этого не извлечете, и вам надо будет сначала партиции увеличить, а потом уже вы получите параллелизм.

АЛЕКСАНДР МИРОНОВ: Совершенно верно, да.

Бэкапы

МАРСЕЛЬ ИБРАЕВ: Последний вопрос из заготовок, который мы успеем рассмотреть: бэкап. Kafka штука распредёленная, и вроде как можно забить и сказать: она сама себя поддерживает, и если что-то упадет, то ну и ладно, она будёт работать. Махнуть рукой и предположить, что никаких проблем не будет. Но при этом что-то такое админское в душе просит все-таки какие-то сохранения состояний, бэкапы на всякий случай. И вопрос такой: нужны ли вообще бэкапы на Kafka, если нужны, то почему или почему не нужны?

АЛЕКСАНДР МИРОНОВ: Я придерживаюсь мнения, что скорее не нужны. Во-первых, в Kafka есть встроенный механизм репликации, который полностью конфигурируется вами, и вы можете контролировать количество реплик от нуля до бесконечности. Помимо этого механизма встроенной серверной репликации у вас есть те самые гарантии доставки, которые мы уже обсудили (тот самый параметр Ex). Вы можете контролировать, на сколько физических или виртуальных машин, контейнеров, подов у вас будет записано сообщение перед тем, как producer получит Всё OK от сервера. Исходя из тех бизнес-кейсов, с которыми работал я, этой гарантии было более чем достаточно.

Тут ещё такой момент, что Kafka имеет замечательный встроенный механизм ретеншена данных. Она может из коробки по времени или по размеру вашего топика удалять старые сегменты. Сегменты данных, которые были записаны, допустим, неделю назад, если вы ее так сконфигурировали. Это даёт вам гарантию, что сейчас внутри вашего кластера будут данные за прошедшую неделю, а более ранние Kafka автоматически из кластера выкинет. Чаще всего Kafka используется именно с таким паттерном, а не как бесконечная база данных.

Один из популярных паттернов складывать результаты аналитической обработки в тот же самый Amazon S3, чтобы потом их можно было поднять другим каким-то компонентом.

Ещё один интересный момент это поддержка infinite retention, то есть бесконечного ретеншена. Это значит, что вы сможете сконфигурировать Kafka таким образом, что вот те самые старые сегменты, которые выкидываются и просто удаляются с диска, вы можете сказать Kafka, что она должна их сложить в какой-то холодный object store (по большому счёту, это Tiered Storage). Интерпрайзный уже есть, но я им не пользовался, так что не буду говорить (open source должен появиться). Так что холодные сегменты, данные, которые вы уже не будете активно использовать, вы можете сложить в S3 и потом доставать раз в год, когда нужно перечитать весь лог. Так вы будете сохранять место на горячем диске и при этом не понадобиться задумываться о бэкапах и прочих дополнительных настройках.

АНАТОЛИЙ СОЛДАТОВ: Я полностью за, и у меня есть несколько дополнений. Начну с Tiered Storage. Это крутая штука, которая изменит в целом конфигурацию машин по Kafka. Сейчас у нас есть какие-то заряженные железками, дисками машины, а можно будет просто какие-то маленькие (почти in memory) Kafka ставить, а все остальное складывать в Tiered Storage. Это как один из вариантов использования.

По поводу бэкапов у нас такой же подход. Kafka это по умолчанию распределённая отказоустойчивая система, которая не должна терять данные, и она для этого практически всё делает. Угробить можно любую систему, конечно. Один из ключевых конфигов, которые нужно не забыть использовать это rack awareness, на мой взгляд. Даже если вы живете в одном дата-центре, попробуйте, если у вас есть контроль над серверами, хотя бы в разные стойки разнести брокеры, всем брокерам прописать, где они стоят (rack id). И Kafka будет следить, чтобы у вас все лидеры равномерно по этим рэкам распределились. Тогда вероятность проблем минимальная. При этом стоимость бэкапов Kafka высокая. Так что Kafka бэкапить-то можно, но будет это стоить дорого, а реального профита вы наверняка не получите.

И второй момент: у Kafka есть Zookeeper, как мы уже обсуждали, и это та система, которую, бэкапить можно. Она довольно недорогая. Мы бэкапим ее. Просто раз в неделю снимаем бэкапы, валидируем их довольно примитивно. Смотрим, что у брокеров id стоят, в Docker разворачиваем и считаем, что всё OK.

АЛЕКСАНДР МИРОНОВ: Мы тоже бэкапим Zookeeper, это важно.

АНАТОЛИЙ СОЛДАТОВ: Без Zookeeper Kafka теряет информацию о том, какие данные где лежат, как их получить. Даже если вся Kafka работает хорошо, а кластер Zookeeper по каким-то причинам отлетел, вам будет очень сложно восстановить данные. Есть всякие Kafka-дампы, которыми можно вытащить из конкретных топиков, которые вы знаете, где лежат, конкретные данные. Но это будет долго и скорее всего не восстановите весь кластер. Поэтому лучше Zookeeper-мозги где-то хранить.

АЛЕКСАНДР МИРОНОВ: При том что объём этих мозгов измеряется в Мб.

Там еще спрашивают в чате: учитывается ли rack id в min.insync.replicas? Я отвечу нет. Просто смысл rack id, в том, что он используется Kafka в момент создания топика. Когда вы говорите, сколько у вас есть партиций в топике, и для каждой у вас будет n реплик. Вот этот rack id, Kafka вам гарантирует, что эти реплики партиций будут раскиданы по разным рэкам. Что она не положит их все в один рэк. После этого она и никакой rack id в своём рантайме не использует.

АНАТОЛИЙ СОЛДАТОВ: Не Kafka использует, а всякие админ-команды. Это будет влиять только на ребалансировки, когда вы будете партиции двигать по брокерам. Тогда да. Он опять заиграет, и Kafka будет смотреть на них так, чтобы лидеров или партиций перетащить так, чтобы они были во всех стойках были распределены правильно.

АЛЕКСАНДР МИРОНОВ: И если, например, вы зададите, что у вас два рэка, но при этом min.insync.replicas у вас там три, то по умолчанию команда создания топиков скажет вам, что не может создать топик, потому что не может раскидать партиции равномерно.

ИВАН СИДОРОВ: По опыту наших клиентов на поддержке могу сказать, что сейчас данные, хранимые в Kafka, не настолько дороги, чтобы делать бэкапы с них. Пока что в типовых случаях время жизни данных в Kafk довольно короткое. Тут правильная мысль про то, что реплики должны быть в разных дата-центрах. Но реплика это кластер, и даже учитывая, что мастер-ноды там нет, они сами себе выбирают, с кластером что-то может пойти не так. Но сохранять данные очень дорого по соотношению стоимость данных/стоимость хранения данных, и самый эффективный вариант, который мы видели это mirroring кластера. Чем отличается от реплики: поднимается точно такой же кластер и настраивается туда пересылка данных. Он просто работает как резерв и как бэкап.

АНАТОЛИЙ СОЛДАТОВ: Тут сразу два момента интересных если несколько ДЦ, это не синоним того, что у нас несколько кластеров. И всегда, когда про Kafka читаешь, начинается с того, что О! Stretch cluster, ужас какой, не используйте. Это всё неправда. На самом деле, нужно исходить из latency, которую ваша сеть дает, проверить хотя бы это, и скорее всего там stretch cluster заведётся, будет всё работать хорошо. Есть варианты с асинхронными кластерами, которые на основе репликаторов, но здесь тоже не стоит забывать, что это повышает сложность всей системы и то, что появляется еще одна точка отказа, и это не бесплатно. И начинать все-таки стоит с простого stretch cluster, который один, растянутый на несколько дата-центров. И часто он работает.

ИВАН СИДОРОВ: Добавлю ещё не про кластеры, а про mirroring кластера. Читал в вопросах, как разделять контуры безопасности, практический опыт если есть интранет и экстранет, и в интранет пускать нельзя, а потоки данных идут из внешки, можно миррорить часть топиков из внешней Kafka во внутреннюю Kafka. Открыть только одну дырочку.

Для тех, кто хочет узнать больше о настройке и оптимизации Apache Kafka Слёрм готовит новый видеокурс. Спикеры Анатолий Солдатов из Авито и Александр Миронов из Stripe. Доступ к первым урокам будет бесплатным. Оставить заявку на курс можно уже сейчас.

19 января в 19:00 приглашаем на бесплатный вебинар Создание эффективной инфраструктуры при помощи облачных решений. На вебинаре расскажем об отличиях облачной инфраструктуры от традиционного подхода. Обсудим вопросы:

Как работают облака и какие проблемы они решают?
В чем разница между IaaS, PaaS и SaaS?
Как Netflix обслуживает десятки миллионов подписчиков по всему миру?
Global Presence: ваш ЦОД в любом уголке планеты.
Flexibiltity: от ста серверов до тысячи и обратно за несколько минут, адаптивно к нагрузке.
Модели оплаты Upfront/Pay as you go.

Спикер

Александр Волочнев, Developer Advocate в DataStax Inc.

Certified Professional Cloud Architect
Автор международных курсов для IT-специалистов
Более 8 лет опыта разработки и внедрения облачных решений
Спикер на многочисленных международных конференциях

Записаться на вебинар

Для тех, кто работает на проектах с развитой или развивающейся микросервисной архитектурой, мы в Слёрме готовим трехдневный интенсив по service mesh, он пройдет с 19 по 21 марта.

Внедрение service mesh на самом низком уровне радикально меняет инфраструктуру, поэтому любые ошибки при внедрении могут привести к даунтайму и серьезным последствиям.

На интенсиве мы не будем много говорить о подходе service mesh. Максимум внимания уделим практике, рассмотрим различные зоны возможностей этого подхода и попробуем их внедрить на конкретной системе.

Для практики будем использовать проект без service mesh в Kubernetes-кластере. Задача постепенно внедрить service mesh, отслеживая изменения.

Преподаватели

Спикер интенсива: Александр Лукьянченко, тимлид в команде архитектуры Авито. Читать интервью со спикером
Лидер практики: Иван Круглов, Staff Software Engineer в Databricks.

Программа

1: Service mesh подход, решаемые задачи.
2: Готовые реализации. Запуск на своем Kubernetes-кластере. Внешний трафик через gateway.
3: Troubleshooting проблем работы service mesh.
4: Умный роутинг, правила доступа. Стратегии deploy: canary, blue/green с помощью SM.
5: Мультикластерность и прозрачная балансировка трафика. Поддержка нескольких ДЦ. Подход к обновлению Kubernetes.
6: Аутентификация и mTLS между сервисами в mesh.
7: Chaos engineering и реализация через service mesh.
8: Observability. Какие возможности дает service mesh.
9: Унифицированный трекинг взаимодействия через метрики prometheus/statsd.
10: Распределенный tracing через proxy контейнеры.

Стоимость обучения: 70 000 руб. при оплате до 1 марта.

Подробнее об интенсиве

Приглашаем на митап Большие данные: не хайп, а индустрия в понедельник 1 марта. Спикеры из ITSumma и Слёрма представят доклады о Big Data, ответят на вопросы участников. Будем говорить о том, как получать и обрабатывать большие данные, какие выгоды и инсайты сможет получить бизнес при правильной работе с данными и какая обработка данных принесёт вред компании.

Доклады:

• Где брать большие данные, как их обрабатывать и главное зачем? Иван Сидоров, ITSumma.
• Обогащение данных что это и почему без него никак? Иван Хозяинов, ITSumma.
• Кейс Тикетница как провайдер больших данных и бизнес-инсайтов. Тимур Хасанов, ITSumma.
• Почему хаотичная работа с большими данными вредит бюджету компании и как с этим бороться? Денис Наумов, Слёрм.

Ведущий митапа Марсель Ибраев, Слёрм.

Участие бесплатное. Понадобится регистрация.

Мы открыли доступ к базовым темам курса по Apache Kafka, начать учиться можно уже сейчас.

В программе две теоретические темы Введение и Базовые основы технологии и практическая тема Установка Kafka. В ней поработаем с технологией руками:

1. Развернём Kafka в самом простом её варианте с одним брокером и одной нодой ZooKeeper.
2. Запишем и прочитаем сообщения, посмотрим в конфиги и увидим, как данные хранятся на диске.

Спикеры курса

• Анатолий Солдатов, Lead Engineer в Авито;
• Александр Миронов, Infrastructure Engineer в Stripe, ex-Booking.

Доступ к курсу придёт после регистрации: https://slurm.io/kafka

Релиз всех тем видеокурса будет 7 апреля. До релиза действует цена предзаказа 40 000 руб. вместо 50 000 руб.

Потеря данных или их недоступность это всегда больно. А времени на поиск решений, анализ, тестирование идей по улучшению инфраструктуры не хватает, потому что надо поддерживать текущие процессы.

Мы собрали информацию и опыт в учебную программу, которая закроет три основных блока вопросов по работе с PostgreSQL.

Курс поможет сэкономить время на генерации идей, поиске информации. Рассмотрим архитектурные решения и вместе с преподавателем внедрим их в тестовой среде.

Спикер

Иван Чувашов, ведущий инженер OKKO и администратор баз данных Southbridge

• Сертифицированный администратор PostgreSQL (PostgresPro, 10 уровень Эксперт);
• 13 лет опыта работы с базами данных, более 6 лет опыта работы архитектором БД и DBA;
• Опыт поддержки технической инфраструктуры компании Окко (dev, preprod, prod) в части баз данных;
• Опыт построения отказоустойчивых кластеров на базе СУБД PostgreSQL и GreenPlum 6x;
• Постоянный докладчик на IT-конференциях.

Расписание

Курс пройдёт в формате онлайн, по вторникам и четвергам в течение трёх недель: 6 и 8 апреля, 13 и 15 апреля, 20 и 22 апреля. Начало занятий в 19:00 по мск. Длительность занятия 3 часа.

Стоимость: 30 000 руб.

Посмотреть подробнее и подать заявку можно здесь.

Внедрить SRE-подход, когда в команде нет опытного SRE-специалиста получается только через пробы и ошибки. Чтобы такие ошибки не стоили дорого, можно перенять опыт коллег из других компаний. Приглашаем на интенсив по SRE 2123 мая 2021 года.

Формат интенсива: офлайн или онлайн на выбор.

Как будет проходить обучение?

Участники интенсива будут решать задачи, близкие к ежедневной работе SRE-инженера.
И всё это без рисков на продакшене, лишнего стресса и убытков для компании. Спикеры покажут то, что написано в книгах Google об SRE через призму реальной работы. Практические задания студенты будут выполнять в небольших командах по 46 человек, в каждой команде соберутся специалисты с разным опытом и компетенциями.

Мы уже провели два потока, получили отзывы студентов и продолжаем улучшать интенсив.

На интенсиве нужно будет поддерживать приложение, уделять много внимания мониторингу. Понадобится много работать с кодом. SRE это тот, кто разбирается с кодом помимо программистов. Приложение написано на Python.

Спикеры

• Иван Круглов, Staff Software Engineer в Databricks.
• Павел Селиванов, Senior DevOps Engineer в Mail.ru Cloud Solutions.
• Артём Артемьев, Lead SRE в Inspectorio.

Место проведения: Москва, отель Севастопольи онлайн (Zoom). Выбирайте подходящий вам вариант.

Стоимость участия: при оплате до 1 мая 70 000 рублей.
Командой 3+ 50 000 рублей за 1 участника.

Подробности и регистрация

Запускаем запись на двухдневный интенсив по Terraform, обучение пройдет 2425 апреля. Интересно будет всем, кто работает или планирует работать с облачной инфраструктурой и продолжает разворачивать её в ручном режиме.

На интенсиве можно получить практический опыт работы с технологией, а после приступить к внедрению подхода Инфраструктура как код для стабильного и быстрого развертывания инфраструктуры без ошибок.

Во время практики студенты с нуля построят проект инфраструктуры с помощью Terraform, постепенно разбирая его концепции. Во второй день уделят время рефакторингу и обновлению существующей инфраструктуры, используя при этом лучшие практики.

Результат обучения: знания по работе с Terraform, умение строить с помощью него инфраструктуру корпоративного масштаба, умение работать с Terraform в команде.

Программа интенсива

1 День (24 апреля, суббота)

• Что такое Terraform и практика Infrastructure as a Code. Для чего их применяют.
• Чем отличается Terraform от других инструментов конфигурации, в чем его преимущества и недостатки.
• Terraform State что это такое.
• Создание проекта с Terraform. Основные команды при работе с Terraform, основные концепции Terraform: providers, resources, variables, locals, data sources, outputs.

2 День (25 апреля, воскресенье)

Создание модулей для Terraform инфраструктурной абстракции.

• Разделение проекта на несколько частей remote state. Организация работы с state в команде.
• Использование одного и того же кода для разных окружений Terraform Workspaces.
• Обновление между версиями Terraform.
• Продвинутые команды и функции Terraform.
• Best-practices по использованию Terraform в компании.

Стоимость обучения: 15 000 рублей.

Подробности и регистрация

Гостем подкаста The Art Of Programming стал спикер курса Слёрма по Kafka Александр Миронов, Infrastructure Engineer в Stripe. Тема выпуска Проблемная Kafka. Обсудили вопросы, часто возникающие при работе с Kafka: аудит входных данных, квоты, способы хранения данных, возможный даунтайм в консьюмер-группах и др.

Итоговый проект по Kafka

Релиз видеокурса от Александра Миронова и Анатолия Солдатова состоялся 7 апреля. Кроме заявленных тем мы добавили в курс итоговый проект: студентам нужно будет выполнить практическое задание под звёздочкой с применением знаний, полученных на курсе.

Мы добавили два варианта заданий из области разработки и из области администрирования. В первом варианте понадобится создать приложение для генерации real-time статистики продаж интернет-магазина, а во втором спасти кластер от хаоса.

Подробнее о курсе
Бесплатные материалы курса

21 мая в Слёрме начнётся интенсив по SRE. На три полных дня участники погрузятся в теорию и практику поддержки высоконагруженных сервисов. Никаких задач по работе, никаких семейных дел только учёба. Под катом рассказываем, что вас ждёт, если решите присоединиться.

Справка об SRE

Site Reliability Engineering (SRE) обеспечение надёжности информационных систем. Это новый подход к поддержке сайтов, сервисов и приложений с тысячами и миллионами пользователей. Подход зародился в Google, а сейчас распространяется по всему миру. В России SRE внедрили в Яндексе, Mail.ru, Сбербанке, Тинькофф, МТС, Мегафоне и других компаниях.

Инженерами по SRE становятся опытные разработчики и системные администраторы: важно глубокое знание серверных ОС, работы сети, инструментов мониторинга, а также умение программировать. На все эти хард-скиллы накладывается методология SRE конкретные практики, которые помогают обеспечивать высокую надёжность.

SRE это не столько про алертинг и постмортемы. Это про то, чтобы до продакшена не доходил код, который ночью подрывает.

Из общения с инженерами, внедрившими SRE

Долгое время основным источником знаний об SRE была одноимённая книга от Google. Сейчас есть несколько англоязычных и русскоязычных обучающих программ. Одна из них интенсив по SRE в Слёрме.

Формат интенсива

Интенсив проходит онлайн и состоит из лекций и практических занятий. Будет трансляция в Zoom и Telegram-чат со спикерами.

Два вида практики. Практические занятия предусмотрены двух видов: настройка по образцу и работа над задачами, решение которых не определено заранее. На интенсиве они называются кейсы.

Командная работа над реальным сервисом. Для работы над кейсами участники интенсива объединяются в команды по 5-8 человек. Каждая команда получает стенд с приложением несколько VDS, на которых размещён сайт для заказа билетов.


Сервис заказа билетов, стабильную работу которого будут обеспечивать участники интенсива

Имитация сбоев. В течение интенсива в работе сайта произойдёт несколько крупных сбоев, и задача команды найти причину, устранить и предотвратить её повторение. Кейсы основаны на реальном опыте: спикеры собрали проблемы, с которыми сталкивались за свою практику SRE, и создали среду для имитации этих проблем.

Опытные спикеры. Программу интенсива разработали и будут вести:

• Иван Круглов, Staff Software Engineer в Databricks.
• Артём Артемьев, Lead SRE в TangoMe.
• Павел Селиванов, Senior DevOps Engineer в Mail.ru Cloud Solutions.

Поддержка. Объединиться в команды и организовать совместную работу помогут кураторы. В решении сложных задач поддержат спикеры и инженеры техподдержки Слёрма.

Дистанционный формат. Лекции транслируются в Zoom, обсуждение задач происходит в Slack. Все записи лекций сохранятся и будут доступны после интенсива, к ним полезно возвращаться через некоторое время, уже в более спокойной обстановке.

Три дня полного погружения. Интенсив рассчитан на три полных дня, с 10:00 до 18:00 по Московскому времени. Будут небольшие перерывы между лекциями и обед.

Старт 21 мая. Места ещё есть.

Узнать больше и зарегистрироваться

Ниже полная программа интенсива.

День 1: знакомство с теорией SRE, настройка мониторинга и алертинга

В первый день вы познакомитесь с теорией SRE, научитесь настраивать мониторинг и алертинг, а также объединитесь в команду с другими участниками интенсива.

Расскажем про метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Поделимся Best Practices по настройке мониторинга и правилами для пожарной команды. Дадим первые практические кейсы.

Тема 1: Мониторинг

• Зачем нужен мониторинг,
• Symptoms vs Causes,
• Black-Box vs. White-Box Monitoring,
• Golden Signals,
• Перцентили,
• Alerting,
• Observability.

Практика: Делаем базовый дашборд и настраиваем необходимые алерты.

Тема 2: Теория SRE

• SLO, SLI, SLA,
• Durability,
• Error budget.

Практика: Добавляем на дашборд SLO/SLI + алерты.
Практика: Первая нагрузка системы.

Кейс 1: downstream-зависимость. В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down. Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.

Тема 3: Управление инцидентами

• Resiliencе Engineering,
• Как выстраивается пожарная бригада,
• Насколько ваша команда эффективна в инциденте,
• 7 правил для лидера инцидента,
• 5 правил для пожарного,
• HiPPO highest paid person's opinion. Communications Leader.

Кейс 2: upstream-зависимость. Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой. В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.

Тема 4: SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать.

День 2: решение проблем с окружением и архитектурой

Второй день практически полностью построен вокруг решения двух кейсов: проблемы с окружением (здесь будет подробный разбор Health Checking) и проблемы с архитектурой. Спикеры расскажут про работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.

Тема 5: Health Checking

• Health Check в Kubernetes,
• Жив ли наш сервис?
• Exec probes,
• initialDelaySeconds,
• Secondary Health Port,
• Sidecar Health Server,
• Headless Probe,
• Hardware Probe.

Кейс 3: проблемы с окружением и правильный Healthcheck. Задача Healthcheck обнаружить неработающий сервис и заблокировать трафик к нему, чтобы пользователи не столкнулись с проблемой. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность проблемы могут быть в окружении. Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.

Тема 6: Практика работы с постмортемами пишем постмортем по предыдущему кейсу и разбираем его со спикерами.

Тема 7: Решение проблем с инфраструктурой

• Мониторинг MySQL,
• SLO/SLI для MySQL,
• Anomaly detection.

Кейс 4: проблемы с БД. База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы непонятно. Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.

День 3: traffic shielding и канареечные релизы

Тут два кейса про высокую доступность продакшена: traffic shielding и canary deployment. Вы узнаете об этих подходах и научитесь их применять. Хардкорной настройки руками не планируем, хотя кто знает.

Тема 8: Traffic shielding

• поведение графиков роста кол-ва запросов и бизнес операций
• понятие saturation и capacity planning
• traffic shielding и внедрение rate limiting
• настройка sidecar с rate-limiting на 100 запросов в секунду

Кейс 5: traffic shielding. Когда падает прод? Например, когда мощности рассчитаны на 100 пользователей, а приходит 1000. Вы столкнётесь с подобным кейсом и научитесь делать так, чтобы система не падала целиком, а продолжала обслуживать то количество клиентов, на которое была рассчитана. Блокируя избыточный трафик, вы сохраните возможность системы выполнять задачи для части пользователей.

Тема 9: Canary Deployment

• стратегии деплоя в k8s (Rolling Update vs Recreate),
• canary и blue-green стратегии,
• обзор инструментов для blue-gree/canary release в k8s,
• настройка canary release в GitLab CI/CD,
• пояснение схемы работы canary release,
• внесение изменений в .gitlab-ci.yml.

Кейс 6: проблемы с кодом. Как бы хорошо новые фичи не работали на стейджинге,
всегда есть вероятность, что в продакшене что-то пойдёт не так. Снизить потенциальный ущерб можно, если выкатить обновление только на часть пользователей и предусмотреть возможность быстрого отката назад. Подобный подход называется Canary Deployment, и через практический кейс вы научитесь его применять.

Узнать больше и записаться

Учебный центр Слёрм и Selectel совместными усилиями создали курс по Managed Kubernetes, доступ к урокам предоставляется бесплатно.

Спикеры курса познакомят с Managed Kubernetes Selectel и научат работать с кластерами.
Покажут популярные кейсы использования, разберут мультизональный кластер и расскажут, как рассчитать стоимость проекта.

По окончании курса вы сможете решать главную задачу организация контейнерной инфраструктуры.

Кому подойдёт курс

• Администраторам, готовым приобрести практический опыт использования Kubernetes.
• Инженерам, оптимизирующим затраты на рутинные задачи по разворачиванию и поддержке кластеров Kubernetes.
• Разработчикам, желающим получать контейнерную инфраструктуру быстрее.

Спикеры

Марсель Ибраев, Chief Technology Officer, Слёрм
Инженер с 8-летним стажем,
Certified Kubernetes Administrator,
Внедрения Kubernetes для клиентов Southbridge.

Алексей Богданов, Product manager, Selectel Managed Kubernetes
Развиваю системы и людей больше трёх лет;
Работаю над продуктами Selectel: Managed Kubernetes, Serverless, CRaaS, API Gateway и MQaaS;
Рассказываю на вебинарах о Managed Kubernetes.

Формат курса

Курс состоит из 7 модулей, выстроенных в логической последовательности. Каждый модуль состоит из одного или нескольких уроков, которые представляют собой наборы видеолекций, описательной части и практики.

Во вводном модуле курса каждый студент получит промокод на 3 000 рублей для выполнения практических заданий в сервисе Managed Kubernetes Selectel.

Программа

Тема 1: Вводный модуль

• О Selectel, курсе и промокоде

Тема 2: Знакомство с Managed Kubernetes Selectel

• Managed Kubernetes VS bare-metal Kubernetes
• Особенности и возможности Managed Kubernetes Selectel

Тема 3: Развёртывание своего кластера через Managed Kubernetes

• Создание кластера из личного кабинета
• Создание кластера через Terraform
• Создание кластера через API Selectel

Практика: развернуть кластер одним из трёх изученных способов, настроить управление кластером через Kubectl со своего локального компьютера.

Тема 4: Практические кейсы по использованию Managed Kubernetes

• Подключение сетевых дисков
• Работа с сетевыми абстракциями
• Настройки безопасности
• Регламентные работы
• Кастомизация кластера
• Мониторинг и логирование
• Настройка пользователей и конфига kubectl
• Taint, Labels
• Добавление кастомных зон в CoreDNS

Практика: Поднять отказоустойчивый кластер с 3 мастер-нодами и 3 воркер-нодами и 2 нодами с ролью ингресс в разных зонах. Установить ингресс-контроллер через Helm, настроить его согласно best practices.
Создать кластер Manager PostgreSQL и настроить взаимодействие кластера Kubernetes и кластера PostgreSQL.
Установить в кластер Kubernetes приложение RabbitMQ. Запустить его в 3 реплики, настроить персистентное хранение данных с помощью PV/PVC.

Тема 5: Мультизональный кластер Kubernetes

• Создание мультизонального кластера Kubernetes в панели управления.

Тема 6: Поиск неисправностей и дебаг

• Разберём способы поиска причин неисправностей и их устранения.

Тема 7: Ценовая политика

• Как рассчитать стоимость проекта?

Managed Kubernetes Selectel

Kubernetes это система оркестрации контейнеров. Managed Kubernetes от Selectel упрощает процесс развёртывания, масштабирования и обслуживания контейнерной инфраструктуры. Обновлением версий, сертификатов, безопасностью и работоспособностью Control Plane Kubernetes занимается Selectel.

Сервис работает на базе Облачной платформы Selectel и использует её ресурсы для рабочих нод кластера: серверы, балансировщики, сети, диски.

В Managed Kubernetes можно управлять кластерами с помощью панели управления, Terraform или API сервиса. Создать кластер в Managed Kubernetes Selectel за две минуты реальность.

Начать учиться

Доступ откроется после регистрации автоматически: slurm.club/3tT7c2Q

Я как-то видел, когда в команду разработки закинули задачу распилить монолит. И всё. Люди должны были работать в два раза больше это ужасно.

Когда поступает похожий запрос, важно не наворотить дел и понять, как избежать новых трудностей. Об этом рассказал Марсель Ибраев, технический директор Слёрма.

Марсель поделился непростым кейсом из своего опыта, высказал мнение, что всё начинается с менеджмента и как может выглядеть обучение распилу монолита. Этот материал не очередное руководство к действию. Это интервью с человеком, который набил не одну шишку и поделился опытом выстраивания правильного распила.



Давай представим, что перед нами стоит задача распилить монолит.

Начнем с причин и решим, действительно ли вообще нужно что-то распиливать. Я сталкивался с кейсом, когда монолит пилили просто потому, что один разработчик назвал это решением всех проблем, другие идею подхватили, а вот детально никто ничего не проработал. И вот в этом случае проблема была не столько в монолите, сколько в плохом коде и неверных подходах.

Так, и какими дальше будут наши действия?

Первое, что нужно сделать, это организовать грамотный менеджмент. Начните с выбора технического лидера человека, обладающего должными компетенциями и достаточным количеством свободных ресурсов. Это может быть и текущий технический лидер компании, например, CTO или тимлид. Но важно, чтобы у него хватило ресурса и времени на курирование задачи по распилу.

Далее он вместе с командой проводит ретроспективу, где выясняет, как они дошли до жизни такой, какие проблемы сейчас актуальны и почему они возникли. Они могут быть следствием логичного развития проекта: кодовая база сильно выросла, появилось много зависимостей, выкатка релизов производится недостаточно часто. Или это следствие неправильных подходов и плохого кода, что бывает гораздо чаще, на мой взгляд,. Честный ответ на вопросы упростит всем жизнь в будущем.

Есть мнение, что монолит это плохо и нужно сразу делать микросервис. Это так?

Нет. Я в корне не согласен с этим. Монолит и микросервис это две разные архитектуры под две разные задачи. Например, если проект представляет собой магазин носков, который ежедневно посещают пять человек и в будущем их будет не сильно больше, то, скорее всего, лучше делать монолит. Так будет быстрее и проще. Главное не упустить момент, когда требования к проекту и подходам сильно изменились, а ваш магазин стал вторым Amazon. :)

А есть ли какое-то решение в обход распила монолита?
Допустим, мы мигрируем в облако, и нам требуется при миграции подготовить свое приложение к Кубу, а именно распилить на сервисы.

Повторюсь, что для начала нужно обратиться к причинам, зачем нужно пилить монолит. Если команда понимает, что это действительно необходимо и текущий процесс разработки при том же ритме и подходах в перспективе стоит дороже, чем силы, потраченные на распил монолита, в таком случае обходных путей нет. Главное нужно хорошо подумать о том, как всё сделать правильно.

То есть не получится запихать legacy в контейнер и сказать, вот, пожалуйста, влезло.

Нет. Такая идея может возникнуть. Например, кто-то написал какое-нибудь древнее legacy, которое все боятся трогать. Допустим, этот человек пару лет назад уволился, а сейчас кто-нибудь предлагает взять и запихать его код в контейнер со словами: Пусть это там само работает. Звучит дико, согласен. И я бы не поверил, что такое может быть, если бы не увидел своими глазами.

Ты говоришь, что если мы собираемся пилить монолит, то нам нужен человек, который будет курировать процесс работы, прикинет затраты.
А вот что делать, если ни у кого нет опыта в этом?

Нужно дополнительно обучаться или же брать человека с необходимым бэкграундом. Три составляющей успешного распила: компетентный лидер, компетентные разработчики и компетентная инфраструктурная команда. И лучше не идти в этот процесс, если хоть где-то мы проседаем или в перспективе не доберем компетенций.

Если компания всю жизнь разрабатывала на монолите, то, вполне возможно, что у разработчиков не будет опыта разработки микросервисной архитектуры. Это может быть неочевидно, так как сам по себе разработчик может быть хорошим, но это плохо для компании с точки зрения выполнения задачи. Подходы в монолитной и микросервисной архитектуре различны. Даже хороший монолитчик с большим стажем, который всю жизнь делает монолиты и даже слышал что-то про 12 факторов, не сможет хорошо выполнить работу с микросервисами именно из-за разницы в подходах. Но мое мнение, что успех работы на 80% зависит от менеджмента. Без человека, управляющего процессом, ничего путного не выйдет.

Почему?

Давай лучше приведу пример. Я как-то видел, когда в команду разработки закинули задачу распилить монолит. Просто поставили тикет, как будто разработать очередную фичу. И всё. Как команда должна решить этот вопрос, с какой стороны подступиться, непонятно. В итоге люди должны были работать в два раза больше это ужасно. Ну и положительного результата там тоже не случилось. Поэтому нужен человек, который возьмет на себя планирование. Это не должны быть детальные планы вплоть до дней и часов, это должны быть ключевые пойнты.

Как вариант, можно расписать работу по спринтам. Но скажу сразу, что я не завидую этому лидеру. Ему придется быть между молотом и наковальней: грамотно согласовывать интересы команды и бизнеса. Прийти к владельцам и сказать, что мы ничего, кроме распила, делать не будем это плохо. Прийти к разработчикам и сказать, что бизнесу нужны фичи, а нам нужно пилить монолит, поэтому вы будете работать в два раза больше это тоже плохо. Не получится делать хорошо всё и сразу теми же силами.

Есть какие-то выходы из этой ситуации?

Это, скорее всего, будут кадровые решения и набор компромиссов. Можно нанять новых сотрудников или отправить на учебу имеющихся, как я уже сказал ранее. Можно какие-то кадровые перестановки сделать. Также стоит учесть, что теперь команде нужен человек, который будет понимать инфраструктуру будущего проекта. Идея просто засунуть всё в Kubernetes кажется легкой, конечно, но не стоит забывать что Kubernetes это дополнительная абстракция в вашей инфраструктуре. Да, она позволяет решать ряд операционных задач проще, но по факту делает жизнь админов и поддержку проекта сложнее.

Ты сказал, что людей нужно обучить. Можно ли упаковать информацию по распилу в какое-то единое знание? Будь то гайд или курс для разработчиков или админов.

Думаю можно. Хоть каждый случай особенный и неповторимый, какие-то основные паттерны от кейса к кейсу будут похожи. Причины распила будут примерно одинаковые, языки, на которых всё будет происходить, будут примерно одинаковые и шишки, которые люди набьют, тоже будут примерно одинаковые. Образовательный продукт интересен тем, что тема горяча и процесс распила монолита похож на ремонт он не заканчивается никогда.

Оно же как бывает: бизнес требует фичи, а разработчики пилят монолит. Получается так, что из-за срочности реализации фич эти фичи добавляются в монолит. Причем добавляются они быстрее, чем монолит пилится. И это легко может превратиться в бесконечный цикл. Без правильного менеджмента никуда, как я уже не единожды это проговорил. Если говорить об образовательном продукте, то это, наверное, ряд лучших практик технических, инфраструктурных и управленческих.

Проекты бывают разные. У кого-то интернет-магазин, у кого-то платформа для торгов. Отличаются ли аспекты распила для них?

Подход плюс-минус будет одним и тем же. Главное, чтобы у вас был четкий план работы. Но тут важно отметить, что при этом нужно оставаться гибкими. Например, приходит к тебе бизнес и говорит, что в ближайшие две недели будет распродажа, поэтому прод не нужно трогать. Важно не отвечать на подобное жестким нет и вообще-то, у нас в эту неделю переезд каталога. Важно найти компромисс и понимать, что интересы бизнеса первичны. Распил монолита, как уже было сказано, это большая задача и большой менеджерский вызов.

Копнём про гибкость глубже. Распил какой-то части отодвигается на месяц, как тогда быть?

Есть вполне конкретная ситуация, например, разработчики, разбирающиеся в той части, которая нам нужна для переезда, заняты написанием фич. Эти фичи важны и были согласованы, поэтому мы тратим все силы на них. В таком случае роль менеджера не в том, чтобы просто сказать окей, ладно, переносим сроки, а подойти к вопросу с точки зрения бизнеса или даже инвестора. Только в данном случае мы инвестируем не столько реальные деньги, сколько время наших сотрудников.

Нам будет выгоднее отложить эту задачу на месяц или нанять кого-то, кто будет заниматься задачей прямо сейчас? Нам будет выгоднее пилить фичу прямо сейчас или можно отложить на неделю и потом сразу релизить эту фичу в микросервис? Нужно всегда отслеживать процесс работы, корректировать его и предлагать эффективные решения. В этом и заключается гибкость.

Ты несколько раз упомянул про фичи, которые прилетают от бизнеса и которые нужно добавлять в монолит. Получается, нужно добавлять их и в распиленные микросервисы.
Я правильно понимаю, что тут речь идет об обратной совместимости с монолитом, когда фичи должны быть и там, и там?

Я встречал разные имплементации. В одном из проектов нам удалось договориться с бизнесом о том, что мы новые фичи сразу пилим в микросервисы. У нас был некий центральный балансировщик, который распределял трафик на монолитную часть по одним урлам, а по другим отправлял его в Куб. По итогу мы сошлись на том, что все новые фичи стали делать сразу в Кубе. Но так договориться получится не всегда, поэтому оптимальным решением будет соблюдение правильного баланса всех имеющихся ресурсов.

С кем важно договориться в первую очередь?

С бизнесом. Важно понимать, что-то 100% пойдет не по плану. Это часть процесса, так точно будет. Как бы хорошо и правильно вы всё не распланировали, вы с этим точно столкнетесь, к сожалению. Но может быть, просто мне так не везло, и бывает что все проходит идеально.

И снова обращусь к примеру. Разные части монолита разрабатывались много лет разными командами и разными людьми. Большая часть сотрудников, разрабатывающих ранние куски кода, уже ушла из компании. В коде вскрылись различные зависимости, о которых никто не знал. Документацию, естественно, никто не вел. Всё это в совокупности формирует те самые непредсказуемые изменения, о которых я говорил ранее. И что еще раз подчеркивает идею о том, что важно быть гибким и договариваться с бизнесом.

Сколько нужно разработчиков и админов для распила монолита? Кто из них будет работать дольше или больше?

Определенно, что работа с инфраструктурой в целом менее затратна, чем работа с кодом. Иногда нужно что-то заново разрабатывать, вносить новые архитектурные паттерны. Получается, что разработчиков нужно больше, чем админов. Со стороны инфраструктуры нужно будет что-то поднять и оперативно настраивать. В самом начале работы с инфраструктурой будет много, ведь придется все отстраивать с нуля. Хотя опять же всё зависит от проекта. Но в целом разработчики работают больше, и в компаниях их обычно больше, чем людей, занимающихся инфраструктурой.

Поделись проблемами, которые возникали при распиле. Первое, что я слышал обычно, это непродуманность инфраструктуры.

Да, у нас было такое. Пришел к нам клиент, которому нужен был Kubernetes. Поскольку мы ребята опытные, то сразу задаём встречный вопрос: А вам это зачем? Бывали случаи, когда мы отказывали клиентам, потому что не видели необходимость в Kubernetes, естественно всё объясняли. Человек услышал что-то про Kubernetes, решил, что это круто, и захотел. Расскажу про ситуацию, когда мы не отказали.

Клиент был в процессе переезда на микросервисную архитектуру. Первая проблема была в отсутствии DevOps-инженеров в команде. Выполняли всё силами бедных разработчиков, которые пилили фичи, микросервисы и занимались инфраструктурой. В какой-то момент поняли, что ничего не получается.

Часть монолита хостилась на нескольких серверах в разных частях. Примерно всей кодовой базы была неизвестна: туда никто не лез, потому что люди, которые ее писали, уволились, и изучение того, что там, оставляли на потом. Проект был в сложном состоянии. Контейнеры крутились в Docker Swarm. В одном контейнере был просто запущен кусок монолита, хотя ради справедливости стоит отметить, что было и несколько микросервисов. В итоге, конечно, мы разобрались со всем этим.

И всем стало хорошо?

Вроде бы и да, но счастье почему-то всё не наступало. То есть технически проект стал работать стабильнее, деплой стал удобнее. Но радости от этого со стороны заказчика мы почему-то не ощущали. Мы поняли, что стоило бы глубже обсудить вопрос, зачем все же клиенту нужен был Kubernetes.

Оказалось, история была следующей. У проекта изначально были некоторые бизнес-проблемы, в которых видели техническую причину. Один из разработчиков тогда сказал, что причина, почему так все плохо в монолите. В тот же день поставили задачу переезд на микросервисы. И действительно даже начали распил и частично заехали в Docker SWARM. Только счастье все равно не наступало, просвета не наблюдалось, проблемы не решались. Тогда решили, что проблема в Docker Swarm. И обратились к нам.

Так вот по итогу переехали в Kubernetes, не идеально конечно, кое где полупереписанное legacy заехало, по желанию клиента и с обещанием переписать в дальнейшем. Но счастье снова не наступило. Оказалось, что да, инфраструктура стала работать стабильнее, но первоначальных проблем это так и не решило. Скорость разработки не увеличилась, фичи как пишутся вяло, так и пишутся, и скорость релизов неудовлетворительная. Когда мы наконец поняли, что проблема счастья клиента носит не инфраструктурный характер, мы встретились со стейкхолдерам компании и решили провести аудит.

Что именно вы делали?

Мы провели полный технический и менеджерский аудит всей компании: проверили, как работают разработчики, как устроены процессы, заново всех прособеседовали. И по результатам вскрылось очень многое, в том числе неприятных подробностей. Там внутри был и саботаж процессов, и перекладывание ответственности, и просто отсутствие компетенций. Не буду вдаваться в детали, но по итогу несколько человек пришлось уволить, а нескольким сделали последнее предупреждение. Помимо этого, мы увидели, что многие процессы были выстроены неправильно, поэтому и не работали так, как надо. Дали клиенту ряд рекомендаций и если не изменяет память, помогли с наймом новых сотрудников.

Не знал, что Southbridge оказывает такую услугу (прим. Кейс с того времени, когда Маресль работал инженером в Southbridge).

На моей памяти это была разовая история. Так что мой основной поинт по нашей теме: в процессе переезда важнее всего менеджмент и управление, а технические нюансы уже вторичны. Хоть и тоже крайне важны.

Как понять, что мы действительно распилили монолит на микросервисы, а не сделали микросервисный монолит?

Это вопрос компетенций внутри команды. По идее, если сотрудники компании не просто просиживают рабочее время на работе, а сознательно относятся к ней и стремятся сделать всё качественно и хорошо, то такой вопрос вообще не будет стоять.

Приведи пример.

Микросервис представляет собой некий кусочек приложения, выполняющий конкретную функцию. Этот кусочек независим. Если всё сделано хорошо, то падение или недоступность одного микросервиса не вызывает падение или недоступность всего проекта. Например, магазин, сортировка, личный кабинет всё работает в обычном режиме, но вот положить товар в корзину мы не можем, потому что какой-то один микросервис приуныл. Конечно, нюансов там гораздо больше чем, я описал, но это просто пример правильной работы.

Подведём итог. Рецепт распила монолита состоит в следующем: компетентные кадры, грамотное планирование, четкое понимание целей и гибкость в работе. Ничего не упустил?

Забыл упомянуть менеджмент. Кстати, если этот рецепт переложить на выполнение других задач, то их реализация тоже получится хорошей. Тут я Америку никому не открыл. Я понимаю, что инженерам и программистам интересна техническая сторона вопроса, но предлагаю взглянуть на распил с точки зрения управления процессом. Если про это забыть, то ничего не получится.

Поделитесь своим мнением на наши вопросы, варианты могут не охватывать всё, можно дополнить свой ответ в комментариях.

Когда компании пора внедрять микросервисы? Как быть разработчику, который хочет или которого заставляют использовать 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 дадут всем участникам бонусные баллы.

Вы бы посоветовали своему сыну или дочери пойти работать в IT? Считаете ли, что через 10-15 лет эта отрасль всё ещё будет на волне? Сделала ли работа в IT счастливым вас, сделает ли счастливым вашего ребенка?

Моей старшей дочери 22 года. Она доучивается на физтехе и работает бизнес-аналитиком. Младшей дочери 16, и она вообще не хочет в институт: она топит за опыт работы и самостоятельное обучение.

В Слёрме у большинства есть дети. И когда мы обсуждаем обучение разработке для детей и подростков, мнения делятся от давайте оставим детям детство до любые курсы лучше, чем то, что сейчас творится в образовании.

А вы какую позицию занимаете?

Вот что говорит мой коллега, тимлид в Southbridge. Его старший ребенок учится в 6 классе.

Вопрос в том, интересно ли это ребенку? Как по мне, работа обязательно должна приносить удовольствие.

А если отвечать на вопрос, насколько перспективно IT-образование, то тут двоякое ощущение. С одной стороны, современное IT-образование, как и любое другое, отстает от реальности примерно на 5 лет (что для IT колоссальная пропасть), и поэтому от него нет особого толка. С другой стороны, высшее образование даёт большое количество дополнительных плюсов. В частности, навык самостоятельного поиска информации.

Если вопрос в том, насколько перспективна работа в ИТ, я считаю: более чем. При этом я бы рекомендовал своему ребенку начать с разработки, так как современные тенденции говорят, что в ближайшее время все будет как код, и без умения писать код специалист не сможет развиваться ни в одной области ИТ.

Владимир Гурьянов

Пожалуйста, проголосуйте в опросе и напишите в комментариях, что вы думаете по этому поводу. Редкий случай, когда ваш комментарий действительно может что-то изменить.
(Если опрос недоступен, можно проголосовать здесь: https://forms.gle/ous7bRovTQgp7LEf7).

Что такое service mesh и какие задачи по управлению инфраструктурой решает? Как service mesh внедряли в Авито и почему отказались от популярного Istio? Зачем стали писать аналог и к чему в итоге пришли? Об этом в интервью Слёрму рассказал Александр Лукьянченко тимлид в команде архитектуры Авито и разработчик интенсива по service mesh.

В Авито Александр Лукьянченко строит внутреннюю платформу для всех разработчиков на базе оркестратора Kubernetes. В Слёрме готовит интенсив по service mesh, который стартует в марте.

Начнём с основ: что такое service mesh?

Service mesh это подход, который позволяет организовать внутри системы умную сеть, а эта сеть в свою очередь даёт возможность решать определённые задачи и проблемы. Например, более гибко управлять трафиком, создавать более безопасное общение между узлами системы, организовывать деплой канареечными релизами, внедрять гибкие механизмы выкатки новых микросервисов, да и любых частей системы.

Это подход, когда мы неважно, какая у нас технология, на каком стеке написана система добавляем в каждый узел sidecar-контейнер и через него получаем возможность внедрять в сетевое взаимодействие любую логику. В результате можем внедрять разного рода вещи, которые я упомянул, а также инструменты observability для понимания, как все эти кусочки системы взаимодействуют.

Как узнать, что компании пора внедрять service mesh решения?

Самое главное это понять, какие проблемы есть в системе, и закрывает ли их service mesh.

1. Управление трафиком: канареечные деплои, деплои по методу blue-green, различные схемы балансировки (round-robin, хеш-балансировки и т. д.) между микросервисами. Это про эффективность и условное тестирование в продакшене, чтобы меньше аффектить пользователей в случае проблем.
2. Безопасность. Когда мы хотим не только снаружи, но и внутри иметь безопасное общение между всеми узлами в системе. Много кто идет в технологию, исходя именно из этого пункта. Если есть много компонентов в системе и надо сделать так, чтобы каждый из них взаимодействовал с другим по защищенному соединению, протоколу это задача сложная не только в плане имплементации, но и в плане поддержки. Надо заниматься ручной ротацией сертификатов или писать инструменты, которые это будут делать. А service mesh закрывает эти проблемы.
3. Observability. В развитой микросервисной архитектуре не всегда можно быстро найти причину деградации или какого-нибудь падения. Service mesh даёт возможность простого внедрения унифицированного распределенного трейсинга, мониторинга. Это в том числе и логирование, но логирование именно сетевого взаимодействия. Например, envoy proxy позволяет удобно и в подробном виде получать логи всех взаимодействий.
4. Объединение в единую сеть больших кусков системы. Например, нескольких Kubernetes-кластеров. Это тоже важный момент. Здесь есть два поинта. Первый мы с помощью такого подхода обновляем Kubernetes-кластера на новые версии, делая это не inplace для постепенного перехода. И второй когда у нас есть, например, несколько публичных облачных провайдеров либо своих дата-центров, мы можем с помощью этого подхода объединять их в единую сеть.
5. Отказоустойчивость системы. В распределенной системе в разных частях могут возникать периодические сетевые ошибки. С помощью паттернов circuit breaker, outlier detection, retry политик можно эти проблемы обойти. Но реализовывать в каждом узле их затратно. С service mesh это также можно решить.

Это основные моменты. На мой взгляд, их наличие хороший сигнал о том, что надо посмотреть на service mesh.

Также по косвенным признакам: когда есть развитая микросервисная архитектура со множеством независимых кусков, которым надо взаимодействовать между собой; когда сложно понимать, как они взаимодействуют; когда нужно выстраивать между ними более надежные и безопасные взаимодействия и сделать это руками всё ещё возможно, но дорого и сложно вот тогда компания приходит к service mesh.

Если система состоит буквально из нескольких микросервисов или представляет собой одно монолитное приложение, то это можно решить другими средствами, и абсолютно не обязательно я бы даже сказал, не имеет смысла использовать service mesh.

Как к внедрению service mesh пришли в Авито?

Были две глобальные задачи: решить проблемы с пониманием того, что происходит в системе и более гибко управлять трафиком. Сначала мы хотели улучшить observability, получить унифицированный мониторинг и трейсинг. Это была первая цель, которой мы добивались, внедряя service mesh.

Спустя какое-то время понадобилось добавить возможности по управлению трафиком: внедрить канареечные релизы, использовать несколько Kubernetes-кластеров в одном окружении. Мы не обновляем Kubernetes-кластеры inplace, а вместо этого создаём Kubernetes-кластера рядом и переносим все сущности из одного кластера в другой. Без создания единой сети и service mesh делать это было больно, потому что приходилось в каждом узле системы переписывать правила прохода трафика говорить, что вот сейчас мы идем в другой Kubernetes-кластер.

Эти две глобальные задачи возникли с разницей примерно в год. Когда только начали подступаться к решению, помимо истории с observability был ещё один технический аспект, почему мы вообще пошли в эту технологию, начали её ресёрчить и внедрять, почему стали смотреть на Istio.

Дело в том, что к тому моменту мы уже использовали в продакшене Сontour.io от Heptio (сейчас VMware). Contour это ingress-контроллер на базе envoy proxy. Это более мощное решение, нежели стандартный ingress-контроллер на базе Nginx. Он позволяет делать много разных штук, которые умеет envoy, в том числе внедрять более мощные стратегии управления трафиком, нативные канареечные релизы. Кроме того, Contour обладал лучшим перфомансом, чем механика, которую использовал Nginx (reload конфигураций со сторонним контроллером и множеством логики на lua).

Но что самое интересное, по сути Contour использовал тот же стек технологий и тот же подход, что и решения service mesh. У него был свой control plane, очень похожий на то, что есть в Istio (в то время это был pilot компонент). Он использовал то же самое прокси-решение envoy proxy. Мы понимали подход и знали, что envoy proxy уже production ready, и его можно использовать в нашей системе. Поэтому мы начали входить в Istio.

В докладе о service mesh ты говорил, что его внедрение было обусловлено ещё и задачами тестирования.

Да, это как раз трек про управление трафиком. В непродакшн средах нам действительно нужна была фича перенаправление динамического трафика на новую версию микросервиса.

Это один из подходов, который позволял нам дешево тестировать: мы просто выкладываем новую версию сервиса и с помощью service mesh перенаправляли на неё трафик только для конкретно этих тестовых запросов с помощью специальных заголовков.

Возвращаясь к переходу от Contour к Istio: чем эти решения различаются?

Contour это ingress-контроллер, то есть решение, которое позволяет принимать внешний трафик внутрь Kubernetes-кластеров. По сути, только эту задачу он и решает.

Istio и вообще service mesh технологии это технологии, которые позволяют использовать те же подходы, но решать проблемы взаимодействия узлов внутри системы. Например, обеспечивать подачу различного трафика между микросервисами, внедрять mTLS-общение между узлами. По сути это тот же самый подход, но масштабированный на всю систему.

Надо сказать, что почти все service mesh решения предоставляют возможность (на том же самом control plane, на тех же технологиях) использовать свой ingress-контроллер. Например, в Istio есть Gateway. Но есть и отдельные проекты, которые делают чисто ingress-контроллеры, Contour это один из них.

Рассматривали ли вы другие решения, кроме Istio?

В то время (а это был, по-моему, 2017 год) существовало два проекта, которые мы рассматривали Istio и Conduit (сейчас переименован в Linkerd 2). Почему мы выбрали Istio?

Первый поинт был в используемых технологиях, потому что envoy proxy в то время был уже продакшн-реди продукт, который использовался большими компаниями. Например, в Lyft, где и разработали envoy proxy, его уже использовали по паттерну service mesh. Мы понимали, что это решение, скорее всего, будет хорошо подготовлено к нагрузкам и будет успешно использоваться и в Авито с точки зрения перфоманса. А в Conduit было свое решение, написанное на Rust. У нас экспертизы по этому языку было немного, и казалось, что это не очень правильный подход, что там ещё свой прокси.

Второй момент это, конечно, маркетинг Istio и внедрение его в индустрию Google и IBM. Они очень качественно представили проект в индустрии: выпустили много презентаций и видео о возможностях Istio. Где-то за год им удалось сделать так, что если кто-то узнавал о service mesh или говорил, то рядом обязательно всплывало слово Istio. Istio стало как бы дефолтной реализацией.

И мы понимали, что скорее всего на горизонте нескольких лет именно Istio будет основной реализацией, которую будет использовать большинство компаний. Остальные имплементации может быть и останутся, но будут менее популярными и менее поддерживаемыми, чем Istio.

Каким образом вы начали внедрение? В своем интервью ты говорил, что перед этим тестировали Istio около года.

Начав его внедрять, мы уже примерно понимали, как всё устроено и как организовать процесс.

Начинали с песочницы?

Естественно, раскатывали постепенно. Сначала на staging-кластерах тестировали механику работы, разбирались в логике. Затем начали постепенно, посервисно внедрять. Спустя несколько месяцев дошли до продакшена.

К тому времени в основном Kubernetes-кластере у нас была уже достаточно большая система: тысячи инстансов, тысячи подов микросервисов. Поэтому новая система сразу же проверялась на перфоманс насколько она готова к такому объему.

При внедрении Istio в продакшн и всплыли явные проблемы, в том числе та, из-за которой мы спустя время решили отказаться от Istio. Самой большой проблемой оказался как раз перформанс работы Istio. Об этом я много рассказывал на конференциях.

Причина этой проблемы скрывалась в архитектуре, и устранить её нельзя было без сильного внедрения в исходный код Istio. Каждый инстанс содержал в себе знание о всей системе, и так как у нас уже была большая система с тысячами инстансов, каждый из узлов потреблял большое количество оперативной памяти. Вместе с тем, чтобы получать эти знания, Istio сильно утилизировал и сеть, и CPU.

Мы посмотрели, как это всё ведет себя в проде, умножили на количество наших инстансов и в принципе даже были готовы потянуть такой объем (хотя он был огромным, терабайты оперативной памяти просто так). Но понимали, что в будущем мы будем расти, и этот объём тоже будет расти, причём квадратично. То есть решение просто не масштабируется.

Помимо этого при внедрении возникали какие-то проблемы, встречались баги мы их сами фиксили. К тому времени у нас уже был свой форк Istio вещи, которые мы быстро не могли протащить в апстрим, исправляли сами. Но исправить проблему с перфомансом в то время было крайне сложно, потому что нужно было переписать процентов 30 кодовой базы Istio.

Получалось, что мы вроде как используем Istio, но при этом должны его сильно менять, и в итоге получить свой уникальный service mesh, просто на базе Istio.

Тогда мы начали понимать, что в Istio таком виде у нас в проде не может лететь в долгую. Совместно с еще одним моментом, на который закрывали глаза: Istio был не очень стабилен по API и от релиза к релизу делал ломающие изменения. Для больших компаний это проблема, потому что когда есть много мест, где используется технология, менять по каждому из вхождений имена это большая работа. Но мы были готовы с ней мириться, если бы не проблема с перфомансом.

Как могло получиться, что Istio разрабатывали такие большие компании, но с большими нагрузками она справляется плохо?

Istio и многие другие service mesh решения развивались эволюционно. Взять даже envoy proxy. В первой версии протокола использовался не gRPC, который позволяет делать сервер-пуши для обновления конфигураций в каждом узле. Там использовался обычный http, который давал оверхед на взаимодействие control plane с прокси-контейнерами. Соответственно, на это потреблялось большое количество CPU и сети, чтобы делать long polling, затем, спустя время перешли на gRPC.

В случае с Istio ровно та же история. Сначала сделали базовое решение, которое в целом решало нужные проблемы, но еще без больших внедрений. На мой взгляд, архитектурные решения вроде раздачи всего discovery в каждый узел были приняты исходя из того, что они просто работали. Да, они работали до определенного уровня и на этапе зарождения технологий это было не так важно. Внедрение на каких-то не очень больших проектах работало хорошо и позволяло быстро достичь результата.

Забегая вперед скажу, что в конце 2018 года в Istio решили внедрять механизм чёткого декларирования зависимостей. Этот подход мы использовали в своём control plane, разработанном уже после отказа от Istio. В Istio он появился примерно в 2019 году и как раз позволял чётко задекларировать, какому узлу какие данные нужны и решить таким образом проблемы с потреблением памяти, сети и вообще, в целом, оптимизировать всю эту систему. Но это было спустя несколько лет.

Отказавшись от Istio, вы стали разрабатывать своё решение. На какие характеристики делали упор в первую очередь?

У нас был достаточно длинный путь. После первого внедрения Istio мы преследовали те же задачи, повышение observability в первую очередь.

Чтобы просто иметь возможность получать с каждого узла нужные метрики, а с каждого микросервиса трейсинг-спаны, мы разработали альтернативный прокси. Заменили envoy proxy на собственную реализацию, которая потом стала называться Netramesh. Это технология тоже service mesh, она позволяла нам без control plane, без настраивающей части прокси-контейнера получать со всей системы нужную нам информацию о том, как взаимодействуют части системы. С этим решением мы жили достаточно долго, и до сих пор оно в продакшене.

Со временем возникла новая задача объединить несколько Kubernetes-кластеров в единый контур. Однажды получилось так, что у нас появилось несколько равноценных Kubernetes-кластеров, которые использовались в одном окружении. Нужно было управлять ими с помощью единой сети, и мы снова пришли к service mesh.

Только в этом случае нужно было в каждом узле знать всю систему, все Kubernetes-кластеры. Нам нужен был тот самый control plane выделенный компонент, который бы всем рассказывал, куда нужно ходить, какие у нас есть зоны, какие зоны отказа и так далее. Так мы пришли к созданию дополнительного решения, по своей архитектуре очень похожего на Istio.

Мы взяли envoy proxy, написали control plane под его протокол xDS и назвали это решение Navigator (здесь можно посмотреть базовое описание и исходный код).

Таким образом сейчас мы имеем в продакшене сразу два прокси-контейнера: Netramesh, который занимается задачами observability, и envoy proxy, который настраивается с помощью Navigator и управляет трафиком.

В результате мы получили возможность связать Kubernetes-кластера в единую систему и объединить в единую сеть. Сейчас мы используем большое количество envoy proxy и service mesh подход как раз с помощью Navigator. В том числе различные схемы балансировки трафика между сервисами, канареечные деплои, mTLS, стики-сессии (по кукам, по хедерам), настраиваем зоны приоритетов подачи трафика, везде используем outlier detection, connect retries.

Путь такой. Соответственно, каждое из этих решений закрывало определенную проблему. Сначала проблему observability закрыла Netra, сейчас Navigator управляет взаимодействием между инстансами микросервисов.

Когда возникла необходимость объединить кластеры, вы не рассматривали Istio снова?

Да, перед внедрением Navigator мы ещё раз пробовали внедрить Istio, проводили перфоманс-тесты, уже зная проблемы, но он всё еще был не готов.

Это было примерно полтора года назад, а спустя ещё полгода эта проблема в Istio была решена с помощью специальной sidecar-сущности, которая позволяет отрезать discovery.

Я общался в комьюнити Istio и знал, что решение будет, и что оно будет именно такое, но ждать мы не могли были проблемы и потребности, которые нужно было закрыть. Тогда мы подумали, что сможем за достаточно короткий срок разработать свой control plane, который будет решать конкретный набор задач (не всё, что есть в Istio, а лишь определенный пул).

Примерно так и вышло. Мы разработали первую версию Navigator буквально за месяц. Причем большую часть времени заняло написание инфраструктуры мощного мультикластерного e2e тестирования. Без них было нельзя, потому что это корневой инфраструктурный компонент.
В итоге мы получили стабильное решение, которое смогли ввести в продакшн значительно раньше, чем если бы продолжили дожидаться Istio и решений с его стороны.

А если предположить, что тогда Istio был бы готов. Вы бы стали его внедрять?

Мы бы запустили следующий перфоманс-тест, и если вы всё было хорошо, то смотрели бы на стабильность в плане логики работы. Если бы там не было больших проблем (скорее всего их бы не было, потому что мы их еще несколько лет назад полноценно ревьюили и репортили), то да, скорее всего мы бы пошли в сторону Istio.

Кроме оверхеда у Istio было ещё одно не очень приятное для нас качество большие возможности. С одной стороны, это круто, ты можешь делать очень много с помощью инструмента. С другой стороны, порог входа и удобство использования оставляло желать лучшего. Это огромное количество разной документации разного уровня качества. Входить и разбираться в проект, в котором есть большое количество возможностей, крайне сложно и вводить в такой инструмент нескольких инженеров достаточно затратно.

Сейчас разработчики Istio сворачивают управление его возможностями в небольшой set кастомных ресурсов, возможностей конфигурации. Делают, чтобы по дефолту все работало максимально в том виде, в каком нужно пользователям в продакшене.

Возможно, какие-то такие вещи могли бы нас еще остановить, но в целом это всё решаемое. Скорее всего, мы бы взяли Istio как основное решение.

Сейчас Istio всё ещё на позиции лидера, или есть какие-то более-менее равноценные аналоги?

Я бы сказал, что есть три продукта, которые точно стоит рассматривать.
Не стоит фокусироваться чисто на Istio. Стоит посмотреть, попробовать, как минимум изучить, какие есть возможности и архитектура работы трех решений. Первое Istio, второе Linkerd2, несмотря на то, что он без envoy proxy, посмотреть на его механику работы, попробовать в каких-то частях своей системы, я думаю, стоит. Так как у этого проекта как раз долгое время был упор на перфоманс, на более эффективную работу, и возможно, что в конкретном кейсе он подойдёт лучше, где нужно будет более эффективно сделать взаимодействие. Хотя на горизонте нескольких лет все-таки есть уверенность, что победят service mesh на базе envoy.

Третье решение, которое точно стоит посмотреть, это Consul Connect от HashiCorp. Это решение, по сути, альтернатива. Оно в текущих версиях ушло от своего прокси-контейнера тоже в сторону envoy proxy. И сейчас Consul Connect умеет настраивать envoy и умеет решать задачи мультиклауда если у нас несколько дата-центров, либо несколько публичных облаков, он позволяет объединять это в единую сеть. Если в стеке технологий в компании уже есть Consul или другие продукты от HashiCorp, то, возможно, это вообще очень хороший кандидат в том плане, что он позволяет объединять в единую сеть в том числе ворклоады и части системы, которые находятся, например, вне Kubernetes-кластеров, вне стандартных решений, на которые обычно ложатся service mesh.

Ну и с точки зрения стабильности HashiCorp имеет реальных клиентов, и они в них внедряют и отлаживают эту систему, поэтому она продакшн-реди, и ее можно рассматривать как хорошее решение для внедрения к себе.

Если смотреть на эти три проекта в целом, то всё ещё кажется, что выиграет Istio, но вполне возможно, что будет просто несколько альтернативных решений как сейчас. Consul Connect, на мой взгляд, сейчас достаточно популярен. Менее популярен, чем Istio, но есть определенный набор компаний, который его использует в продакшене и успешно.

Интересно, что ты не упомянул связку, которую вы используете.

Да, могу рассказать про нашу связку. Мы заопенсорсили наш продукт: и Netra, и Navigator можно найти на GitHub, их можно использовать. В принципе, это один из вариантов, который можно внедрить, и он действительно с точки зрения перфоманса и тех фич, которые реализованы, очень стабилен, проверен уже временем, там несколько лет активного использования в продакшене.

Но есть один момент. Наши решения решали проблемы именно Авито в первую очередь. Поэтому здесь можно посмотреть, насколько наши решения закрывают все потребности.

Сейчас мы не предоставляем наше решение как продукт с возможностями платной или бесплатной поддержки. Мы, конечно, отвечаем на вопросы тем, кто использует, например, Netra (она давно используется в нескольких компаниях и помимо Авито), но надо понимать, что это не бизнес в данный момент. Это просто open source решение.

Ты был основным разработчиком этого решения?

Одним из основных. Конкретно Netra занимался в основном я и в будущем было еще несколько человек, это уже точечные contribution по добавлению дополнительной функциональности. Всего в сумме поучаствовало где-то 5-6 человек. Navigator это уже более мощное решение, в его разработке изначально участвовало уже три инженера и в будущем подключались еще на различные проекты и фичи, которые были нужны, еще несколько человек. Это те, кто активно развивали продукт.

Текущие решения, которые используются в Авито, закрывают все задачи, которые были поставлены до этого?

Те проблемы, которые мы хотели решить этими инструментами, мы их решили, но, как и любой инструмент, любой продукт не может быть заморожен, у него все равно с течением времени появляются какие-то новые фича реквесты, новые хотелки, которые нужны. И мы продолжаем его активно дорабатывать. Внедряем какие-то новые фичи, например, из последних вещей, mTLS тот же самый и внедрение его по всей системе сейчас в активной фазе развития. То есть, такого рода вещи, которые мы изначально не ставили в цель решение с помощью этих инструментов, но сейчас такие задачи появились, и мы их закрываем этими решениями. Navigator растет, развивается. Изначальные задачи были решены, но есть и новые.

Предположим, компания решила внедрять service mesh. Какие компетенции необходимы команде?

Вообще технология service mesh лежит посередине между разработчиками и теми, кто занимается эксплуатацией. Какие необходимы знания? Надо точно понимать, как происходит взаимодействие тех узлов в системе, в которые мы хотим это внедрять. Какие протоколы используются, какая сетевая подсистема, Kubernetes, как сейчас происходит взаимодействие инстансов в нашей системе. Вообще представлять, как работает на текущий момент наша система.

Ключевым я бы назвал понимание именно сетевого стека работы всех систем, протоколов, TCP, прикладных протоколов, которыми общаются микросервисы в системе. И в целом понимание того, как архитектурно работают такие распределенные системы.

Чего-то особенного тут, в принципе, нет. Это система, которая использует достаточно стандартные подходы, стандартные технологии для своего внедрения, поэтому каких-то базовых знаний, в принципе, достаточно. Но важно понимать именно сетевую составляющую, как происходит взаимодействие узлов.

Ты сказал, что service mesh это нечто посередине между разработчиками и теми, кто занимается эксплуатацией. А какая роль разработки здесь? И вообще, внедрение service mesh влияет на работу разработчиков?

Это зависит от того, каким образом оно внедряется и потом поставляется. Я имел в виду, что, с одной стороны, инфраструктурный компонент, который достаточно низкоуровнево внедрятся во взаимодействие между узлами, на самом деле решает те задачи, которые обычно решают разработчики в своем коде, прямо в своих микросервисах. И это инструмент, который позволяет как бы перевести на уровень ниже это. Поэтому здесь и возникает такой момент, что, с одной стороны, внедряют это обычно ребята из платформы, те, кто занимается инфраструктурой, но, с другой стороны, в результате получаются фичи, которые нужны в первую очередь разработчикам микросервисов. Например, circuit breaker паттерн.

Это вещи, которые нужны разработчикам и поэтому разработчики обычно здесь вовлечены с той стороны, что они, во-первых, должны понимать, какого рода дополнительные фичи вносятся во взаимодействие. И во-вторых, в зависимости от того подхода, который выбирает компания, они могут либо их настраивать (то есть понимать, какие есть возможности и применять манифесты для настройки этого взаимодействия), либо с помощью каких-то более высокоуровневых абстракций, инструментов, также опосредованно использовать эту технологию. Например, говорить: я хочу, чтобы ко мне была другого вида балансировка трафика. И оно там под капотом в итоге улетает в service mesh и применятся. Поэтому это что-то посередине. Конечно, с точки зрения внедрения, это больше со стороны инфраструктуры, но интересует и разработчиков.

О чем ты будешь рассказывать на мартовском интенсиве по service mesh?

Когда мы приходим компанией к тому, что эта технология нам полезна, и мы хотим ее потрогать, посмотреть и внедрить в будущем в своей компании, здесь есть два поинта.

Первый состоит в том, что эта технология достаточно сложна в первоначальном входе, есть много различных компонентов, возможностей, настроек, и нужно разобраться вообще, как это все архитектурно устроено, за что каждый компонент отвечает. Понять, как работают все эти механизмы, чтобы подступиться к внедрению технологии или наоборот понять, что такой подход нам вообще неинтересен и неприменим в конкретном случае. Поэтому первый момент, который будет раскрываться, это именно сама механика работы. Что это за технология, как она позволяет закрывать эти проблемы, которые мы обсуждали.

Второй момент очень важен для компаний, особенно крупных, у которых есть фокус на то, что все системы должны работать стабильно, без даунтаймов и действительно нет возможностей для экспериментов на продакшене. На самом деле, большинство компаний такие. Крайне важно понимать, какими шагами можно прийти к тому, чтобы эту систему полноценно внедрить и внедрить без каких-то неожиданностей в продакшене. И здесь есть путь, который мы прошли, есть большое количество граблей, на которые мы наступили и сами словили в момент и внедрения, и эксплуатации этого решения.

Поэтому есть важные моменты, которые в каждой части курса мы будем рассматривать, как правильно подходить к внедрению разных частей service mesh. Расскажем в целом, как этот процесс вести таким образом, чтобы не ронять всю систему и понимать в будущем, в момент эксплуатации, что у нас вообще происходит.

Service mesh это технология, которая на самом низком уровне радикально меняет инфраструктуру. И если вдруг в момент эксплуатации что-то идёт не так, это обычно приводит к катастрофе полные даунтаймы системы, серьезные последствия. Поэтому очень важно понимать, как все устроено и как в эксплуатации быть уверенным в том, что все работает в штатном режиме и в случае проблем быстро это исправлять.

Основной упор всё-таки будет сделан на Istio?

С помощью Istio мы будем рассматривать именно подходы и брать его как основную реализацию. То есть, смотреть, как это все использовать, все основные фичи и так далее. Но envoy proxy это сейчас основное решение, вокруг которого базируется большинство service mesh, и мы не будем прямо сильно фокусироваться на каком-то интерфейсе Istio и, грубо говоря, изучать, какие ключи нужно ввести, чтобы получить определенную настройку.

Мы будем смотреть в сторону возможностей и просто с помощью Istio их быстро настраивать, чтобы понять, как оно работает внутри, как это правильно внедрить в свою систему, какие там механики действуют под капотом, потому что это самое важное при внедрении и при использовании технологии понимать, как оно всё работает внутри. Но Istio это хороший пример, потому что практически все возможности в нём реализованы, и с использованием этого инструмента мы как раз можем пощупать это со всех сторон, всё попробовать.

Как будет проходить практика?

Несмотря на то, что service mesh это подход, мы говорим о конкретных технологиях и конкретных решениях, и поэтому большая часть интенсива будет посвящена практике. Рассмотрим различные зоны возможностей этой технологии и попробуем их внедрить на конкретной системе.

Ключевой момент будем не просто смотреть на то, какие там фичи есть, и пробовать их, мы будем работать в условиях, максимально приближенных к реальным. У нас будет некоторый проект без service mesh, он будет крутиться в Kubernetes-кластере, жить своей жизнью. И мы будем внедрять эту технологию, смотреть, как это корректно делать именно в таких условиях, когда у нас уже что-то есть. Потому что большинство компаний будут внедрять не с нуля, и нам это важно отработать. Также все кейсы мы берем из реальной практики и будем последовательно закрывать возникающие проблемы с помощью service mesh.

Кому не стоит идти на этот курс?

Тем, кто осознал все возможности и особенности и понял, что никакая проблема из существующих не решается с помощью service mesh. Тем, кто работает с системой, которая состоит из одного кусочка, где просто нет этого уровня проблем: проблем взаимодействия большого числа узлов, безопасности и так далее. Потому что очевидно: когда у нас 1-2 элемента в системе, это всё можно сделать руками, без использования этих подходов.

А если говорить про уровень специалистов? Интенсив рассчитан на техлидов или специалистов, которые потенциально могли бы это внедрять?

С одной стороны, можно сказать, что это будет полезно тем, кто еще сомневается, не принял решение, и это могут быть техлиды и вообще человек, который активно не работал с Kubernetes он получит одного рода инсайты из этого курса. Но я проектировал интенсив направленный на то, чтобы человек после него имел полное представление о технической части, как возникающие проблемы решаются и в итоге качественно и с полным пониманием технологии мог её внедрять. Поэтому целевая аудитория практикующие инженеры эксплуатации, платформенные и инфраструктурные разработчики. Их и ожидаю увидеть!

Интервью подготовила Виктория Федосеенко Vika_Fedoseenko

KubeGraf это плагин для Grafana, который собирает данные с кластера Kubernetes и приложений внутри него, а затем показывает их на красивых и понятных графиках. В феврале этого года вышел релиз 1.5, и стало известно, что предыдущие версии скачали более 250 тысяч раз! Мы расспросили Сергея Спорышева, создателя плагина и директора направления DevOps-продуктов в ITSumma, об истории создания плагина, факапах и причинах популярности.

Сергей Спорышев участвует в создании курса по мониторингу и логированию в Слёрме, набор на который уже начался. В конце интервью мы немного поговорим и про курс тоже.

Как-то, рассказывая о разработке KubeGraf, ты упомянул, что вы хотели сделать универсальный инструмент для мониторинга, который поставил и ничего больше делать не надо. Что скажешь спустя полтора года: получилось ли?

Я думаю, получилось. Здесь логично рассказать, откуда возникла идея плагина. В апреле 2019 года я помогал Евгению Потапову, гендиректору ITSumma, готовить доклад для конференции HighLoad в Питере. Он планировал рассказать про мониторинг Kubernetes: какие есть инструменты, подходы Всего этого и методологий, и инструментов, было очень много, но какого-то более-менее универсального решения, чтобы поставил и ничего делать не нужно, не было.

Углубляясь, мы нашли у самой Grafana плагин для мониторинга Kubernetes. Он вроде был жив, но почему-то не поддерживался. Мы его поставили и увидели, что половина функций не работает. Так возникла идея написать своё и докинуть туда багаж практик, который мы наработали внутри компании (одно из направлений ITSumma как раз техподдержка 24/7 и, соответственно, круглосуточный мониторинг).

Была ещё одна вещь, которую мы хотели реализовать. В России раскатка на bare metal это нормальное явление, а все прогрессивные страны пользуются managed-решениями: Kubernetes от Google, Amazon (у нас теперь ещё Яндекс и Mail.ru). В работе с облаками есть свои нюансы, и мы подумали почему бы не сделать плагин, который будет эти нюансы учитывать?

Такой был план: написать плагин, основываясь на решении, выпущенном самой Grafana, дополнить его своими наработками и сделать так, чтобы он работал везде одинаково. Я думаю, получилось. Лично я его юзаю, и наши клиенты тоже: причём как те, кто на голом железе сидит, так и те, кто сидит в Google и Amazon. Лишних телодвижений делать не приходится никому.

А какие фичи плагина ты используешь каждый день?

Одна из основных фишек это как раз возможность работы с облачными провайдерами. Обычно во всех этих системах используется авторизация по сертификатам. В облаке сертификаты тебе никто не даст, поэтому мы сделали возможность работы через токены. Ты применяешь кубовые манифесты, регистрируешь пользователя, выдаешь ему права, и с этим пользователем плагин работает.

Мы мониторим как приложения, которые крутятся в Kubernetes, так и ноды, на которых Kubernetes работает. В реальном времени можно смотреть нагрузку по ноде, сколько ресурсов на ней зарезервировано и какие выставлены лимиты. Например, мы индицируем, что у ноды есть всего лишь 2.5 Гб памяти, 2 Гб которых уже зарезервировано, и тогда подкрашиваем ноду жёлтым либо красным, таким образом предупреждая: Ребят, эта нода скоро закончится. То же самое с лимитами.

В реалтайме видно, какие именно приложения, какие поды Kubernetes крутятся на ноде, их можно группировать. Видно потребление и резервирование, лимитирование ресурсов для конкретного приложения. Это позволяет заметить, например, что какие-то приложения слишком много выжирают и надо бы их расселить.

Второй режим просмотра это так называемая Карта всех приложений. Виден список всех приложений, как они сгруппированы по неймспейсам, какие сущности за собой тянут, сколько там реплик. Все красивенько отображается.

Ну, и последний ключевой момент в одном месте сведена информация обо всех предупреждениях, ошибках, критических ситуациях. Ты можешь просто открыть страничку Cluster Status и посмотреть, что у тебя с кластером происходит. Куда надо обратить внимание, куда не надо.

Можешь вспомнить ситуации из своей рабочей практики, когда KubeGraf реально тебе помог?
Это случилось, когда мы научились правильно индицировать лимиты, реквесты и всё остальное. На одном из проектов облачный кластер Kubernetes в момент пиковых нагрузок разрастался до 25-26 нод. Мы стали смотреть на данные из плагина и, пользуясь ими, сократили парк почти в два раза. Сейчас этот же кластер с большим количеством приложений спокойно работает на 12-13 нодах.

При этом ресурсы кластера мы никак не разбирали. Мы просто смотрели, что такие-то приложения при таком-то трафике практически не должны ничего жрать, но потребление вырастает до колоссальных размеров. Анализировали приложение, смотрели, что где можно подтюнить, как именно построен scheduling на основе реквестов. Видели, например, что зарезервировано 1.5 Гб памяти, но за два месяца никто столько никогда не использовал и можно это сократить. Потихоньку-помаленьку сократили кластер в два раза.

В новостях о плагине вы писали, что его скачали 250 000 раз

По не совсем официальной информации да. Это такая информация для разработчиков, её в паблике нет, но вот я нечаянно узнал. Круто!

Это много или мало?

Много! У нас четыре с лишним сотни клиентов, у одного клиента может быть максимум кластеров 10. Если мы хотя бы 400 умножим на 10 это 4 000. То есть если бы каждый наш клиент был с Kubernetes, мы бы каждому накатили и получили только 4 000. А тут четверть миллиона! Это много и это круто.

Как думаешь, в чём причина такой популярности?

Один из ключевых факторов: плагин от Grafana, о котором я уже упоминал, разработчики по неизвестным причинам перестали поддерживать. И теперь в issues или в pull request на GitHub, я не помню точно, их спрашивают: ребята, вы собираетесь этот инструмент дальше развивать или нет? А они говорят: нет, вот вам ссылка на нормальное решение. И дают ссылку на нас.

Плюс сарафанное радио: мы раскидываем плагин клиентам, активно взаимодействуем с сообществом, много где его презентуем. Скорее всего, в этом причина.

А если оценивать аудиторию англоязычную, русскоязычную как тебе кажется, где KubeGraf больше используют?

Мне кажется, это неправильным в современном мире разделять аудиторию на русскоговорящую и не русскоговорящую.

Недавно вышла версия 1.5. Что там нового?

Мы починили большое количество ошибок совместимости. В середине 2020 года релизнулась седьмая версия Grafana, там всё еще работало, а с 7.3 начались большие изменения в структуре, поэтому пришлось дорабатывать плагин, чтобы ничего не отваливалось. Плюс добавили поддержку последних версий Kubernetes, доработали, по каким путям мы забираем данные из API Kubernetes.

В версии 1.5 мы добавили сбор метрик по лимитам для приложений. До этого работали только с реквестами и текущим потреблением: приложение сколько-то под себя резервирует и сколько-то использует в реальном времени. Но со временем поняли, что очень важна еще и работа с лимитами.

Переработали UX, чтобы было удобно для восприятия, добавили реалтайм индикации. Раньше была сводная таблица по всем приложениям, и мы просто видели, сколько они резервируют и потребляют. В 1.5 добавили индикацию: в табличке подсвечено, где что-то не указано, где зеленая зона, где желтая, красная и так далее.

Как обычно, были небольшие фиксы: где-то слетела легенда, где-то кнопка не работала поправили.

Последнее ключевое в сводной таблице по состоянию кластера мы наконец-то догадались ввести сортировку по важности уведомления: жёлтое, красное и т. д.

Алертинга у вас нет?

Тут можно холиварить долго, но устоявшееся мнение такое: алерты и Grafana это разные вещи. Алерты в Grafana делать можно, но это неправильно. Для алертинга нужен другой инструмент: Prometheus+Alert Manager, например. Grafana это про визуализацию. Мы только планируем на графике сделать индикацию алертинга.

Ты говорил, что многие фичи появлялись, исходя из ваших потребностей. А были такие, которые вы делали по запросам?

Конечно! Здесь соотношение где-то 60/40. 60 это наша практика. 40 это общение с комьюнити, с клиентами. Сейчас мы работаем над версией 1.6, и одним из ключевых новшеств в ней будет обновлённый дашборд. К нам пришли клиенты, которые активно юзают плагин, и говорят: ребята, мы пользуемся, всё круто, но хотелось бы увидеть ещё такую вот панель. Мы отвечаем: ну, супер.

Запросы на разные фишки по дашбордам тоже приходили от клиентов, так что сообщество играет здесь большую роль. Большая часть, конечно, это наши клиенты, потому что они могут прямо в клиентский чатик написать я приду, поговорю, обсудим.

Заспойлери что-нибудь ещё из версии 1.6.

Будет небольшой редизайн, потому что первый макет создавался кустарно. Сначала мы с Женей Потаповым набросали на бумажке, как может выглядеть интерфейс. Потом один из наших разработчиков разобрал тулкит Grafana с визуализационными элементами, и мы просто впихали всё, как было. Позже подключился дизайнер, и где-то в версии 1.3-1.4 мы переработали одну из страниц. Теперь перерабатываем остальные и в 1.6 затащим красоты.

Плюс к странице Cluster Status появится сводный дашборд по общему состоянию кластера. Не по отдельным нодам, а именно по всему кластеру, как если бы он был одним большим сервером. Дашборд даст понимание, как он себя чувствует.

Ну и мы хотим полностью переписать плагин. С выхода первой версии прошло два года, Grafana выпустила много вспомогательных инструментов для разработки. Поэтому мы полностью переписываем сборку, переходим на использование компонентов от Grafana и другой фреймворк: плагин написан на Angular, а где-то год назад пошёл тренд на React-плагины, поэтому я думаю, что после 1.6 будет сразу версия 2.0 на React.

С какой скоростью выпускаете новые версии?

Критичные минорные изменения вносим так быстро, как это только возможно, но вообще стараемся релизиться раз в два месяца. Только с версией 1.5 что-то пошло не так готовили её почти полгода. Сказался и личный загруз (это все-таки наш open source проект), и эпидемия, и задержки со стороны Grafana. С релиза версии может пройти от недели до двух месяцев, когда её примут и опубликуют на сайте Grafana. Поэтому релизный цикл плавающий.

Как устроена работа над плагином: сколько человек в команде, сколько времени каждый из вас уделяет разработке?

Команда это два разработчика: я и мой коллега Дмитрий Воронов. Когда нужно, подключаем дизайнера. Менеджерю этот процесс я сам. Если по работе у нас ничего не горит, то понедельник мы посвящаем плагину. Понедельник у нас Grafana Day, такая разминка перед тяжёлой рабочей неделей.

То есть это не выходные, не ночь, а полноценный рабочий день?

Да. Единственное это предрелизная штука, когда обычно я на себя всё захватываю. Там может выжирать и три дня в неделю. Но стандартно день.

В таком режиме получается отдыхать от плагина? Когда два года делаешь какую-то штуку, она может слегка поднадоесть, нет?

Бывает такое, но можно взять на неделю перерыв. Это же pet project: поднадоело давайте отложим.

Были за эти два года такие факапы, которые прям совсем факапы?

Конечно, они бывают в любой разработке. Как-то раз выкатили версию, которая не работала. Потестили на одной из версий Grafana, а на остальных нет. Где-то всё поехало, где-то метрики перестали приходить.

Заметили довольно быстро, потому что мы обычно, пока ждём официального релиза от Grafana, ходим и через Git и обновляем это всё у наших клиентов. Видим, где ломается.

Второй факап был прямо жёсткий. В одной из версий Kubernetes и Prometheus полностью сменился лейблинг. До этого в основных метриках было два лейбла: container name и pod name, а тут они поменялись на container и pod (я уже сейчас не вспомню точно). В какой-то момент мы заметили, что нейминг разъехался: здесь мы собираем по pod, здесь по pod name; здесь по container, здесь по container name. И у нас половина плагина работала, половина не работала. Никто сначала ничего не мог понять. Пришлось пойти, разобраться, упороться регулярками, которые все ненавидят. Ну и вроде собрали, заработало.

Но, в целом, за счет того, что time-to-market у плагина очень высокий, у нас всегда есть минимум две недели в ожидании релиза, когда можно сходить всё исправить. То есть факапы они локальные, в паблик не могут уйти.

Если бы ты сейчас подходил к разработке плагина, что-нибудь бы сделал иначе?

Думаю, нет. Я даже не знаю, что можно было изменить, потому что оно как шло по желанию, так и шло. Какие-то фишки придумывались, какие-то дорабатывались. Что-то изменить? Не знаю.

Какую побочную, помимо технической, пользу принёс плагин тебе самому и вашей компании?

Brand awareness узнаваемость бренда. Это самое большое, что мы получили. Когда компания выпускает open source продукты, она закрепляет свою экспертизу, повышает узнаваемость. На приток клиентов не рассчитывали. Хотели только, чтобы нас узнавали, чтобы люди понимали, что мы это умеем и в этом шарим.

Мне кажется, у нас получилось, потому что про плагин писали везде. Очень много материалов в интернете, и везде ссылочки на нас. Да, определённый процент клиентов приходили с плагина: понимали, что в теме Kubernetes и мониторинга нам можно довериться, и работали с нами дальше.

В небольшом видео с анонсом версии 1.5 ты сказал, что вы планируете сделать плагин отдельным продуктом. Что это за идеи?

У нас была мысль сделать плагин прямо такой stand-alone версией, потому что мы наработали большое количество практик в работе с Kubernetes, и хотели бы их реализовать в отдельном продукте.

Мы думаем про сервис, который будет делать не только визуализацию, но поможет проводить аудит кластера и тюнить его. Grafana здесь будет только мешать, поэтому думаем оформить его в виде stand-alone решения, которое просто так же поставил через Helm и видишь красивую картиночку, где у тебя что происходит. Но это всё пока только на уровне проработки концепции.

Еще какие-то плагины делать? Я пока не знаю. У нас было много идей, как можно что-то визуализировать. Пока руки не доходят.

Если это будет отдельный продукт, который будет шире, чем просто мониторинг и визуализация, он будет платным?

Open source продукты принято делать бесплатными. Но, например, Grafana тоже open source, но есть Grafana Enterprise. Мне кажется, этот продукт будет в двух вариациях free и с какой-то подпиской.

Такой серьезный продукт придётся не только по понедельникам делать.

Да.

Выходит, ITSumma сейчас смотрит чуть в сторону open sourse, в направлении разработки своих продуктов?

Конечно! Нужны же какие-то артефакты работы компании. Хоть что-то после себя оставить нужно.

На этом мы закончили обсуждать плагин KubеGraf и немного поговорили о видеокурсе по мониторингу Kubernetes, который Сергей Спорышев вместе с другими спикерами разрабатывал в Слёрме. К беседе присоединился СТО Слёрма Марсель Ибраев.

Что будет в новом курсе?

МАРСЕЛЬ: Мы будем говорить о том, как мониторить и собирать логи с приложений, которые запущены в кластере, и с самого кластера Kubernetes. Потому что просто поднять кластер это полдела, и с этим справляется большинство, а вот правильно настроить сбор логов и метрик уже получается не у всех. Цель курса рассказать и показать лучшие практики.

Стоит ли идти на курс по логированию тем, кто уже проходил курсы по Kubernetes в Слёрме?

МАРСЕЛЬ: Стоит, потому что в наших курсах по Kubernetes не раскрывается тема логирования и мониторинга. Мы пробовали её включить в первые базовые курсы, но получалось не очень: материала много, и дать его в рамках двух занятий внутри обзорного курса по Kubernetes невозможно. Уже тогда была идея, что надо делать что-то отдельное. Наконец-то мы к этому пришли.

Чем хорош курс? Почему вы бы сами на него пошли?

МАРСЕЛЬ: Во-первых, курс подготовили практикующие инженеры ребята, которые каждый день работают с Kubernetes, набивают шишки. Они рассказывают именно то, что нужно знать. Это чистый опыт. Да, его можно наработать и самому, но мы конвертируем время в деньги (и наоборот) и приносим опыт на блюдечке.

Мы не обещаем, что, пройдя курс, вы сразу станете крутым специалистом. Чтобы освоить все инструменты, нужно много практиковаться. Но начать это делать можно уже во время обучения. И это вторая причина, по которой я бы сам на него пошёл: Слёрм даёт практические задания и стенды для их выполнения. У студента есть все возможности, чтобы закрепить знания на практике и получить навыки, которые потом можно оттачивать на реальных проектах.

Сергей, ты один из спикеров курса по мониторингу и логированию в Kubernetes. Как тебе кажется, чем этот курс хорош?

СЕРГЕЙ: Я впервые участвую в создании такой штуки, но, посмотрев на внутреннюю кухню, поучаствовав в проработке одной из тем, пообщавшись с другими спикерами, я понял, что все спикеры максимально детально разжевывают материал, но делают это не в формате старых книг вроде PHP для чайников, а на реальных практических примерах, затрагивая современные аспекты технологии.

Сама площадка тоже топчик. Я планировал писать на локальном кластере, но потом понял, что всё есть, всё удобно, и с минимальными усилиями за минимальное количество времени ты можешь попробовать выполнять практические задания, в реальном времени видеть результат.

Всё сделано по-максимуму для студента, слушателя курса. Без воды, без лишнего материала. Всё учтено. Такая тонкая грань между вводом и хардкором.

Программа курса максимально последовательная. Когда меня только привлекли к подготовке, я прочитал план и понял, что он составлен идеально. Студента проводят по тем же этапам, которые он бы прошёл сам, настраивая мониторинг и логирование.

Кому будет полезен этот курс?

СЕРГЕЙ: Есть замечательная шутейка, что в современных реалиях Kubernetes это операционная система, а Helm просто пакетный менеджер для него. Всем приходится иметь дело с Kubernetes, значит всем нужно знать мониторинг и логирование такой промышленный стандарт. То есть курс будет полезен всем.

Какие знания необходимы для учёбы?

МАРСЕЛЬ: Мы рассчитывали курс на тех, кто уже знаком с Kubernetes. Знание систем контейнеризации, Docker в первую очередь, тоже горячо приветствуется. Без них будет тяжело, потому что в рамках курса мы не рассказываем о базовых абстракциях.

Предполагается, что у человека есть кластер, он с ним уже работал, но просто не знает, как правильно настроить мониторинг.

Нужно ли идти на курс, если что-то уже настраивал сам?

МАРСЕЛЬ: Думаю, да. У всех свой взгляд, как это сделать и настроить. Иногда я узнаю, как некоторые делают очень страшные вещи, строят костыли, где не надо, и прочее. Поэтому хочется, чтобы люди просвещались в этом вопросе. В рамках обмена опытом, скажем так.

Что ещё важно сказать про курс?

МАРСЕЛЬ: Первая версия прошла тестирование. Бета-тестеры дали очень много фидбека, после которого мы изменили программу. Например, в программе был Zabbix, а потом мы поспрашивали ребят, экспертную группу, и поняли, что он там не нужен, поэтому убрали его и добавили другие темы. Кроме того, мы значительно усилили команду спикеров, подключили ребят из ITSumma.

Бонусом студенты получают видеокурс о Prometheus. Он будет полезен даже для тех, кто с Prometheus никогда не работал.

Узнать больше о курсе и записаться

К 2021 году Ansible уже стал стандартом в администрировании. В трёх из четырёх DevOps вакансий просят знание Ansible. Из них только в одной из четырёх это преимущество, в остальных требование.

Для тех, кто еще не работал c Ansible или только пользовался ролями и плейбуками, написанными коллегами, мы готовим новый курс Ansible: от первых шагов до большого проекта.

Спикер Всеволод Севостьянов из vene.io (Берлин).

Программа курса

Тема 1. Инсталляция LEMP стека на машину (ручной инсталл)
Инсталляция LEMP стека на несколько машин
Что такое автоматизация инфраструктуры
Что такое Ansible
Требования Ansible
Установка Ansible

Тема 2. Инсталляция LEMP стека с помощью Ansible (playbook, ansible.cfg, hosts, templates)
Пишем первую роль
Пишем плейбук
Пишем конфигурацию
Ansible Galaxy
Практика. Деплой Symphony приложение на PHP с помощью Ansible

Тема 3. Python stack (modules, handlers)
Raw модуль
Устанавливаем uWSGI для сервера
Самоподписанные ssl сертификаты (Lets encrypt )
Практика. Деплой Flask приложение на Python с помощью Ansible

Тема 4. Не веб приложения (roles, jinja2, реестры, группировка хостов, переменные, postgresql_db, postgresqluser, mongodb, script модули, CHANGED WHEN, FAILED_WHEN)
Установка proxy сервера с помощью Ansible
Postgres cluster
Mongo cluster
Практика. Собираем Docker-контейнеры

Тема 5. Патчинг и апдейты с помощью Ansible (pre_tasks, post_tasks, include, serial и мax_fail_percentage, блоки, выбор хостов, лимиты)
Оркестрация
Что такое rolling update и как его накатывать
Практика. Накатываем апдейт веб-приложения под нагрузкой

Тема 6. Как автоматизировать рутинные задачи и зачем (коллбеки, как ускорить Ansible)
Запуск расчетных задач по расписанию
Практика. Автоматизируем ротацию логов и оценку свободного места на
машинах

Тема 7. IaaC и деплой плейбуков
Git hooks с Ansible и автодеплой (Gilab API integration, Gitlab runners)
Практика. Организуем деплой для мультисервисной системы (микросервисное веб-приложение)

Тема 8. Мониторинг (фильтрация логов)
Что такое Prometheus
Сбор системных данных
Сбор логов
Практика. Устанавливаем и настраиваем бизнес/системный мониторинг

Тема 9. Защищенные системы и правильная настройка Ansible в них (подстановки,
фильтры, в целом работа с облаками включая подъем новых машин)
Работа с Google cloud и AWS используя Ansbile
Ansible Vault и что в нем можно хранить
Bastion и правильная настройка Ansible
Ansible Tower
Как лучше ставить воркеры в сети для enterprise окружения

Тема 10. Написание своих модулей
Тема 11. Обзор конкурентов Ansible

Релиз запланирован на 27 августа.
До 6 августа курс стоит 30 000 рублей, а еще можно стать консультантом-тестером и повлиять на итоговую программу.
С 7 августа 40 000 рублей, доступна рассрочка.

Подробнее о курсе