Kubernetes *

Я тут недавно пытался попасть на бесплатные курсы от Aston, но получил отказ с такой формулировкой.

Денис, добрый день! После изучения вашей анкеты, к сожалению, мы не готовы пригласить вас к дальнейшему рассмотрению на обучение в компании. У нас очень большой поток кандидатов на курсы. В данный момент взяли в рассмотрение участников с показателями выше. Ваша анкета будет сохранена, возможно, вернемся к вашей кандидатуре, при наборе на следующий поток. Благодарим за внимание к нашей компании.

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

Сегодня хочу попробовать пройти тестовое задание от клауд.ру. Оно охватывает тот самый стек для devops, linux, docker, git, kubernetes.

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

Тестовое задание состоит из 4 задач, начнем с первой.

Добавление физического сервера в кластер Kubernetes требует ручных действий: подключиться по SSH, установить пакеты, добавить параметры подключения и секреты, сконфигурировать kubelet, проверить, что узел появился в кластере, повторить для следующего сервера.

Привет, Хабр! Меня зовут Андрей Волков, я руководитель SRE в команде Managed Service for Kubernetes в Yandex Cloud и мы добавили возможность подключать BareMetal-серверы в кластер Kubernetes одной кнопкой.

Привет, Хабр! Наши sheet-ербьюторы не спят и продолжают развивать экосистему даже утром в субботу, когда сон для усталых взрослых людей. Теперь к делу!

Sheeternetes держит кластер контейнеров, у которого control plane — электронная таблица. Этот пост — про то, как заставить два таких кластера работать как один: on-prem-кластер поверх локального Excel-файла и облачный поверх Google-таблицы — по сети, с общей ёмкостью, живой миграцией и рантаймом, которому не нужен Docker. Всё воспроизводимо; код — один небольшой репозиторий.

Привет, Хабр! Значю, что вам на это плевать и вы не хотите это читать, но я все равно продолжу это писать:) В общем, Sheet-Native Computing Foundation продолжает цвести и пахнуть и у нас даже есть сторонние контрибьюторы. А чего добились вы?

Итак, вот что теперь можно сделать в таблице: запушить в неё настоящий OCI-образ контейнера и вытянуть его обратно. Не ссылку на образ, не метаданные о нём — сами слои, хранящиеся как base64 по ячейкам, с адресацией по sha256, собирающиеся байт-в-байт на выходе. У SheetHub — нашего форжа в стиле GitLab, который работает на Google-таблице — появился реестр контейнеров, и он целиком живёт в ячейках.

Этот пост — про то, как это всё устроено.

Привет, сегодня решила поделиться переводом от Маттео Бизи на вечнозеленую (как оказалось) тему — Shadow AI.

В материале про то, почему ИИ-агентов нужно моделировать как угрозу, а не просто как инструмент продуктивности.

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

Меня зовут Александр Прохоров. Я эксперт команды разработки Developer Productivity в VK Cloud. В статье расскажу, почему классическая инфраструктура тормозила развитие ИИ-проектов и какой подход к управлению вычислительными ресурсами стал ответом на эти вызовы.

Всем привет! Меня зовут Михаил Голубев, и я работаю в команде Kubernetes Security, MWS Cloud Platform. В этой статье я расскажу об одной попытке оптимизации: как мы залезли под капот CEL и Protobuf, чтобы научить интерпретатор читать данные из бинарного формата на лету без полной десериализации, и почему в итоге от этого кода пришлось отказаться.

Почему мы вообще этим озадачились: в одном из наших микросервисов реализовано сканирование приходящих событий по k8s-манифестам. Событий летит много, а обрабатывать их надо быстро, так что, чтобы минимизировать сетевой трафик и снизить нагрузку на инфраструктуру, в качестве основного формата передачи данных мы первоначально решили использовать Protobuf, он значительно компактнее JSON.

Далее эти данные проходят через различные валидации и проверки. Для описания и выполнения таких политик мы используем CEL — наподобие Kyverno или нативных k8s Validating (и Mutating) Admission Policies. Вот тут-то Protobuf и CEL встретились, и эта встреча оказалась не такой гладкой, как мы рассчитывали, — об этом подробнее ниже.

SRE‑инженер Mindbox Дима Рыбалка рассказывает, как команда за два месяца перенесла 40 кластеров ClickHouse в Yandex Cloud. Внутри — как выбирали стратегию миграции, связывали кластеры без VPN, переключали клиентов через cutover без даунтайма и с какими столкнулись проблемами после миграции. Материал будет полезен SRE‑, DevOps‑ и DBA‑инженерам, которые работают с ClickHouse в Kubernetes.

По прогнозу Gartner, к концу 2026 года task-specific AI-агенты будут встроены в 40% корпоративных приложений против менее чем 5% в 2025-м по оценке той же Gartner. Безопасность агента обычно сводят к guardrails, промпт-фильтрам и хорошо написанной системной инструкции. Однако в июле 2025-го случился инцидент —  агент Replit удалил прод-базу SaaStr, хотя его несколько раз просили ничего не менять. А в июле 2026-го на Хабре был опубликован разбор того, как имя, работодатель и город пользователя ушли наружу через Claude без единого клика с его стороны.

Об этих случаях известно только потому, что их публично разобрали — и спасибо тем, кто это делает. Но о скольких ещё случаях мы не знаем? CNCF за восемь июльских дней выпустил три материала подряд об изоляции агентов. Посмотрим, что они предлагают и как собрать из этого рабочий контур из трёх слоёв, с манифестами.

