Karmada признали зрелым проектом CNCF

Cloud Native Computing Foundation (CNCF) присвоила Karmada статус graduated, признав проект зрелым. Karmada распределяет приложения между кластерами Kubernetes, облаками и регионами без их изменения. Проект централизованно размещает их, переключает при отказе и масштабирует между кластерами.

В Karmada v1.19 улучшили планирование составных задач распределённого обучения ИИ. Планирование по приоритетам перешло в бету и включено по умолчанию, чтобы критичные нагрузки планировались первыми.

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

Часть систем CERN готовят к переходу с CentOS Linux на Debian

Если у вас парк CentOS Linux, опыт CERN полезен как ориентир для оценки собственной миграции. CERN готовит переход только части систем: речь не идёт о переносе всей вычислительной среды организации.

Сотрудники CERN представили переход в докладе «Controlling CERN's Accelerators with Debian» 30 августа 2026 года. В целом ускорительный комплекс получает данные с датчиков и сохраняет петабайты для анализа, но конкретные версии пакетов, команды и срок завершения в переданном фрагменте не названы.

Перед собственным пилотом отделите выбранные системы от остального парка и зафиксируйте их зависимости от CentOS Linux. В разборе LWN есть видео доклада и слайды сотрудников CERN: используйте их для изучения кейса, а не как готовую инструкцию.

ZeroTier можно запустить без нативных библиотек, а на ESP32 оставить только P2P

Для сервисов на .NET появилась ZtSharp: реализация ZeroTier на C# со своим стеком TCP/IP поверх виртуального Ethernet. Она не требует нативных бинарников и отдельных P/Invoke-обёрток для каждой ОС.

Для ESP32 автор оставил только VL1, слой с идентификацией узлов, шифрованием, поиском пиров и обходом NAT. ZtLiteESP передаёт сообщения напрямую между узлами без виртуального Ethernet и IP-связности. Ещё один проект, ZtGenStorage, создаёт идентификаторы ZeroTier при подготовке устройства, а не на самом микроконтроллере.

Перед пилотом определите границу: если устройству нужна обычная IP-связность, потребуется VL2; если достаточно прямых сообщений между узлами, можно оценить VL1-only клиент. В статье показано, как обязанности разделены между двумя слоями и тремя проектами.

eBPF убирает код трассировки из Go-сервисов, но зависит от среды выполнения

Ручная инструментализация OpenTelemetry расползается по вызовам SDK, передаче контекста и служебным метаданным. Под нагрузкой она может расходовать процессорное время, а пропущенная ветка оставит дыру в трассе. eBPF-пробы цепляются к функциям Go и точкам входа HTTP и gRPC, не меняя целевой бинарник.

Цена переноса логики наружу: горутина переезжает между потоками ОС, Go 1.17 перенёс аргументы со стека в регистры, а инлайнинг может убрать функцию для пробы. Трассеру нужна привязка по ID горутины и логика под соглашение о передаче аргументов каждой минорной версии Go либо отладочные данные DWARF.

Перед продом проверьте точную версию Go, а также откуда трассер читает аргументы: из регистров или данных DWARF. В разборе на DEV Community остались механика проб, границы подхода и компромиссы для эксплуатации.

Как проверить аварийное восстановление приложений в Kubernetes

Обстоятельный разбор Cloud Native Computing Foundation отделяет резервную копию от готовности восстановиться. В трёх опытах с PostgreSQL результат сверяли с четырьмя контрольными строками, а не со статусом ресурсов.

Velero показал 47 989 888 байт, хотя Completed не подтверждает запуск приложения. GitOps вернул манифесты и создал пустой том. Два исправных снимка томов с интервалом пять секунд оставили после восстановления 25 платежей без заказов.

Для согласованных снимков в Kubernetes 1.36 есть VolumeGroupSnapshot, но его должен поддерживать драйвер. В статье Cloud Native Computing Foundation даны лаборатория, команды и ограничения API.

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

