Андрей Квапил (kvaps) — Solutions Architect в компании Флант. Путь в ИТ он начал с подработки эникейщиком во время учебы в школе. А сейчас создает платформы для автоматического управления инфраструктурой, участвует в open-source-сообществе, пишет статьи и выступает на конференциях. Поговорили с Андреем о его карьере в ИТ, переезде в Чехию и выступлениях на конференциях.
Андрей — один из спикеров VK Kubernetes Conference, которая пройдет 9 декабря 2021 года.
— Начнем издалека. Ты помнишь, когда впервые начал интересоваться ИТ?
— Первый компьютер в нашей семье появился у деда — он работал профессором в МГУ. Это был Pentium 1 133 Mhz с 32 Мбайт памяти, еще с кнопкой Turbo. Мои старшие братья часто играли на нем в Larry, а мне не разрешали. Но меня тогда интересовал не сугубо развратный подтекст игры, а то, насколько широко она использует возможности компьютера. Звуковых карт тогда еще не было, но музыка проигрывалась через спикер. Мне это показалось крутым: компьютер играет музыку, ничего себе!
Через некоторое время компьютер появился и в нашей семье, в основном его использовала мама для работы, она архитектор. Игр практически не было, интернета тоже.
Развлекаться и проводить время за компьютером хотелось, и не мне одному. Однажды я заметил, как моя сестра копалась в системных файлах и нашла много интересного: картинки, видеоролики, системные звуки. Для меня это было большим открытием. Я начал повторять за ней — изучать, что еще можно найти, и таким образом познавать недра Windows. Позже я рисовал скины для Winamp, Light Alloy, QIP и других программ, но тяга к изучению компьютеров и систем появилась у меня именно в этот момент.
— Какой была твоя первая работа в ИТ?
— Я начал работать в 12 лет, когда еще учился в школе. Устроился курьером в офис, где работала мама. Но мою тягу к компьютерам быстро заметили, и я начал подрабатывать эникейщиком.
В компании было несколько серверов, в основном все на Windows. Но была и одна загадочная для меня машина, на которой крутилась Gentoo. Большую часть времени на ней была запущена консоль, но минимальный GUI тоже был: XWM и XScreenSaver с его глючными заставками. В компании работал матерый сисадмин, он рассказывал мне про Gentoo, и для меня это было чем-то странным и завораживающим, но пока недоступным.
Спустя время этот матерый админ покинул компанию, а я понял, что хочу админить не только Windows-серверы, но и Linux. Как раз подвернулась задача — поднять почтовый сервер. На тот момент я еще ничего не знал ни про Postfix, ни про Exim, а решил использовать проприетарный Kerio Connect. Установить его не составило особого труда, но вот настроить роутинг и пробросить порты в iptables для меня оказалось не совсем простой задачей.
Именно тогда первый раз обратился в публичный IRC-чат за помощью и осознал силу комьюнити. В общем, начал понемногу набираться опыта.
— Ты где-то обучался администрированию, Linux и другим технологиям?
Андрей Квапил на DevOps Conf 2021 рассказывает про GitOps
— Нет. Все произошло само собой. Я поступил в колледж, учился на оператора ЭВМ — это был трехлетний курс о том, как заполнять таблички в Excel, базы данных в Microsoft Access, и программировать в Visual Basic. Мне это не было интересно, да и к тому времени я уже и так много знал.
Потом поступил в Московский институт радиотехники, электроники и автоматики. Мне нравилось учиться, но предметы по специальности мне были неинтересны — я знал гораздо больше некоторых преподавателей. На одном занятии произошел забавный случай. Преподаватель начал показывать прошивку DD-WRT, а затем сказал: «А вообще, это вам лучше Андрей расскажет», и показал на меня.
Я параллельно и работал, и учился — времени на все не хватало. В итоге пришел к выводу, что реальная работа в компании даст мне больше, чем институт, и через полгода бросил учебу.
— Хорошо, давай перейдем к работе. Можешь рассказать о своем пути от эникейщика до Cloud-архитектора и DevOps-инженера?
— На тот момент я админил Windows-серверы и занимался сетью. Я хотел быть Linux-админом, хотя практически ничего не знал о Linux.
Пробовал найти новую работу, но с небольшим опытом в Linux меня не брали на полноценного Linux-админа. Спустя время устроился в системный интегратор ЛанКей, так как они предлагали возможность бесплатно получать сертификаты Microsoft, которыми я надеялся прокачать свое резюме.
Но вместо этого я пошел на аутстаффинг в компанию Konica Minolta. Аутстаффинг — это когда компания предоставляет своих специалистов другой фирме as a service. То есть я был трудоустроен в ЛанКее, но по факту работал в Konica Minolta. В основном поддерживал уже существующую Windows-инфраструктуру и занимался текучкой. Например, подготавливал ОС и заливал ее на компьютеры, устанавливал обновления, решал проблемы пользователей.
Спустя время из российского подразделения Konica Minolta ушел штатный ИТ-менеджер. Они долго не могли найти нового, и поэтому мне стали прилетать и более сложные задачи вроде переустановки и настройки продакшен-серверов. Благодаря этому я многому научился в плане устройства систем и их взаимодействия. Даже смог внедрить Linux там, где это было оправдано: поднял Apache для лендингов, за что получил прозвище Linux fanboy.
Но все равно у меня не было настоящей работы с Linux, а мне очень хотелось. Дома экспериментировал с Proxmox, Zentyal и прочим, но все это было just for fun.
Когда набрался больше опыта, начал искать работу целенаправленно как Linux-администратор. Устроился в системный интегратор Crosslab. Мы предоставляли клиентам инфраструктурные решения, построенные преимущественно на свободных технологиях. А вообще, много чем занимались: закупали серверы, протягивали сеть, настраивали телефонию.
Как раз в Crosslab я получил основной опыт работы с Linux. Начиналось все с настройки Proxmox, Kolab Groupware, Owncloud, Asterisk, а позже появились и более интересные задачки.
Например, большинство наших пользователей работали не локально, а на удаленном сервере. И хотя на их локальных компьютерах использовалась преимущественно Ubuntu, настраивать и поддерживать операционную систему в актуальном состоянии было неудобно.
Мы хотели внедрить Thinstation, он позволял собрать единый образ системы со всем необходимым и раздавать его на клиентские машины по PXE. Но позже я наткнулся на проект LTSP — и это была просто бомба. LTSP позволял настроить один сервер, который использовался для загрузки всех рабочих станций в офисе. Обновлять и вносить изменения в такой сервер было очень просто, и я взял этот проект себе на вооружение.
Позднее появилась еще одна интересная задача. Нужно было организовать некоторое подобие VDI — то есть сделать так, чтобы при подключении пользователя к серверу для него создавалась отдельная виртуальная машина из шаблона. А после того как пользователь поработал в этой машине и сохранил все на удаленную шару, виртуальная машина уничтожалась. Я использовал для этого OpenNebula, потому что она реализует облачный паттерн, легко кастомизируется и отлично подходит для такой задачи.
Обо всех интересных кейсах я старался писать на Хабр. Цель этих статей — не заявить о себе, а рассказать сообществу об интересных open-source-проектах и их применении в реальной жизни. Также это помогло мне лучше структурировать материал у себя в голове. Кто-то пишет в блокнотик — я пишу статьи на Хабр.
Забавно, что статьи с Хабра иногда переводят на английский сервисы, зарабатывающие на рекламе, причем с помощью грубого машинного перевода. Так перевели несколько моих статей, и на одну из них наткнулись ребята из WEDOS. Они как раз искали решение для своего дата-центра и собирались полностью переходить на виртуализацию. И предложили мне развернуть для них отказоустойчивый кластер OpenNebula с Ceph по разовому контракту.
Была загвоздка: систему нужно было установить на блейд-серверах без iLO и возможности подключить внешний ISO. То есть единственный возможный вариант установить систему — раздать установочный образ по PXE.
Самое забавное, что по ошибке я почти сразу потерял доступ к PXE-серверу. К счастью, у меня остался доступ к шасси, в котором работали и другие тестовые серверы. Пришлось взломать один из них, чтобы раздать загрузочный образ с него. Сейчас вспоминаем эту ситуацию со смехом.😅
Когда завершился разовый контракт, меня пригласили на постоянную работу в Чехию. Я согласился, они помогли нам с женой переехать: предоставили квартиру с мебелью и помогли оформить документы. Еще так забавно получилось, у меня ведь фамилия чешская. И я подумал: «Это знак, надо ехать».
Андрей Квапил на Saint HighLoad++ 2021
— Интересный опыт, и как все это привело тебя в Kubernetes?
— В WEDOS я продолжил заниматься OpenNebula и LTSP, но в этот раз соединил эти два решения вместе. Мы сделали так, что серверы грузятся по PXE с LTSP-сервера, а затем с помощью OpenNebula на них накатываются виртуальные машины.
Но виртуалки — это только вершина айсберга. Еще у нас были веб-хостинг, почтовые серверы, базы данных, и все это требовало инфраструктуры, которой на тот момент просто не было. И большую часть времени я занимался созданием этой инфраструктуры. В итоге появилась некая платформа, на базе которой работают все остальные сервисы компании: OpenNebula, веб-хостинг, базы данных и другие.
Изначально мы планировали запускать все в OpenNebula, но очень не хотели иметь накладные расходы на виртуализацию. В то же время мы понимали, что это нужно как-то автоматизировать. У нас не было проблем с провижинингом физических нод — LTSP полностью закрывал эту задачу. Но нам нужно было найти решение, которое позволило бы распределять рабочую нагрузку на них.
На тот момент у меня уже был опыт с Docker, и я начал искать решение, которое позволило бы автоматизировать запуск контейнеров на нодах. Я пробовал Docker Swarm, Rancher, Kubernetes. И Kubernetes оказался единственным решением, которое удовлетворяло наши нужды.
Впоследствии Kubernetes отлично вписался в эту идеологию: наши ноды не имеют персистентной ОС, они загружаются по PXE, подключаются в Kubernetes-кластер, а уже он автоматически раскатывает на них рабочую нагрузку и следит за состоянием.
Но чтобы работать с Kubernetes, нужно сначала перестроить свой : здесь у тебя уже нет статических IP-адресов, сеть работает по-разному для ingress- и egress-трафика, нужно более динамическое хранилище. У нас же на тот момент практически все сервисы были Legacy и Stateful. Поскольку Kubernetes на тот момент не был приспособлен для запуска Stateful-приложений, то и его использование в нашей инфраструктуре было достаточно нестандартным решением.
— И как вы решали эту проблему?
— Долгое время мы вообще не использовали сеть в K8s, а создавали обходные решения. Например, почта должна была уходить всегда с конкретных IP-адресов, назначенных подам. Даже сейчас есть всего пара решений, которые позволяют контролировать egress-трафик в зависимости от назначенных лейблов, но они еще не production-ready. А в то время для такой задачи не было вообще никаких решений. И мы прикрутили Pipework в обход сети Kubernetes, а сам кубер использовали только как оркестратор.
Другой пример — когда мы начали использовать BeeGFS, были проблемы, связанные с частым обращением к метаданным. Когда пользователи переписывали много мелких файлов, это плохо выживало. Чтобы этого избежать, мы решили создавать большие loopback-девайсы поверх кластерной файловой системы, внутри них размещать обычную ФС вроде ext4, и все это уже монтировать в контейнеры. На тот момент для Kubernetes еще не было CSI, поэтому мы написали несколько Flexvolume-драйверов. Однажды я даже написал контроллер на чистом sh :-)
Так я постепенно адаптировал Kubernetes под наши нужды и задачи, параллельно разбирался с его устройством. Впоследствии хорошо в нем разобрался, особенно в тех вопросах, которые не очень широко освещены. Большинство людей опасаются использовать Kubernetes для Stateful-приложений, в нашем случае это основной кейс.
Недавно я получил интересный оффер от Фланта. Меня заинтересовали амбициозным проектом, для реализации которого уже есть все необходимое.
— Я знаю тебя как человека, который много делает для Kubernetes, а еще выступает с докладами и пишет статьи. Как ты к этому пришел?
Андрей Квапил на Saint HighLoad++ 2021 рассказывает про кластерные файловые системы
— Во-первых, я люблю делиться опытом в статьях и получать фидбек. Особенность русскоязычного комьюнити — жесткая, но конструктивная критика в комментариях. Например, мне пишут: «Это не сработает, нужно делать вот так». Я смотрю — точно, так и есть. Начинаю разбираться и узнаю еще больше нового. Так что комментарии на Хабре иногда полезнее, чем сама статья.
Во-вторых, во время подготовки статьи или доклада тебе приходится очень подробно разбираться в вопросе, структурировать информацию и искать противоречия. Это тоже сильно помогает прокачаться.
У нас в WEDOS была нестандартная инфраструктура: Kubernetes на Bare Metal, где 80% приложений — Stateful. Еще пару лет назад мало кто мог представить себе такое. Я часто делился опытом в телеграм-чате kubernetes_ru. Там меня и поймал SinTeZoiD и пригласил выступить на Kubernetes Meetup #2 в VK. Я долго готовился, вроде бы хорошо все рассказал, и аудитории зашло.
С этого доклада все и началось. Позже меня позвали ребята из Онтико, и я начал выступать на конференциях Олега Бунина. На DevOpsConf 2019 рассказывал про использование CI/CD для развертывания и управления BareMetal, а на Highload++ — про OpenNebula. На DevOpsLive 2020 мой доклад «Kubernetes-in-Kubernetes и ферма серверов с загрузкой по PXE» занял первое место по отзывам, и пошло-поехало.
— Отлично, и последний вопрос. Скоро ты выступаешь на конференции VK Kubernetes Conference. О чем будет твой доклад?
— Нашему основному Kubernetes-кластеру в WEDOS было уже больше трех лет, мы пережили 10 мажорных обновлений. За это время пришлось сменить большое количество CNI- и CSI-плагинов, несколько раз мигрировать сам Kubernetes. С одной стороны, доклад будет информативным — я подробно расскажу про то, как Kubernetes взаимодействует с этими интерфейсами. С другой стороны, поделюсь нашим опытом миграции между ними. В интернете об этом мало информации, и, поскольку мы через это уже прошли, будет полезно поделиться опытом.
VK Kubernetes Conference пройдет 9 декабря. Помимо Андрея Квапила, на ней выступают ребята из VK Cloud Solutions, Авито, Слёрма, Luntry, X5 Group. Участие бесплатное, программу можно посмотреть здесь.
Автор: Павел Селиванов
