Привет! Я Андрей Квапил (или kvaps) и в этой статье я опишу наш путь организации доставки приложений в Kubernetes, объясню недостатки классического GitOps в локальной разработке и покажу, как новая утилита cozypkg решает эти проблемы. Материал рассчитан на разработчиков, знакомых с Helm и Flux.

У нас есть общий репозиторий — в нем мы описываем общую конфигурацию всех компонентов, а также темплейты для их деплоя. Для того чтобы максимально упростить процесс поддержки каждого из компонентов, мы следуем определенному процессу.В основе этого процесса лежит идея о том, что каждый компонент — это Helm-чарт.

Привет! Меня зовут Андрей Квапил (или kvaps). Я CEO в Ænix, и мы делаем Open Source-платформу и фреймворк Cozystack, с которым очень удобно строить облака.

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

Обычно Talos Linux предоставляется в виде набора готовых образов под различные системы. 

Стандартный метод установки предполагает, что вы возьмёте подготовленный образ под конкретное облако или гипервизор и просто создадите из него виртуальную машину. Если же говорить о физических серверах, то предполагается, что для загрузки образа Talos Linux и последующей установки вы будете использовать ISO или PXE.

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

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

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

В этой статье мы разберем, что такое API aggregation layer, для решения каких задач его стоит использовать, когда его использовать не стоит и как мы использовали эту модель для реализации собственного extension API server в платформе Cozystack. 

Недавно мне довелось обновлять старую FreeIPA в большой компании. Эта FreeIPA была установлена в LXC-контейнере на CentOS 7 и находилась в нерабочем состоянии уже несколько месяцев. Мне передали бэкап LXC-контейнера для Proxmox, и я взялся за дело.

Вот мы и подобрались к самому интересному: запуску Kubernetes в Kubernetes. В этой статье мы поговорим о таких технологиях, как Kamaji и Cluster API, а также о том, как интегрировать их с KubeVirt.

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

И начнём мы, пожалуй с Cluster API.

Продолжаем серию постов про то как построить своё собственное облако в экосистеме Kubernetes. В прошлой статье мы разобрали как можно подготовить базовый дистрибутив Kubernetes на базе Talos Linux и Flux CD. Теперь нам предстоит обсудить возможность запуска виртуальных машин и всего что для этого необходимо, а это в первую очередь хранилище и сеть.

Мы поговорим про такие технологии как KubeVirt, LINSTOR и Kube-OVN

Для начала мне стоит рассказать зачем вообще нужны виртуальные машины, почему бы нам не ограничиться только-лишь контейнерами?

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

За последнее время я вижу всё больше споров на тему двух популярных GitOps инструментов: Argo CD и Flux CD.

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

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

Мы очень любим Kubernetes и мечтаем чтобы все современные технологии поскорее начали использовать его замечательные паттерны.

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

Да, вы могли бы возразить что Kubernetes для этого не предназначен и почему бы не использовать OpenStack для Bare Metal-серверов а внутри него запускать Kubernetes как положено. Но поступив так, вы просто переложите ответственность с ваших рук на руки OpenStack администраторов. Что добавит как-минимум ещё одну сложную и неповоротливую систему в вашу экосистему.

Зачем так всё усложнять? - ведь на данный момент Kubernetes уже имеет всё необходимое для запуска Kubernetes кластеров.

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

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

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

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

Несколько месяцев назад у нас появилась необходимость разработать CSI-драйвер для Kubernetes, который в первую очередь использовался бы для хранения дисков виртуальных машин в Deckhouse Virtualization, но также мог бы использоваться и со стандартными контейнерами в Kubernetes. У оборудования наших заказчиков, как правило, есть определенная специфика — чаще всего это классическая SAN (Storage Area Network) с внешним хранилищем и общим shared LUN, который выделяется на несколько узлов. На одном LUN одновременно работает несколько виртуальных машин или контейнеров.

Помимо всего прочего, от драйвера нам требовалась поддержка различных CoW-фичей, таких как снапшоты, thin provisioning и возможность выполнять live-миграцию виртуальных машин в Kubernetes. Из существующих решений можно было бы отметить некоторые свободные проекты, однако ни один из них не реализует все желаемые фичи. Кроме того, у них есть явные проблемы с масштабированием.

