В Суздаль за 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, разрешить автооткат; синтетику по ключевым сценариям гонять раз в минуту из регионов, где ваши пользователи.

ACME отработал с кодом 0, а пользователи всё ещё получают старый сертификат

Cron обновил сертификат, джоба зелёная, а nginx, HAProxy или IIS держат в памяти прежний: файлы на диске новые, но процесс перечитывает их только после reload. Второй случай: скрипт кладёт файл в один каталог, а конфиг после давней миграции читает из другого. Скрипт выйдет с нулём, ничего не изменив.

Поэтому пайплайн заканчивается не успешной командой, а проверкой живого эндпоинта после reload:
• снять сертификат с боевого адреса: echo | openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -serial -enddate;
• сравнить serial и notAfter с тем, что только что задеплоили;
• расходятся: сделать reload и проверить, из какого пути читает сервис.

Пока этого шага нет, об истёкшем сертификате вы узнаёте от пользователей. Разбор цепочки от renew до recover — в статье на DevOps.com.