Объём неиспользуемых ресурсов не уменьшается (хотя вроде как должен), а узлы бесконечно ротируются. Это нормально для автоскейлера или пора что-то чинить?

В статье — детально о механизме консолидации в Karpenter, а главное — можно (и нужно) ли как-то его исправлять.

Всем привет! Решил поделиться с вами опытом написания и проведения ревью аудит‑политики Kubernetes.

Аудит‑политика Kubernetes — один из тех пунктов, который пишется один раз при настройке кластера, а потом годами живёт «как есть», обрастая исключениями для новых компонентов и почти никогда не пересматривается целиком. В какой‑то момент это уже не политика безопасности, а слой из комментариев трёхлетней давности.

Недавно я сел перечитать собственный конфиг на 500+ строк — собирал его из нескольких источников, в первую очередь опираясь на Kubernetes Threat Matrix. Хочу поделиться не столько конкретными находками (так как они специфичны для конкретного кластера), сколько принципами и типовыми ловушками, которые всплыли в процессе ревью. Если вы пишете или проводите ревью политики аудита для своего кластера — этот чек‑лист вполне сэкономит время.

Go показывает стабильную память, heap-профиль молчит, а Kubernetes всё равно убивает под по OOM. Разберём, откуда берётся это расхождение, как на поведение под лимитами влияют cgroup, GOMAXPROCS и GOMEMLIMIT и что изменилось в последних версиях Go.

Три часа ночи, воскресенье. «Пачка» уведомлений от системы мониторинга в почте и Telegram. Mission‑critical система «лежит», потому что истёк TLS‑сертификат, который упустили из вида и не включили в «эксельный» реестр.

Ситуация знакома? Тогда эта статья для вас. Разберём, почему вопросы управления цифровыми сертификатами резко обострились, какие классы решений есть на рынке, и почему «просто поставить cert‑manager» — это не всегда финал истории.

Последний месяц лета закрываем длинным списком релизов для AI-агентов: документация, MCP-сервер, скиллы, навыки, файлы в чате и четыре новые модели в каталоге. Причина простая: каждое третье обращение к нашей документации — от агентов, нужно считаться с новой аудиторией.

Вторая половина выпуска для тех, кто читает сам: три класса хранения в S3, отмена удаления баз, клон приложения в App Platform, домены через Госуслуги и обновленный Kubernetes.

Разворачиваем каждый пункт ниже ↓

Привет, Хабр! Была одна вещь, которая давно (примерно 3 дня) не давала мне покоя в Sheeternetes. Весь смысл проекта — «таблица и есть кластер»: Deployments, Nodes, Pods живут во вкладках, таблица — источник истины. Вот только в первых версиях мы покривили душой и шли против истины. Планировщик — та самая часть, что решает, какой под на какую ноду поедет, — был Python-функцией, которая читала таблицу снаружи. То есть таблица хранила состояние, а думал Python.

Это жульничество, и оно меня грызло (на самом деле нет, это клод так придумал). Поэтому я решил убрать последний внешний мозг: переписать планировщик как формулу таблицы. Без Python, без Apps Script, без bash. Одна =LET(…) на под, которая читает вкладку Nodes и решает, куда его поставить, — пользуясь только тем, что встроено в Google Sheets.

И оно работает. Воспроизводит bin-packing, capacity, spread, sticky placement, cordon, affinity и taints — и выдаёт ровно ту же раскладку, что и настоящий Python-планировщик, на всех девяти его юнит-тестах.

В Kubernetes-кластере рано или поздно встаёт вопрос: где собирать Docker image приложений? Вариант «на своей машине разработчика» не масштабируется на команду. Вынос сборок на отдельную виртуальную машину решает эту проблему, но создаёт накладные расходы на обслуживание инфраструктуры и лишает ключевых преимуществ k8s: отдельная ВМ не масштабируется горизонтально под нагрузку, параллельные джобы конкурируют за общие CPU, RAM и диск, а накапливающийся кэш требует регулярной очистки.

Kubernetes executor с Kaniko, BuildKit или Buildah лишён этих недостатков: сборка происходит в изолированных подах прямо на нодах кластера, ресурсы динамически масштабируются, а виртуальные машины для Docker-демона больше не требуются.

Большинство статей про Kubernetes на границе (edge) описывают более-менее стабильную топологию: несколько узлов в одном или нескольких дата-центрах, предсказуемая сеть между ними, редкие сетевые партиции как исключение, а не норма. У нас всё наоборот: control plane живёт в офисе/датацентре, а agent-узлы физически стоят в транспортных средствах автопарка — едут по городу, паркуются в подземных гаражах без связи, теряют VPN на десятки минут за смену. Разрыв связи с control plane — это не инцидент, это штатный режим работы системы, который нужно было спроектировать с самого начала, а не «подкрутить» постфактум.

В этой статье — то, как устроен наш K3s-кластер для автопарка: HA control plane на kube-vip, транспорт через WireGuard поверх MikroTik, разнородный флот из amd64- и ARM-агентов (включая Jetson), и отдельно — самая интересная часть: как мы подступаемся к вопросу «может ли под на границе продолжать работать, когда control plane временно недостижим».

Есть проверенный закон вселенной: если у чего-то есть экран и хоть немного памяти, рано или поздно на этом запустят 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-контейнере, играется в браузере с клавиатуры).

Сервис зависает, контейнер не отвечает, а в логах — только «обработанные» ошибки. Часто причина таких инцидентов скрывается в слишком широком except Exception, который мешает приложению корректно завершаться. Разберем, как правильно обрабатывать исключения в production‑воркерах и избежать подобных проблем.

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

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

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