Сломанный API в Nitro можно поймать раньше пользователей

Деплой Nitro-приложения может оставить фронтенд доступным, но сломать /api/*. Мониторинг одной главной страницы этого не покажет.

Добавьте маршрут /server/routes/health.get.ts:

export default defineEventHandler(() => ({
  status: 'ok',
  timestamp: new Date().toISOString(),
  service: 'nitro-app'
}))

Подключите маршрут к Vigilmon вместе с главной страницей и критичными API. Он подтверждает только ответ Nitro. Для контроля базы или внешнего сервиса проверяйте соединение в обработчике и возвращайте degraded при сбое. В руководстве также перечислены риски для сертификата, фоновых маршрутов и холодного запуска Cloudflare Workers.

Доступ к Kubernetes можно отзывать вместе с учётной записью

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

С OIDC доступ привязывается к учётной записи и группам. kubelogin запускает вход через браузер, получает ID-токен с именем и группами и добавляет его к запросам kubectl. kube-apiserver проверяет токен, а RBAC определяет разрешённые действия.

Для kubectl настройте публичный OIDC-клиент с PKCE, без клиентского секрета. Тогда доступ отзывается удалением пользователя из группы, а сертификаты распространять не нужно. В разборе Cloud Native Computing Foundation перечислены три компонента схемы и нужные параметры kube-apiserver.

Миллиард манифестов показал цену свежих контейнеров

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

За шесть месяцев до публикации Chainguard увеличила число манифестов сборки с 500 млн до более чем 1 млрд. Каждый такой манифест фиксирует новый артефакт: версию образа, пересборку после патча или вариант для другой архитектуры.

Проверьте правила своей цепочки поставки: патч базовой библиотеки, изменение зависимости и обновление исходного проекта должны запускать пересборку. В материале The Hacker News описано, как Chainguard OS и Chainguard Factory поддерживают непрерывный выпуск вместо полугодового релизного цикла.

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.