Есть проверенный закон вселенной: если у чего-то есть экран и хоть немного памяти, рано или поздно на этом запустят DOOM. Запускали на осциллографах, на тесте на беременность, на кофемашине и на тракторе. Мы в Sheet-Native Computing Foundation тоже решили побыть в этом уже достаточно запылившемся тренде и запустить DOOM в контейнере, упакованном в ячейки электронной таблицы. То есть образ контейнера с игрой физически лежит в ячейках, оттуда собирается обратно в Docker-образ, проверяется по sha256 и запускается.

В первой статье я рассказывал про Sheeternetes — оркестратор контейнеров, у которого весь control plane (Deployments, Nodes, Pods, Events) живёт внутри Google Таблицы или Excel, а на другом конце крутятся настоящие Docker-контейнеры. Там же мельком был упомянут наш формат образов — SICF (Sheet-Native Image Container Format). Эта статья как раз про него: как он устроен, как всё это воспроизвести у себя, как оно работает на bare metal (то есть в эксельке, а не гугл-таблице) без интернета и какие неожиданно интересные находки вылезли, когда мы начали пихать всё это дело в ячейки Google Sheets.

Спойлер: DOOM — настоящий (Chocolate Doom плюс свободный Freedoom, всё в Linux-контейнере, играется в браузере с клавиатуры).

В одном чате по куберу меня спросили единственное, что реально важно, когда ты собрал оркестратор контейнеров внутри таблицы: а сколько оно вообще тянет? Сколько подов, пока не ляжет. Какой образ влезает в ячейки. Сколько кластеров держит одна машина. И — раз уж мы фонд с серьёзным лицом — как это смотрится рядом с настоящими: Kubernetes, Docker Swarm, Nomad.

Поэтому мы провели честное нагрузочное тестирование. Четыре измерения, два бэкенда (.xlsx на диске и живая Google-таблица), синтетика на ноутбуке и реальные Docker-образы на облачной виртуалке. А потом поставили цифры рядом со взрослыми оркестраторами.

Короткая версия: по каждой оси, которая имеет значение, мы проигрываем на 3–5 порядков. По осям, которые значения не имеют, — выигрываем вчистую. И один наш давний «факт» оказался неверным — бенчмарк нас поправил. Поехали.

Недавно я рассказывал про Sheeternetes — оркестратор, у которого control plane живёт в таблицах. Здесь — про следующий логичный шаг: паттерн «оператор», применённый к самим таблицам. Настоящий полноценный Sheeternetes-оператор. Не скрипт внутри таблицы, а внешний контроллер, который приводит табличку к желаемому состоянию.

И раз уж так совпало по датам, демка этого оператора будет переворачивать календарь и возвращать таблице все атрибуты настоящего третьего сентября, дня прощаний.

Хабр, привет! Есть такой тип проектов, которые начинаются со слов «а что если» и заканчиваются тем, что ты в три часа ночи объясняешь kubelet-у, что таблица — это его новый control plane. Так вышло и тут, всё родилось из субботней шутки в одном телеграм-канале по кубернетесу.

Правила игры простые: раз весь мир можно создать в эксельке, то пускай всё состояние кластера живёт внутри электронной таблицы. Не «метаданные в таблице», не «экспорт в CSV» — а буквально: Deployments, Nodes, Pods, Events — это вкладки Google Sheets (или листы Excel). Планировщик читает и пишет ячейки. kubectl-подобная утилита ходит в таблицу. И — вот это ключевое — на другом конце крутятся настоящие Docker-контейнеры. Таблица не симулирует кластер. Таблица и есть кластер.

Проект называется Sheeternetes. Это, конечно, шутка. Но шутка, которая компилируется, проходит тесты и переживает падение ноды.

Ниже — как это устроено, как это поднять у себя за пять минут, как оно работает на bare metal без интернета (в Excel и LibreOffice), как связать несколько таблиц-кластеров в федерацию с живой миграцией, почему контейнеры можно хранить прямо в ячейках, — и что это внезапно выросло в целый фонд с 30 проектами, стандартом контейнеров и системой сертификации.

Вышел Cozystack v1.6.0. Релиз опубликован 22 июля 2026 года и включает все исправления, ранее вышедшие в патч-релизах v1.5.1–v1.5.3. Ниже — перевод официального анонса, дополненный главными исправлениями из патч-релиза v1.6.1 от 5 августа.