А вы уже забрали свой подарок ко Дню программиста?

Мы в Tproger вместе с нашими друзьями собрали целую коробку подарков к вашему профессиональному празднику. Переходите по ссылке, трясите коробку и забирайте свой презент: https://tprg.ru/GPUR

Как превратить SLO в алерты, которые не будят зря

У порога ошибок есть перекос. Для SLO 99,9% за 30 дней правило Prometheus «ошибки ≥ 0,1% за 10 минут» заметит полную недоступность за 0,6 секунды, но может срабатывать до 144 раз в сутки, хотя сервис всё ещё выполнит SLO.

Увеличить окно до 36 часов? Точность вырастет, зато после полной недоступности сигнал продолжит гореть 36 часов. Добавить for: 1h? Пятиминутные всплески каждые десять минут вообще не вызовут алерт, хотя съедят 35% месячного бюджета ошибок.

В главе Alerting on SLOs авторы сравнивают шесть схем по точности, полноте обнаружения, времени срабатывания и сброса. Практический ориентир: откажитесь от одного фиксированного порога и длительности for; стройте правила по скорости расходования бюджета ошибок относительно SLO. Так тяжёлый инцидент даст сигнал быстрее, а незначимое событие не превратится в вызов дежурного.

Как завершать Pod в Kubernetes без оборванных запросов

При rolling update, масштабировании или вытеснении Pod могут удалить, пока он отвечает на запрос. Для Service маршрут до экземпляра задаёт endpoint: IP-адрес Pod вместе с targetPort. В список попадают Pod, прошедшие readiness probe; при создании и удалении Pod список обновляется.

Перед изменением Deployment проверьте путь остановки:
1. новый Pod принимает трафик только после readiness probe;

2. для завершаемого Pod настроен preStop;

3. у долгих задач и постоянных соединений есть отдельный сценарий завершения;

4. длительность остановки согласована с масштабированием кластера.

В разборе Learnk8s показан путь Pod через kubelet, Service и endpoints, затем сценарии корректного завершения. Используйте его как чеклист для теста rolling update без оборванных соединений.

Как выбрать distroless-образ для статического и динамического бинарника

FROM scratch даёт пустую файловую систему. Каталоги, CA-сертификаты, данные пользователей, часовые пояса и общие библиотеки приходится добавлять вручную. Distroless уже содержит необходимый системный минимум.

Для статически собранного приложения подходит gcr.io/distroless/static: около 2 МБ, без libc и менеджера пакетов. Бинарнику с зависимостью от glibc нужен base-nossl размером около 15 МБ, а при зависимости от libssl — base размером 20,7 МБ. В замере статьи Trivy нашёл в static 0 уязвимостей, а в base восемь: семь низкой и одну средней опасности.

Перед сменой образа проверьте зависимости бинарника через ldd и выберите минимальный вариант с нужными библиотеками. Иерархию образов и Dockerfile для Go с CGO автор показывает в разборе iximiuz Labs.

Как удержать кардинальность метрик Prometheus под контролем

Кардинальность метки: число её уникальных значений. Число рядов равно произведению количеств значений меток. В примере два HTTP-метода, семь путей, пять машин и 12 рядов, создаваемых гистограммой, дают 840 временных рядов. Добавление одного значения к первым трём меткам увеличивает результат до 1728.

Проверьте /metrics: найдите метки, число значений которых может превысить 10 по мере роста сервиса. Особенно следите за идентификаторами клиентов и числом корзин гистограмм. Не переносите значения в имя метрики: количество рядов от этого не уменьшится.

Детализацию по отдельным запросам оставьте журналам событий, а метрики используйте для общей картины и оповещений. Механика роста и ориентиры по пределам разобраны в статье Robust Perception.

В Суздаль за DevOps

