Как Codex обнаружил регрессию в Kubernetes 👩💻 Начинаем рабочую неделю с фотоотчёта DevOps Lab и рабочего кейса портала HeyOnCall. После обновления Kubernetes до версии 1.36 Майк Роббинс заметил проблему на небольшом тестовом кластере. kubelet постепенно «съедал» всю память. Поды работали нормально, но pprof обнаружил миллион объектов контекста. Проблема возникла из-за небольшого регресса в коде startPodSync , и при каждом цикле синхронизации создавался новый context.WithCancel() , а старый никогда не освобождался. С Codex Роббинс быстро обнаружил проблемный коммит, подготовил исправление, прошёл ревью и добился включения патча в основную ветку и бэкпорта для релиза 1.36.3. 🔵 В статье о том, как найти утечку памяти в kubelet с Go pprof и сократить потребление с 1 ГБ до 110 МБ , почему подобные ошибки сложно поймать на тестировании и какая строка кода может привести к утечке сотен мегабайт памяти на каждой ноде. ➡️ А здесь мы оставили фото участников лабы, делимся атмосферой. Отмечайте @DevOps_FM в соц.сетях и расскажите о своих впечатлениях – тут 💙 #kubernetes #devops #kubelet #никсис
ПяПятничный деплой
CategoryOtherLanguageRUFirst seenJul 06, 2026QualityVerified
Subscribers1.7K
Avg views1.1K
ERR62.9%
Price-- RUB
Price / subscriber--
Price / view--
Metrics updated: Jul 06, 2026
Recent posts
Зацените какую штуку тут товарищ написал: https://github.com/crust-gather/crust-gather Она сохраняет стейт Kubernetes кластера в OCI-имадж (со всеми CRD, статусами, ивентами, подами и их логами) Потом его можно запустить локально и в нем покопаться обычным kubectl. Можно клода натравить, можно k9s, и т.п. Идеально подходит чтобы интегрировать в свой пайплайн. Написано на rust'е. Завтра будет рассказывать о ней на KCD https://kcd-czech-slovak-2026.sessionize.com/session/1195463 (есть прямая трансляция)
Редкий Docker-трюк для баз данных: отдельный volume под WAL У Postgres есть место, куда он пишет журнал изменений: WAL . Если база активно пишет данные, WAL может стать узким местом. В Docker его можно вынести в отдельный volume: services: db: image: postgres:16 environment: POSTGRES_PASSWORD: postgres POSTGRES_INITDB_WALDIR: /var/lib/postgresql/wal volumes: - pg_data:/var/lib/postgresql/data - pg_wal:/var/lib/postgresql/wal volumes: pg_data: pg_wal: Зачем это нужно: 1. данные базы лежат отдельно 2. журнал транзакций лежит отдельно 3. проще мониторить рост WAL 4. меньше риска забить основной volume логами Особенно полезно для staging, pet-проектов с нагрузкой и локальных стендов, где внезапно «почему Postgres сожрал весь диск». Мелочь, но уже уровень не “я просто поднял базу в Docker”, а нормальная инженерная привычка.
PEP 810: Explicit lazy imports 2 Как я уже писал , в Python 3.15 нас ждут lazy imports. В первом посте я описал основные фичи. Прочитайте его перед продолжением. Во втором посте настало время посмотреть на плохие части. Детали PEP, которые мы не осветили прошлый раз Во-первых, из очевидного: lazy import может быть использован только на уровне модуля, в других местах - он будет вызывать ошибку синтаксиса. Но, что забавно, lazy import не может быть использован внутри даже try блоков. Во-вторых, я не уточнил, как будет работать lazy_modules , а там дичь. Мы можем указывать lazy_modules = ['os', 'typing'] в любой версии питона. Очевидно, что работать как ленивые они будут только в 3.15+, в остальных - будет просто неиспользуемый атрибут. Но штука в том, что в разных версиях питона библиотеки будут работать по-разному. Но! Он будет ленивым, только если он может быть ленивым. То есть, если он находится внутри класса, функции, try , тд - он не станет ленивым. Удачи в дебаге, короче. Ну и самое забавное, мы можем управлять глобальным стейтом всех импортов через -X lazy_imports=none|normal|all и так же через переменную окружения PYTHON_LAZY_IMPORTS . Что оно значит? Отключаем все lazy импорты | все работает так, как написано | все импорты ленивые. Мы можем управлять тем, как работают импорты через переменную окружения!! Перечитайте, если вы тоже не поняли. Я вот не сразу понял. Внедрение в питон В stdlib питона уже активно используют lazy импорты. Однако, внутри уже появились циклические импорты. Потому что теперь так можно сделать случайно. И специально. Да, ленивые импорты могут помогать избегать циклических импортов. В некоторых режимах работы. Теперь stdlib больше не работает в режиме -X lazy_imports=none . О чем развернулась жаркая дискуссия, прочитать которую я всем советую: https://github.com/python/cpython/issues/149321 Но и режим -X lazy_imports=all все сломал. Теперь с ним некоторые библиотеки начали работать по-другому . Например: $ PYTHON_LAZY_IMPORTS=normal ./python -c "import shutil; print(shutil._BZ2_SUPPORTED)" False $ PYTHON_LAZY_IMPORTS=all ./python -c "import shutil; print(shutil._BZ2_SUPPORTED)" True Так как импорт становится ленивым, он больше не проверяет есть ли на самом деле библиотека _bz2 у вас. А просто всегда возвращает True . Что делать - пока никто не знает: https://github.com/python/cpython/issues/150167 Вот в такой ситуации мы все оказались. Зато теперь некоторые скрипты будут запускаться быстрее, потому что импорты в некоторых местах стали ленивыми. Иногда, не точно. Почему нельзя было использовать импорт внутри функции? Я не знаю. Мое отношение к данной фиче можно только охарактеризовать словами вечного инструмента wemake-python-styleguide : https://github.com/wemake-services/wemake-python-styleguide/issues/3639 Обсуждение : я даже не знаю, честно. Давайте просто обнимемся в комментах. | Поддержать | YouTube | GitHub | Чат |
Choosing a Go Logging Library in 2026 В прошлой статье вы узнали про популярные библиотеки логирования для Python. Сегодня — Go. Доминирование Logrus, zap и zerolog в течении долгого времени заставляло разработчиков использовать отдельные подходы к логированию. Начиная с Go 1.21, библиотека log/slog дает унифицированный способ логирования и отсутствие необходимости переключения между контекстами. В этой статье рассматриваются распространенные библиотеки ( спойлер : Slog , Zerolog , Zap , phuslu/log , Logrus и charmbracelet/log ), как они работают, чем отличаются друг от друга и когда достаточно просто усердно работать. Подробности в блоге dash0 📱 Telegram | 📲 MAX