Фестиваль РИТ 2018 в Сколково был большим и весьма разноплановым. Мобильная разработка, бэкенд, фронтенд, DevOps, управление проектами и даже психология – темы на любой вкус и в плотном расписании с утра до вечера. Темы разбиты по отдельным трэкам, трэки привязаны к залам. Если интересуют только специализированные доклады, можно обосноваться в нужном зале. Зал для кейноутов, правда, использовался по потребности докладчиками разных тем.
Я, по большому счёту, просвещался DevOps’кими знаниями, и после, делясь с коллегами впечатлениями от конференции, я сформировал шорт-лист запомнившихся мне докладов. Прошло несколько месяцев, и я все еще хорошо помню, о чем там говорили.
Итак, 3 технических доклада, которые я запомнил на РИТ 2018.
Мониторинг и Kubernetes
Используемый сейчас инструментарий мониторинга не так уж хорошо поддерживает приложения с микросервисной архитектурой. Чем больше динамики в системе, тем сложнее настроить для нее мониторинг. Удобный мониторинг для кластерных систем типа Kubernetes, доводящих динамику до экстремизма, вообще представляет из себя нетривиальную задачу. Почему так? Дмитрий Столяров, технический директор компании Флант, рассказывает о причинах этой сложности и ее влиянии на главную миссию мониторинга.
Традиционные системы мониторинга рассчитывают на работу со статичными серверами, которые сравнительно редко добавляются и удаляются из инфраструктуры приложений. В Kubernetes же создание и удаление окружений-подов и приложений-сервисов происходит ежесекундно, так что существующие процедуры автоматического обнаружения просто не справляются с этим объемом.
Количество самих окружений тоже исчисляется в десятках и сотнях. Соответственно во столько же раз увеличивается и объем передаваемой телеметрии. А ее еще нужно где-то хранить.
Отдельную проблему представляет столкновение физического и виртуального миров: потребление ресурсов приложениями в Kubernetes достаточно эфемерно и отражается в терминах ограничений подов. Но потребление ресурсов подами уже имеет конкретное физическое влияние на доступные серверные мощности. При взгляде на графики всегда приходится учитывать с какой точки зрения ты смотришь на ресурсы. На практике мало кого интересуют индивидуальные поды. Интерес представляет потребление ресурсов приложением в целом, а это уже требует гибкой группировки телеметрии подов по каким-то определяемым пользователям критериям.
И надо еще увеличить полученную схему в несколько раз для повсеместных dev/staging/prod окружений!
Доклад рекомендуется всем, кому приходится поддерживать кластера kubernetes.
Девопс в коробочной разработке
Нам было черезвычайно интересно послушать доклад Максима Лапшина, в котором он поделился редким опытом применения девопс-практик при разработке коробочных продуктов. Коробочный продукт — это такое традиционное software, которое устанавливается и работает на мощностях пользователей.
Erlyvideo разрабатывают сервер потоковой передачи видео, мы — сервер конфигурирования интернет-служб. Наши проблемы во многом похожи на те, что послужили причиной DevOps-трансформации Erlyvideo.
Максим начинает доклад с ответа на самый важный вопрос: "Для чего всё это?". Все те же факторы, которые драйвят внедрение девопс-культуры при разработке сервисов, присутствуют и в отраслях, где идёт более традиционная разработка. И влияние этих факторов в коробочных продуктах, пожалуй, будет драматичнее, чем при работе над сервисом. К примеру, чем реже релизы, тем больше объем изменений, который будет задеплоен. Если вы выкатываете новый сервис, вы можете убедиться или просто убедить себя, что это безопасно. Но если вы выпускаете дистрибутив продукта с большим количеством изменений, вам мало убедить себя в безопасности апдэйта, вам придется также убедить ваших пользователей в его безопасности. Небольшие, но частые порции изменений приходят здесь на помощь. И это только одна из проблем.
Доклад углубляется в эту и многие другие причины применения continuous delivery, проводя параллели и подчеркивая отличия от в целом более простой работы в CI/CD режиме с сервисами.
Как такое возможно? В докладе Максим описывает набор практик, применяемых в Erlyvideo для того, чтобы сделать непрерывную доставку потока изменений реальной. Многие подходы будут полезны as is, что-то потребует адаптации под реалии нашей работы. Но, в любом случае, эта замечательная история успеха способна вдохновить на переосмысление своих проблем и поиск решений во множестве DevOps-практик.
Доклад будет весьма интересно посмотреть всем, кто работает над дистрибутивами продуктов.
Сетевые базисы Kubernetes
Повсеместные quick start guide, crash course и tutorials "Как начать работать с kubernetes" позволяют сравнительно легко впрыгнуть в этот вагон, развернуть кластер и задеплоить приложение. Учитывая невероятную популярность этой темы, многие так и делают. Но не нужно забывать, что, по-существу, Kubernetes — достаточно сложная система, обслуживание которой требует специфического знания. В Ingram Micro Cloud такое знание потребовалось, когда очередное приложение внезапно стало недоступно по сети. С расследования этого инцидента и началось увлекательное путешествие Александра Хаёрова по сетевой подсистеме.
Доклад знакомит нас с постепенно усложняющимися элементами сетевого стэка Kubernetes, поясняя как из элементарных блоков складывается большая и сложная маршрутизация. Особенно интересно получается когда Александр рассказывает о том, почему сделано так, а не иначе, моделируя гипотетические другие варианты реализации.
Это действительно азбука Kubernetes, с которой придется столкнуться большинству пользователей. Я сам задавал вопросы "зачем nodePort?" и "почему я не вижу IP моего сервиса на интерфейсе?"
Интересно и познавательно.