Недавно мы съездили на «Без предела: Исходный код ритейла» от MAGNIT TECH в Суздаль. Разговор о технологиях начинался с купеческих рядов, продолжился на Demo Day на ГЭС на Нерли, а затем перешёл к самовару. Мы кайфанули от формата.

У Владимира Дроздецкого, например, зацепил заход через первый рабочий день инженера. По мере знакомства с инфраструктурой за привычными сборками и выкладками обнаруживается хозяйство на тысячи ядер. Через такую историю масштаб ощущается лучше, чем через цифры сами по себе: можно примерить на себя работу человека, которому всё это поддерживать. Ради этого взгляда изнутри советуем открыть презентацию. И наставление от Владимира не забудьте:

Не важно, сколько раз ты упал – важно, сколько раз ты поднялся. Главное — поднимайся с правильным IP-адресом

Модемный скрип перед соединением — если он сразу всплыл в голове, то тебе как раз в анкету от SpaceWeb и Типичного программиста! Она напомнит времена ЖЖ, гостевых книг, первых твитов и других интернет-икон того времени. Заодно расскажем, как менялись веб и SpaceWeb за 25 лет, немного заглянем в будущее, а в конце — промокод и результат, который может удивить.

Как requests и limits управляют подом Kubernetes

В манифесте четыре значения стоят рядом, но работают на разных этапах. Планировщик сравнивает requests с allocatable узла. После запуска kubelet и среда контейнеров переводят настройки в cgroups, где Linux распределяет CPU и ограничивает память.

Низкий requests.cpu уменьшает долю CPU при конкуренции. Достижение limits.cpu включает троттлинг: растёт задержка, падает пропускная способность. Заниженный requests.memory ужесточает вытеснение и OOM, а превышение limits.memory приводит к OOM kill. HPA считает загрузку относительно request.

Сопоставьте requests с kubectl top и allocatable узла: текущее потребление может быть ниже, но планировщик всё равно учитывает весь request. В руководстве Learnkube есть разбор от YAML до механизмов Linux.

Как проследить путь сетевого пакета в Kubernetes

В одном pod контейнеры делят сетевое пространство имён, IP-адрес и порты, поэтому видят друг друга через localhost. Пространство создаёт среда выполнения контейнеров, pause удерживает его, а CNI назначает IP и подключает pod к сети кластера.

В разборе пути пакета показаны маршруты к pod на том же и другом узле, а также к Service через Netfilter и iptables, которые перехватывают и переписывают трафик. Путь прослеживается от исходного запроса до контейнера приложения.

При сетевом инциденте начните с узла: lsns -t net покажет сетевые пространства, а sudo lsns -p <PID> свяжет их с процессом контейнера. Затем проверяйте границы по порядку: пространство pod, подключение CNI, связь между узлами и правила Service.

Как собирать компактные Docker-образы через multi-stage build

В одном Dockerfile можно отделить сборку от запуска: каждый FROM начинает новый этап, а COPY --from=build переносит в финальный образ только артефакт. В примере Docker Go SDK и промежуточные файлы остаются на этапе сборки, а образ на базе scratch содержит только бинарник.

Именуйте этапы через AS build: тогда COPY не сломается после перестановки инструкций. Для отладки собирайте этап командой docker build --target build . BuildKit обработает лишь этапы, от которых зависит выбранная цель.

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

Как изучить контейнеры от runc до Kubernetes

Контейнер полезно рассматривать как изолированную и ограниченную среду для процессов. В Linux пространства имён дают изоляцию, cgroups ограничивают ресурсы, а механизмы прав и фильтрации системных вызовов сужают доступ процесса. Программа runc подготавливает такую среду и запускает в ней процесс.

Затем стоит разобрать образы, containerd, Docker и оркестраторы. Для запуска runc достаточно каталога с config.json, исполняемым файлом и зависимостями. Образы нужны, чтобы экономить место и распространять файловые системы.