Виртуализация оборудования — одна из важнейших и фундаментальных технологий в области облачных вычислений. Без нее не смогло бы работать ни одно «устройство» внутри виртуальных машин: ни сетевая карта, ни диск, ни клавиатура, ни мышь и т. п. В статье мы проследим развитие технологий виртуализации оборудования в Linux.

Всем, привет! Я Андрей Квапил, работаю во «Фланте» над Kubernetes-платформой Deckhouse. Это статья по мотивам моего доклада о разработке нашей системы виртуализации на основе KubeVirt. Я расскажу, какие альтернативы KubeVirt мы рассматривали, чем они нас не устроили, как устроен KubeVirt, как он работает с файловыми хранилищами, сетью и о том, как происходит запуск виртуальных машин внутри Kubernetes. А еще — какие изменения мы внесли в KubeVirt, чтобы он полностью соответствовал нашим задачам. Будет сложно, но интересно. 

Кстати, в начале 2023 года мы уже рассказывали на Хабре о Deckhouse Virtualization — нашей системе виртуализации нового поколения. 

Глубокое понимание внутреннего устройства DRBD позволяет более тонко настраивать работу системы и правильно планировать ресурсы. К счастью, у команды DRBD уже есть отличная документация, которая довольно подробно разбирает эту тему. Мы опирались на нее в своей работе, и решили перевести и выложить в открытом доступе 17-ю главу — как удобную шпаргалку по внутреннему устройству DRBD. Так что это не обычная статья, а перевод части официальной документации (исходная нумерация разделов сохранена).

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

Привет, Хабр! Сегодня у меня для вас отличные новости. В последние несколько лет мы во «Фланте» внимательно следили за технологиями‑лидерами в cloud‑native. Но это вовсе не праздное любопытство: из них мы собрали кое‑что интересное и теперь готовы представить его вам. Речь о новой системе виртуализации, которая появилась в сегодняшнем релизе Deckhouse v1.43.

На самом деле почти никто не знает, что такое GitOps. Я тоже заблуждался, пока не начал готовить доклад, а потом статью по этой теме. Самое распространенное определение GitOps — это «хранение состояния в Git», но оно не единственное и не самое главное. Это звучное словечко  придумали в Weaveworks, но его название несколько разнится с его реальным пониманием. Созвучие с DevOps — скорее, маркетинговый ход, чем реальное отражение сущности. Основная идея GitOps в том, что помимо хранения состояния в Git, у нас есть непрерывный процесс его синхронизации с реальным миром, то есть, что у вас Kubernetes-кластере или где либо ещё в вашем окружении.

Меня зовут Андрей Квапил. Я работал в чешском хостинге WEDOS. Он не сильно популярен в России, но это крупнейший хостинг на территории Чехии (просто Чехия маленькая).  Сейчас я работаю во Фланте, но именно на примере европейского хостинга WEDOS, хочу рассказать историю имплементации GitOps.

В июне я выступил на объединенной конференции DevOpsConf & TechLead Conf 2022. Доклад был посвящен LINSTOR — Open Source-хранилищу от компании LINBIT (разработчики DRBD). Основной идеей выступления было показать [на примере Kubernetes], как работает и устроен LINSTOR, какие проблемы решает, как его правильно настроить и использовать. Эта статья — основная выжимка из доклада (его полное видео см. в конце).

С появлением snapshot-controller в Kubernetes появилась возможность создавать снапшоты для совместимых с ними CSI-драйверов и облачных провайдеров.

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

Кажется это уже стало традицией: каждый раз, когда я выхожу на новое рабочее место, моя деятельность начинается с бенчмарков различных SDS-решений. Мой приход во «Флант» не стал исключением. Я попал в команду разработки Kubernetes-платформы Deckhouse, где решили развивать возможность запуска виртуальных машин в Kubernetes. Но для этого сначала потребовалось найти простое и надежное хранилище блочного типа, которое можно предложить клиентам платформы.

Я взял несколько свободных решений и протестировал, как они поведут себя в тех или иных условиях. В первую очередь интересовала производительность DRBD в различных конфигурациях и сравнение с Ceph.

Но рынок программно-определяемых хранилищ не стоит на месте и постоянно растёт. Появляются новые амбициозные проекты, включая недавно релизнутый Mayastor и pet-проект моего товарища-соратника Vitastor. Результаты оказались очень интересными.