В этом выпуске изменилось несколько важных частей платформы. Рабочие узлы тенантных кластеров Kubernetes теперь работают на Talos Linux вместо Ubuntu, тенанты могут включать аутентификацию OIDC для Kubernetes и Grafana, а новый API SecurityGroup даёт более безопасный интерфейс для управления сетевыми политиками приложений.

В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox). Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator.cozystack.io/v1alpha2. Эта версия пришла на смену etcd.aenix.io/v1alpha1. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера. Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2.0.

I ran into a very practical problem after doing a lot of local work with AI agents. I had Codex projects, Claude Code projects, regular repositories edited with agents, drafts, pipelines, instructions, skills, artifacts, and several machines. At some point it became hard to tell where the current version of a project lived, which files were safe to push, where agent instructions belonged, and where source code had already been mixed with logs and intermediate output.

That is why I built AI Workspace System: a small set of shell scripts, conventions, and Markdown documentation that makes local AI-agent work predictable. It is not an IDE and not an agent orchestrator. It is a thin infrastructure layer around Git, GitHub, Codex, and Claude Code.

The core idea is simple: all projects should be visible from one list, instructions should follow one structure, sync should be safe by default, and machine-specific details should not live in the repository.

У меня MacBook Air M4, ПК под Ubuntu 24.04, консальные Claude Code и Codex (каждый хорош немного под свои задачи, как по мне). Я люблю Ubuntu, но вот в поездках Mac прям незаменим — с ним удобно работать, батарея живет достаточно долго, даже в самолете можно комфортно что-то тыкать тачпадом. При этом яблочную экосистему я не люблю, Ubuntu мне ближе и приятнее в использовании. Важный момент: я не программист, так что большая часть моих проектов — это всякая маркетинговая, менеджерская и редакторская штукенция. Поэтому у меня нет под это всё каких-то IDE и т.п. Конечно, разработчики и другие инженеры обычно работают с кодом, а потому просто коммият всё напрямую в гитхаб.

Но к делу. У меня постоянно запущено по 6-10 окон Claude и Codex в терминале и я заколебался проекты синхронизировать через Избранное телеграма — зипами. Плюс хочется, чтобы проекты нормально работали и в той, и в другой нейронке. То есть мне понадобилась какая-то система синхнонизации проектов между разными устройствами и разными нейронками.

Сегодня наконец собрался с силами и доделал такую — выложил ее под Apache 2.0 на гитхабе, можно пользоваться, форкать, дорабатывать и выражать своё «фи» в ишшьюсах и комментариях. Наверянка уже кто-то что-то такое себе делал и я просто изобретаю велосипед. Но что ж теперь поделать, я его уже переизобрел.

В статье расскажу, как делал, что делал, где и что пришлось дотюнивать. Скажу честно, мне эту часть с инструкцией писать было лень и она написана уже GPT, так что простите. Немного пробегусь по стилистике, конечно, но в целом текст править почти не буду.

Всем привет. Мы в Ænix давно занимаемся Kubernetes-платформами, bare metal-инфраструктурой и Cozystack, поэтому тема блочного хранилища для Kubernetes у нас не теоретическая. Это та часть стека, где красивых абстракций быстро становится мало: надо переживать падения нод, понимать топологию, реплицировать данные, не ломать PVC, дружить с CSI и при этом оставаться предсказуемыми для операторов.

Сегодня хотим показать первый публичный результат этой работы — Blockstor 0.1.0.

Blockstor — это открытая система управления распределенным блочным хранилищем для Kubernetes. Она использует DRBD для репликации данных, совместима с REST API LINSTOR и написана на Go как самостоятельная clean-room реализация. Код распространяется под Apache 2.0.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

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

Да, здесь уже не первый год орудуют самые продвинутые из контент-маркетологов. Однако теперь сюда явно доберется и основная их масса. Конечно, есть некий барьер в виде необходимости получить инвайт на Хабр, чтобы писать статьи, но он, насколько я понимаю, достаточно легко обходится за деньги с помощью серых схем с уже набравшими рейтинг дельцами от контент-маркетинга.

Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

На мой взгляд, такое понимание Kubernetes заводит рынок в тупик. Очевидно, что сложность оркестратора должна расти, очевидно, что будет все больше сфер, в которых он будет использоваться и которые способны извлечь немало пользы из внедрения K8s. Если рынок не начнет смотреть на Kubernetes как на Linux Kernel, это заведет нас в тупик, и вот почему...