Практический порядок: запустить контейнер через runc, разобрать образ и containerd, затем связать эти слои с Docker и Kubernetes. Статья Learning Containers From The Bottom Up собирает маршрут и ссылки на углублённые разборы.

Как измерить и сократить toil в эксплуатации

Google SRE определяет toil как поток повторяющихся и предсказуемых задач поддержки: перезапусков, обновлений и разбора алертов. Такая работа может расти вместе с инфраструктурой, а закрытый тикет не предотвращает повтор проблемы.

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

Если инструкция сводится к входу на сервер, команде, проверке вывода и перезапуску сервиса, она уже похожа на псевдокод. Автоматизируйте выполнение без участия человека, а когда возможно, исправляйте первопричину. Критерии и примеры есть в главе «Eliminating Toil» из The Site Reliability Workbook.

OpenTelemetry бесплатен ровно до дня, когда вы начали его эксплуатировать

Стандарт снял привязку к вендорскому агенту: инструментируете один раз, шлёте куда хотите. Что начинается дальше, перечисляет спонсорский разбор на DevOps.com.

Коллекторов становится по одному на кластер или регион, у каждого свои batch и memory_limiter, и под нагрузкой узким местом оказывается сам коллектор. Хранение OTel не закрывает: трейс-стор, TSDB под метрики и индекс логов вы выбираете и обновляете согласованно. Переход от медленного спана к нужной строке лога тоже не появляется сам: слой корреляции пишете вы и правите при каждом изменении схемы. И пейджер при отвале ingestion звонит вашим инженерам, а не SRE вендора.

Что делать до миграции: заложить в план человека на пайплайн и посчитать квартальные часы на апгрейды SDK и семантических конвенций по всем сервисам. Не сходится — считать ценник managed.

Как выбрать инструменты для анализа производительности Linux

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

Для первого прохода возьмите Linux Performance Analysis in 60,000 Milliseconds: там перечислены первые десять команд для расследования. Затем выбирайте нужную глубину: perf для профилирования, eBPF и ftrace для трассировки, Flame Graphs для визуализации результатов. Есть и доклады по контейнерам, настройке EC2 и чеклистам SRE.

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

Что проверить перед запуском приложения в Kubernetes

Pod может запуститься, а обновление или масштабирование всё равно окажется хрупким. До релиза проверьте приложение: структурированные логи идут в stdout и stderr, настройки отделены от образа, несекретные лежат в ConfigMap, чувствительные в Secret.

При завершении процесс должен обработать SIGTERM: перестать принимать новые запросы, закончить текущие, закрыть соединения и выйти до terminationGracePeriodSeconds. Иначе Kubernetes остановит его принудительно, хотя трафик ещё может попадать в Pod.

Чек-лист LearnKube охватывает пять этапов: приложение, манифесты Kubernetes, безопасность, масштабирование и выход в продакшен. Пройдите его перед запуском, миграцией или внутренним ревью платформы и исправьте проваленные пункты до релиза.

Зелёный CI не ловит деградацию под трафиком, зато её ловит канарейка с автооткатом

Функциональные тесты проходят, а после выката растёт задержка: холодный старт функций, исчерпанный пул соединений к базе, упёршийся в потолок автоскейлинг. Этой нагрузки в пайплайне нет, регрессия вылезает уже на проде.

DevOps.com предлагает перестать считать тесты воротами «прошло/упало» и перенести проверку в выкат: Argo CD раскатывает манифесты, Flagger подаёт на новую версию 10% трафика, потом 30%, потом 100%. На каждом шаге он сверяет RED-метрики канарейки (запросы, ошибки, длительность) со старой версией и при скачке задержки по 95-му перцентилю сам откатывается.

Что делать: включить в тестах и сервисах трейсы OpenTelemetry, иначе сравнивать нечего; задать Flagger пороги по ошибкам и p95, разрешить автооткат; синтетику по ключевым сценариям гонять раз в минуту из регионов, где ваши пользователи.