Привет, Хабр! Под эгидой AOT мы проводим конференции для сообщества вокруг Kubernetes. На Kuber Conf от АОТ в 2025 году у нас выступал Алексей Костарев, Kubernetes-эксперт из «Базальт СПО». Для тех, кто любит смотреть видео — держите ссылку.
А ниже — текстовая версия доклада в изложении Алексея.
Меня зовут Алексей Костарев, в ИТ я с 1980-х годов. Начинал с перфокарт и ЕС ЭВМ, а в целом почти всю сознательную профессиональную жизнь — с UNIX и Linux. Давным-давно мы сделали несколько профильных систем под Linux, включая АС «Пенсия», которая проработала в Пермском крае более двадцати лет.
Сейчас же, с 2020-х, я занимаюсь Kubernetes-решениями и работаю в «Базальт СПО» (направление развития AltLinux в области виртуализации). За эти годы, кроме портирования PVE на нашу платформу, создания и поддержки своей линейки Kubernetes-образов, мы выпустили два продукта (podsec и Alt Orchestra), ориентированных на безопасное разворачивание Kubernetes-кластеров.
Под катом вас ждут:
технологии создания образов Kubernetes, которыми мы пользуемся;
небольшое сравнение решения Talos / ALT Orchestra с другими способами развёртывания Kubernetes;
разница между ALT Orchestra и Talos;
опыт портирования Talos в нашу среду;
история про очень интересный продукт Image Factory, который позволяет быстро создавать образы для дистрибутива и расширения к ним.
Как создаются K8s-решения на платформе ALT Linux
«Базальт СПО» — это, по сути, компания, которая занимается разработкой, поддержкой и продвижением решений ALT Linux Team — международной, в основном русскоговорящей, командой разработчиков свободного программного обеспечения. У нас есть своя платформа развития дистрибутива, а с 2004 года существует собственная база исходных кодов. На её основе создаются RPM-пакеты, которые помещаются на платформу Sisyphus — там отлаживаются все вновь вносимые продукты. После отладки пакеты попадают на стабильные платформы, начиная с платформы p2.2 (февраль 2003) и заканчивая текущей платформой p11. Кроме основных платформ (p10, p11) есть ещё и сертифицированные ФСТЭК — c10 (c10f) и планируется c11f.
На основе этих исходников мы строим бинарные RPM-пакеты. Чтобы развернуть Kubernetes, нам нужно собирать Docker-образы. Мы берём RPM-пакеты, связанные с Kubernetes, и те, которые разворачиваются в виде образов, собираем в образы.
Когда образы собраны, разворачивать их мы можем в трёх режимах.
Обычный, который в 90% случаев разворачивается, это так называемое rootful-решение.
В 2023 году мы разработали rootless-решение — когда при развёртывании Kubernetes контейнеры, работающие с правами root внутри, в рамках host-системы имеют права обычного системного пользователя.
ALT Orchestra, которое берёт своё начало от Talos. В этом режиме на узлах нет SSH-доступа, который является одной из точек проникновения в систему и нарушения безопасности.
Давайте о каждом варианте подробнее.
Rootful-режим
Почему он называется rootful? Потому что речь идёт о правах пользователя root, от имени которого работают контейнеры. Часть K8s-контейнеров вынуждена работать от пользователя root — например, разные init-контейнеры или те, которым необходим доступ к определённым ресурсам хоста.
И всё бы ничего, но есть нюанс. Root-пользователь, который работает в контейнере, имеет ровно те же права, что и пользователь root в хост-системе. А значит, запустив контейнер (в крайнем случае — примонтировав подкаталог контейнера к корню основной системы) можно при помощи старой доброй rm -rf снести с узла вообще всё. Права пользователя повышены, он может полностью нарушить работу системы, и это — проблема. Само собой, злоумышленник не обязательно будет поступать именно так жёстко — он может просто проникнуть в контейнер и, имея повышенные привилегии, наблюдать за работой системы.
В чём тоже мало приятного.
Rootless-режим (PodSec)
С учётом этого в марте 2023 года мы пошли дальше и решили представить решение, которое не позволяло бы такой режим работы. Мы нашли опенсорсный продукт, который как раз и позволял обеспечить такое развёртывание.
В такой схеме контейнерный root запускается от имени обычного пользователя (например, uid 453). С точки зрения хост-системы — это обычный пользователь. Даже если он нарушит изоляцию и сможет проникнуть в хост-систему, у него не будет рутовых прав, он будет таким же обычным, и причинит вреда сильно меньше, чем скомпрометированный рут.
Можно запускать в таком режиме не только пользовательские, но и основные контейнеры, которые обеспечивают работу Kubernetes: kubelet, scheduler, controller, etcd и так далее. Все сервисы controlplane разворачиваются от имени root внутри контейнеров, но в системе они имеют права обычного пользователя. В этом случае даже если злоумышленник нарушит изоляцию и проникнет в контейнер, он не будет иметь больших прав для воздействия на систему.
Мы назвали это решение PodSec (Podman Security), разработали мы его месяца за четыре — к июню 2023 года. Кстати, базовые решения, от которых мы отталкивались, пошли тем же путём, но дошли позже нас. Где-то к осени 2023 года они представили близкое решение, которое позволяет полноценно разворачивать Kubernetes.
На старте это было скорее «игрушечное» решение: его можно было разворачивать только в рамках одного сервера, внутри Docker. Такая себе чисто отладочная штука, совсем не для прода. Но за три месяца мы смогли сделать так, чтобы оно разворачивалось полноценно — на многих узлах с помощью стандартной команды kubeadm.
ALT Orchestra — специализированная ОС под Kubernetes
Тут интереснее — это операционная система, заточенная чисто под развёртывание Kubernetes.
Это не базовые основные дистрибутивы Linux общего назначения, где можно разворачивать серверы, LDAP, почту и прочее. Решение Talos / ALT Orchestra заточено именно под Kubernetes, поэтому в нём максимально настроены параметры ядра и обеспечена максимальная защищённость.
Что особенного
На узлах не запускаются SSH-демоны — удалённого доступа просто нет. Обычно для развёртывания Kubernetes-узлов поднимают серверы, которые позволяют обеспечить удалённый терминальный доступ. И в рамках этого доступа с помощью команды kubeadm на каждом узле разворачивается нужное решение.
Это выглядит удобным, но на самом деле это тоже очень серьёзная дыра в безопасности: проникнув через удалённый доступ на узел, мы окажемся там с теми же правами и в рамках самой хост-системы, значит, сможем серьёзно нарушить безопасность.
Так что тут никакого SSH. Развёртывание идёт с помощью единственной команды — talosctl (по аналогии с kubectl), она обеспечивает полное развёртывание Kubernetes-кластера на всех узлах.
Особенность вот в чём. На каждом узле кластера с помощью ISO или по PXE-протоколу поднимается начальное решение — так называемый maintenance-режим (режим поддержки). Дальше с помощью команд talosctl мы соединяемся с этим сервисом по API и даём команду загрузить нужный нам инсталлятор из сети.
Он загружается, инициализирует наш узел, затем узел перезагружается, создаёт нужные файловые системы, полностью формирует полноценный загрузочный образ на диске и ещё разок перезагружается.
И уже после этого начинается привычная загрузка Kubernetes с развёртыванием controlplane и worker-узлов. Повторюсь, развёртывание идёт не путём запуска команд удалённо через SSH, а с помощью команд talosctl.
И ещё кое-что. Основная файловая система загружается в оперативную память в режиме только для чтения. Даже если хакер захочет что-то почистить на уровне корневой файловой системы, у него банально не хватит прав для удаления и корректировки. Такой вот добавочный уровень защиты.
Сходства и отличия ALT Orchestra / Talos от систем общего назначения
Составные части нашего решения, как и решения Talos, распространяются под лицензиями Mozilla Public License и GPL-3. Но само решение, как и у многих создателей дистрибутивов в России, имеет отдельную лицензию, позволяющую разворачивать его физическим лицам бесплатно, а организациям и юридическим лицам — с покупкой лицензии. Это классика жанра
Вот главные отличия нашей ОС:
Как я и писал, нет доступа по SSH.
Значит, нет возможности взлома системы через этот канал.
Нет обычных для Linux пакетных менеджеров. У нас идёт развёртывание только нужного ядра, нужных образов, и ведётся своя линейка этих образов. Начиная с версии 1.10 мы просто поддерживаем эту версионность, предоставляя наши решения пользователям.
Есть очень удобные инструменты Image Factory, которые позволяют на его основе быстро создать нужное решение.
Богатый набор сетевых решений в рамках Kubernetes. Обычно начинается с простого Flannel, есть Cilium, Calico и так далее. Все эти сервисы решение поддерживает.
Поддерживается режим доступа через Virtual API.
Есть Discovery-сервис, который позволяет по ходу определять, какие узлы поднимаются, а какие — уходят из кластера.
В Talos и в ALT Orchestra файловая система очень жёстко ограничена и есть набор специальных разделов, где хранится нужная информация. Если обычно в Linux решение разворачивается так, что администратор сам вправе разбить файловую систему, выделить нужное место под корень, под home и прочее, то здесь всё жёстко ограничено именно под задачи защиты.
Чем ALT Orchestra отличается от Talos
Сразу скажу важное: у каждого дистрибутивостроителя есть своя технология разработки ядра системы. Мы были вынуждены подстраивать свою технологию под технологию Talos, нам надо было оптимизировать размер ядер, размер файловой системы, сделать hardening — настроить ядро так, чтобы оно работало в наиболее защищённом режиме под Kubernetes.
Отличие в том, что у нас создаются собственные Kubernetes-образы, которые мы используем для различного типа развёртывания. И docker registry, на которых эти образы хранятся.
В рамках Talos есть так называемые extensions. Скажем, если нам надо включить в ядро драйверы NVIDIA или ещё какие-нибудь (Btrfs, ZFS, на выбор), то из коробки Talos и ALT Orchestra идут в минимальной компоновке (ради минимального размера). Значит, мы при необходимости подключаем нужные нам extensions — расширения, которые позволяют, например, развернуть решение на серверах с NVIDIA, чтобы можно было использовать их для ИИ-задач.
Больше скажу — портируя extensions на нашу платформу, мы столкнулись с тем, что многие вещи в исходном коде были зашиты под производителя: адреса, имена образов и подобное. Поэтому мы вынуждены были модифицировать код — хорошо, что он открытый и под открытой же лицензией.
Мы не только модифицировали, но и поддерживали возможность параметризации — чтобы можно было исходное решение разворачивать в Talos так же, как оно исходно разворачивается, либо сразу с нашими параметрами. Все эти решения мы, кстати, передали в upstream, большую часть из них приняли. В этом плане честь ребятам из Sidero Labs, они нормально относятся к тому, что мы развиваем их систему, в том числе переносим её на свою платформу.
Кроме этого, мы очень серьёзно параметризовали Image Factory. Многие константы заменили на возможность указывать свои параметры, что позволило нам использовать собственные образы и более гибкие схемы развёртывания.
Процесс развёртывания
Само развёртывание в обеих системах — ALT Orchestra и Talos — совершенно одинаковое.
Мы создаём так называемые манифесты для развёртывания controlplane и worker-узлов. Есть два манифеста: controlplane.yaml и worker.yaml. Дальше для каждого узла с помощью talosctl мы обращаемся к этому узлу и просим его развернуть нужное нам решение — в controlplane или worker-режиме, с нужными extensions, то есть передаём нужные параметры.
Каждый узел начинает разворачиваться, все они автоматически объединяются в кластер. С помощью команды bootstrap демоны-etcd (которые обеспечивают общее хранилище параметров Kubernetes) синхронизируют свои данные и создают кластер. По окончании создаётся kubeconfig-файл, позволяющий обычным командам kubectl и другим работать с созданным кластером. Эта технология в Talos и в ALT Orchestra совершенно совпадает.
Процедура развёртывания каждого решения на узле более детально:
Создаются шесть разделов —
EFI,BOOT,META,STATE,EPHEMERALи другие.EPHEMERAL— это основная система, где, собственно, хранятся и запускаются контейнеры и происходит вся работа Kubernetes.BOOTхранит начальный загрузчик.Корневая файловая система загружается в оперативку в режиме только для чтения.
Образы, необходимые для Kubernetes, подтягиваются с наших registry. Есть два типа образов: первые — характерные для Talos / ALT Orchestra, которые обеспечивают развёртывание узла, вторые — образы для Kubernetes. Они находятся на двух разных registry и оттуда загружаются.
Все узлы начинают взаимодействовать между собой и создают нужную нам конфигурацию кластера.
Что нам пришлось выполнить при портировании
Ядро дистрибутива общего назначения очень большое, так что нам пришлось минимизировать его настолько, насколько возможно. Как, впрочем, и корневую файловую систему.
Основную команду talosctl, само собой, приходилось менять — константы, зашитые под оригинального производителя, меняли на свои константы под ALT Linux.
Мы переписали Discovery-сервис, поменяли лицензию с коммерческой на свободную. Конечно, мы были вынуждены создавать свои extensions в рамках этой системы. Все наши extensions собираются на основе нашей пакетной базы исходных кодов что облегчило регистрацию в Едином реестре российских программ и текущую сертификацию решения. Мы локализовали (перевели на русский язык) Image Factory — это наше решение попало в upstream — и сделали его более гибким. И мы используем свои Kubernetes-образы для развёртывания.
Что насчёт ядра
Максимально почистили всё, до чего только дотянулись и что сочли ненужным для Kubernetes при начальном развёртывании. Провели kernel hardening — максимально настроили параметры ядра по лучшим стандартам так, чтобы решение было максимально защищённым.
По поводу размеров: ядро общего назначения у нас было около 20 МБ, в Talos — 10 МБ, мы ужали до 11 МБ. Корневая файловая система была около 200 МБ, в Talos — 76 МБ, мы ужали до 90–150 МБ.
В принципе, этого достаточно, чтобы всё поместилось в нужные разделы.
Затем мы создали RPM-пакеты для основных команд: talosctl, installer, imager, Kubernetes-пакеты. Пришлось сделать очень много изменений в плане настройки под наши условия.
Создали Docker-образы для развёртывания ALT Orchestra двух типов.
production, которые попадают к пользователям;
development-образы, которые тестируются перед тем, как уйти в production: мы прогоняем все образы на корректность развёртывания.
Мы собираем собственные extensions: CRI, Btrfs, ZFS, драйверы NVIDIA и другие — чтобы можно было их использовать. Подняли свой Docker-registry для ALT Orchestra. И, собственно, пересобирали Kubernetes-образы.
Кстати, мы свято верили, что делаем стандартные образы, помещая бинарники в каталог
/bin. В нативных же Kubernetes-образах все бинарники находятся в /usr/local/bin — то есть не совсем правильное решение с точки зрения стандартов Linux (/usr/local/bin — это пользовательский каталог для бинарных команд). Пришлось это учесть. Причём до перехода на Talos мы этого не замечали, потому что всё и так работало отлично. А тут вдруг обнаружили, что кое-что сделали не так, как полагается по канонам «ванильного» Kubernetes.
Discovery-сервис
Исходное решение Talos было коммерческим. Чтобы его использовать, его надо было у провайдера купить.
Мы, используя спецификации и даже не анализируя код, переписали этот код с Go на Rust — чтобы уж точно к нам не могли придраться в плане «Да вы взяли и скопировали чужой код», так что мы выбрали другой язык, на котором и создали собственный продукт, который предлагаем пользователям. Лицензия под него — GPL. Это чистый опенсорс: его можно использовать и вносить изменения.
Extensions
В Talos extensions собирали «с миру по нитке». Скажем, CRI брали с GitHub копированием бинарного кода. Другие расширения тоже брали с GitHub, компилируя на Go. Третьи — вообще из пакетов и совершенно «левых» источников.
То есть при сборке каждого extension получалась сборная солянка. Похоже, ребята действительно имели базовое решение и по-быстрому вытаскивали то, что нужно, и помещали к себе. Это, конечно, позволяет быстро всё развернуть, но проблема в том, что при сертификации такое решение точно не примут: оно натаскано из совершенно разных источников, и нет вообще никакой гарантии, что там нет уязвимостей.
У нас все extensions разворачиваются и собираются чисто из нашей пакетной базы. Любой extension, как правило, все бинарники и исходники сертифицируются в рамках платформ c10, c11. Поэтому, взяв сертифицированное решение, мы автоматически получаем сертифицированные же расширения. Нет нужды решать большие проблемы при сертификации extensions. А в Talos это очень сложная задача на практике — взять и привести всё в порядок и обеспечить сертификат на каждый продукт. Тем более, что большинство extensions собираются из исходных кодов, хранящихся на зарубежных серверах, и где-то даже используются сторонние бинарники.
Image Factory
Мы создали собственный веб-сайт для поддержки сборки образов на базе ALT Linux, назвали его Image Factory.
Наши доработки исходного кода Image Factory приняты в upstream, и это уже часть нашего вклада в развитие Talos. Когда мы разворачивали собственный Factory, мы его ещё и локализовали, добавили всевозможные «рюшечки» — логотипы и так далее, чтобы наше решение было с нужными логотипами, более близкими для пользователей. Цвета поменяли на фирменные. Сам интерфейс мы особо не меняли, потому что он считается своего рода стандартом.
Возможности
Во-первых, сначала мы выбираем тип развёртывания: физический сервер (bare metal), виртуальная машина, облачный сервер (Azure, AWS, GCP и прочее). В текущей политической ситуации зарубежные серверы уже не так популярны, но есть решения на Yandex Cloud, которые тоже можно разворачивать. Ещё один вариант, который был у Talos, — одноплатные компьютеры со специфическим оборудованием. Мы в эту сторону пока не смотрим, потому что спрос на эти аппаратные платформы и оборудование в России пока мал.
Затем на следующей странице сайта мы выбираем версию ALT Orchestra / Talos, нужную для развёртывания. Эти решения для разных платформ (Sisyphus, p10, p11) разные — для каждой мы собираем отдельный образ. В рамках каждой платформы опять-таки имеем линейку версий ALT Orchestra / Talos. Пользователь может выбрать нужную ему версию и архитектуру (мы поддерживаем две, amd64 и arm64).
После этого пользователь определяет, какой список расширений он собирается включить в состав своего решения. Здесь приведены основные расширения, включая файловые системы Btrfs, ZFS, NVIDIA-драйверы и так далее. Есть набор из десятка-двух этих расширений, которые пользователь может установить при развёртывании.
Далее идёт страница кастомизации, когда создаются параметры ядра — указываются всевозможные тонкости для старта своего варианта ядра. На основе всех этих параметров система формирует уникальный идентификатор для решения пользователя, который дальше можно использовать, чтобы загрузить решение по этому ID. Если пользователь ничего не задал (а многие именно так и поступают), формируется специальный идентификатор (UUID около 80 байт) — это стандартный моментальный идентификатор.
Под конец Image Factory формирует странички со ссылками. Есть ссылка на ISO-образ того решения, которое пользователь предварительно выбрал, на дисковые образы, на PXE-загрузчики.
Причём система пока не строит ни ISO, ни дисковые образы — она просто указывает ссылки, нажав на которые можно собрать нужный артефакт. При первом запросе система проверяет, есть ли у неё в кэше данный артефакт. Если его нет — строит, помещает в кэш и отдаёт пользователю. Если пользователь повторно (или другой пользователь) выбрал то же самое решение и запросил его у Image Factory, система, увидев артефакт в кэше, сразу отдаст его, не пересобирая заново. Это довольно удобный механизм, который позволяет заметно оптимизировать работу: комбинаций из 20 extensions могут быть миллионы, все их заранее не построишь.
Пользователь может получить и другие артефакты — например, чистый образ ядра, образ rootfs. Схема та же самая: запрашивает по ссылке, если артефакт есть в кэше — отдаётся, если нет — строится и отдаётся клиенту.
Что мы поменяли в Image Factory
Локализовали, перевели на русский язык.
Сделали универсализацию: добавили параметры организации, для которой надо развернуть, указали параметрами, какие образы нужно загружать — не стандартные Sidero Labs, а свои.
По умолчанию загружается всё, что зашито в Sidero Labs, но мы добавили возможность динамического указания своих собственных образов для развёртывания решения. Эти два решения были приняты в upstream без проблем.
Часть наших правок по параметризации upstream не принял. Хотя, вроде, если уж начали делать решение универсальным, логично было бы довести до конца. Дело, конечно, их — у нас это решение есть.
Кастомизировали веб-интерфейс, добавили свой логотип, стили оформления и прочее — это уже чисто наше, upstream принимать не обязан. В исходных кодах все константы были гвоздями приколочены. Мы заменили константы на переменные и дали возможность через параметры менять эти значения.
Это позволило нам при создании нашего решения ALT Orchestra создать две платформы. Первая — development, в рамках которой у нас работает внутренний Factory и кэш. Мы, команда разработчиков, разрабатываем в его рамках свои решения и тестируем их. После того как решение протестировано, с помощью одной команды оно попадает из нашего внутреннего Factory на внешний Factory. И дальше пользователи уже начинают пользоваться той версией ALT Orchestra, которую мы разработали. Получилось довольно гибкое решение.
Sidero Labs как производитель Talos не афишируют, как именно они это делают у себя, но, судя по всему, идут в том же направлении: команда переноса из одного Factory в другой в последней версии Talos у них появилась.
Я так понял, мы с ними идём в плане универсализации решения параллельно. Наша разработка универсализации позволяет развернуть Image Factory не только у нас, но и, например, у клиента. Есть смысл создавать необходимые артефакты локально у клиента (а они бывают по несколько гигабайтов). Сейчас очень многие Kubernetes-кластера в целях защиты решения не имеют доступа в интернет, и это решение позволяет разворачивать то, что необходимо, именно локально. Пользователи могут спокойно разворачивать закрытые кластеры по общей технологии, которую использует Talos.
Что будем делать дальше
Мы сейчас движемся в направлении Cozystack, «уютного» стека. Он в основном ориентирован на развёртывание в рамках Talos — и на основе ALT Orchestra, потому что на уровне развёртывания K8s-системы они идентичны. Но он позволяет строить более мощные решения. Там есть система виртуализации KubeVirt, с помощью которой в рамках Kubernetes можно разворачивать виртуальные машины. Есть своя сетевая подсистема, система хранения данных, система мониторинга.
Производитель Cozystack позволяет на основе этого делать разные поставки.
Первая — full-платформа: поддерживает управление Kubernetes, управление приложениями, управление виртуальными машинами, отдельный user interface для Cozystack, API Cozystack. Это решение мы сейчас потихоньку поднимаем у себя.
IaaS-full (ещё развивается, до конца не готово).
Есть host-решение, которое позволяет разворачивать Cozystack не на решении Talos / ALT Orchestra, функционала там намного меньше.
Решение distro-full — чуть меньший объём поставляемых пакетов, но довольно мощное в плане развёртывания Kubernetes.
И distro-host.
В плане управления кластером в рамках Talos есть решение Omni — оно закрытое и его довольно сложно купить, чтобы обеспечить высокоуровневый пользовательский интерфейс для работы с Talos. Мы сейчас создаём собственный интерфейс для работы с нашим решением ALT Orchestra (и, собственно, с Talos). Назвали его Maestro.
Maestro разрабатывается в рамках решения Headlamp (стандартный пользовательский интерфейс для работы с Kubernetes). Это позволяет в рамках единого интерфейса, поработав в Maestro с Talos, переключиться на Headlamp и посмотреть все параметры нашего развёрнутого решения уже в Headlamp: DaemonSet’ы, ReplicaSet’ы, конкретные поды, сколько они занимают, Storage и так далее. Получается, что в одном флаконе будет инструмент UI для работы как с Kubernetes в целом, так и с нашим решением ALT Orchestra.
Это пользовательский интерфейс над командой talosctl — в ней 50 команд и около 300 подкоманд. Запомнить администратору это просто нереально, работать с этим очень сложно. Так что мы решили сделать жизнь немного проще и создаём собственный пользовательский интерфейс, который позволяет довольно быстро получать нужные параметры для работы как с кластерами, которые мы создаём, так и с узлами этого кластера. Можно создавать собственные кластеры, просматривать их, модифицировать, удаляя какие-то ноды из одного кластера и перенося в другой. В общем, делаем полноценный пользовательский интерфейс работы с кластером.
Так как ALT Orchestra и Talos не поддерживают удалённый доступ по SSH, то администратор не может просто зайти и посмотреть, сколько у него памяти сейчас занято и чем именно, как дела с процессами и прочее. А вот этот интерфейс позволяет наглядно оценить параметры работы каждого узла — какие сервисы запущены, и по каждому сервису логи, чтобы понять, какие проблемы могут возникнуть в работе системы.
Maestro — довольно свежий продукт, ещё и года нет: идея возникла в конце декабря 2025 года. И с 6 января, после праздников, за месяц мы набросали основные интерфейсы, которые будем дальше развивать и предлагать клиентам.
Вместо итогов
Решение ALT Orchestra, кстати, мы сейчас сертифицируем и сможем предлагать уже серьёзным клиентам. В решении заинтересованы и банки — например, Центробанк и Ассоциация Финтех (АФТ) протестировали наше решение ALT Orchestra и выдали положительные рекомендации.
Если вам интересен путь проекта, буду и дальше вам про него рассказывать. А если есть вопросы — не стесняйтесь задавать их в комментариях.
Совсем немного времени осталось до новой конференции Kuber Conf от АОТ — она пройдёт 23 ноября.
Главная тема — инженерные задачи без привязки к конкретным облакам: практика эксплуатации Kubernetes, разбор инцидентов и обмен опытом.
Будем говорить о построении инфраструктуры вокруг K8s и о способах удержания падающего SLO. Программа и регистрация — по ссылке.
Алексей Костарев выступит на конференции со своим новым докладом — «ALT Orchestra и её Maestro».
Комментарии 0