Отладка с pprof и k6

Про pprof наверняка все знают. В статье автор еще раз показывает как им пользоваться, но прикольно что он использует k6 для нагрузки своего сервиса. k6 - это тулза от разработчиков графаны, скрипты для нагрузки можно писать на js. А для ограничения ресурсов CPU используется cgroup - это интересный подход для локального нагрузочного тестирования

#golang

https://kodikapusta.ru/news/42i9-otladka-s-pprof-i-k6

ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом.

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

ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.

Продукт уже работает для пользователей Kubernetes, Helm и GitOps.

Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.

Источник — пост Alexis Richardson на LinkedIn.

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

Коллеги сегодня принесли полезное https://github.com/kellyjonbrazil/jc

Костя Крамлих рассказал как они в Яндекс Облаке сделали сеть надежнее https://habr.com/ru/companies/yandex/articles/920092/
Я от сети далек, но мне понравился подход к решению reliability проблем и, кажется, что его можно использовать примерно везде

Гора родила мышь, а я наконец родил статью на основе материала, про который рассказывал весной на PHDays 2025 и CodeFest 15.

https://habr.com/ru/articles/872918/

#api #oauth #my_publication

Nelm vs Helm 4: что изменилось с новым релизом Helm и почему Nelm всё ещё лучше #habr
https://habr.com/ru/companies/flant/articles/970498/
Tags: nelm, helm, werf, open source, devops, kubernetes, cicd
Author: ilya-lesikov (Флант)

Помните, на прошлой неделе Cloudflare упал и уронил половину интернета?

Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.

Круто, что они опубликовали его прямо в день падения. Обычно, одни согласования с юристами занимают дни.

Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.

Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️

safedep/vet

vet — это инструмент безопасности цепочки поставок программного обеспечения с открытым исходным кодом, созданный для разработчиков и специалистов по безопасности

#golag

https://github.com/safedep/vet

⚡️ Kubernetes Namespaces: базовое разделение ресурсов в кластере

Namespaces в Kubernetes используются для логического разбиения кластера и изоляции ресурсов между командами, проектами и средами.

Что такое Namespaces
- Представляют собой «виртуальные кластеры» внутри одного физического.
- Группируют Pods, Services, Deployments, ConfigMaps и другие объекты.
- Полезны для multi-team, multi-project и multi-environment конфигураций.

Зачем они нужны
- Упорядочивают ресурсы и уменьшают хаос в большом кластере.
- Исключают конфликты имён — одинаковые ресурсы могут существовать в разных пространствах.
- Обеспечивают изоляцию команд и повышают безопасность.
- Позволяют держать dev/staging/prod в одном кластере без пересечений.

Стандартные Namespaces
- default — используется, если не указан другой; размещает обычные рабочие нагрузки.
- kube-system — системные компоненты (CoreDNS, kube-proxy).
- kube-public — доступен всем, включая неаутентифицированных пользователей; хранит публичную информацию.
- kube-node-lease — хранит heartbeat-объекты для узлов, повышая производительность контроля состояния.

Работа с Namespaces
- Создание — через YAML или kubectl, используется для группировки и изоляции ресурсов.
- Переключение контекста — позволяет работать в нужном namespace без постоянного указания -n.
- Удаление — очищает пространство вместе со всеми объектами, удобно для сброса окружения.

Типовые use cases
- Разделение окружений: dev/test/prod.
- Изоляция команд.
- Ограничение потребления ресурсов с помощью quotas.
- Границы безопасности через NetworkPolicies.

Resource Quotas
- Ограничивают CPU, RAM и количество объектов внутри namespace.
- Защищают кластер от «пожирания» ресурсов одной командой или сервисом.

Network Policies
- Контролируют сетевой трафик между namespace'ами.
- Используются для разграничения изоляции в multi-tenant конфигурациях.

Best practices
- Разводить окружения по отдельным namespaces.
- Не размещать рабочие нагрузки в kube-system.
- Настраивать RBAC на уровне namespace.
- Использовать понятные naming-conventions.
- Добавлять quotas в общих кластерах.

📎 Полное руководство по Kubernetes: https://codewithdhanian.gumroad.com/l/jwjls

Aliaksandr Valialkin - Cost-Effective Monitoring in Kubernetes

В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.

Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.

🔐 Postgresus - self-hosted инструмент для резервного копирования и мониторинга PostgreSQL базы данных

🔥 Возможности:
- создание бекапов по расписанию для PostgreSQL 13-18;
- уведомления в Telegram, Slack, Discord, если бекап сломался или база недоступна;
- хранение бекапов локально, в S3 или Google Drive;
- health check базы данных раз в минуту;
- Apache 2.0 лицензия (полностью открытый);

Запуск через Docker:

docker run -d 
  --name postgresus 
  -p 4005:4005 
  -v ./postgresus-data:/postgresus-data 
  --restart unless-stopped 
  rostislavdugin/postgresus:latest

📌 GitHub

Екатерина Истошина из Т-Банка и её история о том, как за год дежурные команды перешли от нервного тика и бесконечных инциндентов к контролю хаоса. Причём всё в цифрах, с конкретными тулами и без воды.

https://youtu.be/ccTMT2zgBtg

git-lfs: храним большие файлы в репозитории правильно

https://www.youtube.com/watch?v=82wj6y2rmR4

Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).

Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем fetch-depth: 1 или аналог, а использовать их надо).

Решение: использовать git-lfs!

Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит

Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️

Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?

| Поддержать | YouTube | GitHub | Чат |