Побывал на крайне интересном мероприятии — Kubernetes spb meetup #2 — в офисе компании Dell EMC. Хочу немного поделиться своими соображениями на этот счёт.
Изначально этот Митап, как я понимаю, больше собирался для Админов, Девопсов и прочих Опсов. Однако карты так легли, что разработчику в этот раз тоже было крайне интересно.
Первым выступал Афонинский Андрей — тех. лид из компании FullDive. Как я понял, Андрей — это человек со стороны разработки. А именно — бэкенда. Собственно поэтому, докладчик повествовал нам о процессах разработки, если вы и ваша компания используете kubernetes.
В принципе, доклад вышел интересным, но очень поверхностным. Ничего нового, наверное, от туда вынести не получилось. Если в кратце, главное, что вы должны помнить — это о стандартизации прошлого опыта в видео задокументированных принципов и библиотек, которые стоит переиспользовать в будущем. Такой подход позволит вам не наступать на грабли несколько раз подряд.
Для разработки микросервисов (про монолиты тут не говорили — сразу был дан совет не идти со старым легаси в кубер) следует использовать популярный подход — The Twelve-Factor App (12 правил создания микросервисов от Heroku). В целом, там нормальные правила о том, как и что делать, поэтому это однозначно хороший совет, не смотря на то, используете вы k8s, или нет.
Для переиспользования опыта использования непосредственно Кубера, с точки зрения Андрея, следует внимательно смотреть на Операторы. В частности, возможно стоит использовать фреймворк Операторов от CoreOs — The Operator Framework.
Андрей также советовал внимательно смотреть на Sidecar контейнеры. Это можно рассматривать, как «библиотека» для программы, так и Сайдкар — библиотека для Кубера. Обычно в рамках одного Pod-а запускают один контейнер (так принято, но никто не мешает запустить больше). Так вот, если вашему Контейнеру требуется какая-то инфраструктурная функциональность, то не обязательно реализовывать эту логику на языке программирования, усложнаяя бизнес-логику приложения. Всё инфстрактурное (метрики, прокси, гиты и т.д.) можно вынести в отдельные контейнеры, которые будут жить в одном Pod-е вместе с вашим бизнесовым контейнером.
Вторым выступал Жучков Михаил из Neuron Digital. Это доклад типичного админа для админов (много шуток про хипстеров программистов, и о важности админов 🙂 ). Доклад Михаила больше был похож на дискуссионный стол, где высказывалась некоторая проблема, а затем она обсуждалась. В частности, говорили больше всего о самой популярной теме — что делать с Stateful приложениями, и как с ними жить в Кубере.
Михаил рассматривал проблему Stateful на примере Кролика (RabbitMQ). Он рассказывал, как они с коллегами страдали из-за огромного количества Split-brain Кролика в Кластерной конфигурации на K8s. В конечном случае, они решили плюнуть на k8s в этом месте и перейти на виртуалочки поверх Bare metal. Шуточка заключается в том, что они отклазались ещё и от Кластера Кролика. Так что, я не очень понял, каким образом такое сравнение вообще возможно, ведь мы сравниваем тёплое с мягким.
Генеральная идея Михаила — не использовать Kubernetes, до тех пор, пока вы точно не понимаете, зачем он вам нужен. В огромном количестве сценариев вам хватит Ansible, Docker Compose и Terraform. С этим трудно поспорить, конечно же.
Последний докладчик — Марсианин — Филатов Максим. Максим, наверное, был самым сильным докладчиком (по крайне мере, он помогал отвечать на вопросы предыдущим двум коллегам).
Максим рассказывал об важной теме — что же делать, если вы всё-таки решили иметь Гетерогенную среду, в которой бок о бок будут жить приложения в Кубере и сервисы на голом Железе. В частности, рассматривался PostgreSQL, как самый культовый пример сервиса, который обычно живёт на виртуалках.
Есть проблема — если у вас не всё живёт в Кубере, то Service discovery из k8s наружу, ясно, работать не будет. Самое простое, что вы тут можете делать — это прибить Айпишники руками. Но, очевидно, ни о каком High availability тут говорить не приходится — ведь таким образом не будет реализован механиз Failover. Поэтому сервисы из Кубера нужно как-то дружить с сервисами вне Кубера.
В Kubernetes есть замечальная абстракция — Services. Важно, что вы можете использовать эти Сервисы и для приложений k8s.
Схема использования тут следующая. Вы создаёте в Кубернетосе Сервис, который получает доменное имя. Сервис имеет жоско определенный IP-адрес. Все остальные приложения взаимодействуют с сервисом через этот «домен».
Сервис принимает запросы от приложений из кубернетоса. Его Айпишник жоско задан, поэтому DNS-кэшерование нам не страшно. После того, как на сервис поступает запрос для доступа к PostgreSQL, сервис, используя iptables, перекидывает запрос на нужный инстанс Постгри. Если мастер PostgreSQL ляжет, достаточно будет только диагностировать это и поменять правило в iptables. Максим говорил, что это занимает буквально 1-2 секунды, и всё начинает работать, как и раньше.
В заключение, пара слов в общем про матип. Всё было очень круто. Отличная организация, прекрасное место проведения (спасибо Dell EMC за это). Единственный минус — это дикая жара, которая, к сожалению, накрыла нас в Спб.
Категории: Программирование