Четыре года мы развивали и улучшали werf 1.2, но теперь наконец‑то выпустили стабильную werf 2.0. Причина простая — последовательно накопилось множество улучшений (300+ релизов!), а кроме того, мы доработали новый движок развёртывания Nelm, и в werf 2.0 это единственный движок. Старый движок удалён. Nelm обратно совместим с Helm 3, поэтому никаких особых изменений в чартах не потребуется — они будут развёртываться так же, как и раньше.

В некоторых случаях у Nelm отличается поведение: например, у него более строгая валидация чартов, поэтому, хотя Nelm и доступен в werf 1.2, по умолчанию мы его включили только в werf 2.0.

Рассказываем, зачем мы сделали Nelm, что под капотом werf 2.0, как werf будет развиваться в будущем и как ее попробовать на своем проекте уже сейчас.

3 апреля на сайте InfoWorld вышла статья известного публициста на тему Open Source и юриста Matt Asay под названием «OpenTofu, возможно, демонстрирует нам, как не надо делать форк». Лидер-абзац в статье довольно жёсткий: 

Не согласны с лицензией? Просто сделайте форк проекта, но не выкидывайте его код — говорите, что он всегда был доступен публично. Сравните код и лицензию HashiCorp с версией OpenTofu.

Разберемся в этой истории последовательно — кто прав, кто виноват и чем всё закончилось.

Как и все, я что-то читаю, что-то смотрю, что-то слушаю и т.п. И в результате этого всего возникают всякие мысли — пытаюсь анализировать и думать, что произойдет в ближайшие лет 10 в следствие развития технологий и науки. Хочется думать, что мысли эти практичны и могут позволить подготовиться к будущему с точки зрения карьеры или развития какого-то бизнеса. Хотя из всего вышеописанного я только один пункт пытаюсь реализовать — и то с очень медленно и лениво:) В общем, это просто фантазии, но давно хотелось ими где-то поделиться:)

Вообще, было бы интересно услышать максимально много мнений читателей на эту же тему и вместе попытаться составить какую-то максимально практичную, позволяющую принимать решения прямо сейчас картину будущего. Что-то из этого наверняка уже реализуется, а что-то уже могло и реализоваться — но пока, судя по всему, не в полной мере (поправьте. если ошибаюсь).

Мы во «Фланте» любим Open Source — причем не только пишем свои открытые инструменты (werf, shell-operator, grafana-statusmap, сommunity-версия Deckhouse), но и активно участвуем в разработке различных проектов — участвуем в KEP’ах Kubernetes, в составе небольшой группы разрабатываем Dex, вносим вклад в Istio, передаем патчи и сведения о найденных багах в Cilium.

Поэтому мы решили написать несколько материалов о том, какие возможности для контрибьюторов предлагают известные в мире Open Source- и Free Software-организации. В этом материале мы рассмотрим Linux Foundation, его дочку — CNCF и европейское отделение Free Software Foundation. Сразу отметим, что участвовать в Open Source-проектах можно, даже не будучи программистом, — есть немало задач, связанных с продвижением, контентом, переводами, менеджментом. 

В этой статье мы рассмотрим, почему API-шлюзы стали ключевым элементом экосистемы современных облачных вычислений и как появление Kubernetes API Gateway упростило и стандартизировало работу с ними. 

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

На днях мы работали над переводом глоссария CNCF и начали спорить о том, как писать словосочетание cloud-native. Раньше мы использовали название с дефисом — такое правило применяется к составным прилагательным в английском языке (пример — well-known actor). «Википедия» в статье «Cloud-native computing» тоже следует этому правилу, с другой стороны, название CNCF расшифровывается уже без дефиса: Cloud Native Computing Foundation. Так что нам пришлось провести небольшое расследование.

Месяц назад компания «Экспресс 42» вместе с партнерами (одним из которых как раз был «Флант») выпустила подробный отчет на 75 страницах о состоянии DevOps в России. В этой статье мы бы хотели более подробно рассказать, какие инструменты и операционные системы компании используют для работы с инфраструктурой, как меняется их проникновение от года к году, как продвигается импортозамещение и что именно российские компании понимают под этим термином.

В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и постепенно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.

В этой статье мы хотели порефлексировать о переходе от сервисной компании к созданию собственных продуктам, рассказать, как эти продукты развивались и что с нами произошло за последние 5 лет.

Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.