С 28 августа 2025 года в публичном каталоге Bitnami произойдут изменения:

- Прекратится генерация образов Debian, существующие переедут в Bitnami Legacy repository.

- Бесплатные hardened образы для разработки будут доступны только с тегом "latest" на hub.docker.com/u/bitnamisecure.

- Production-ready образы и Helm charts перейдут в Bitnami Secure Images (с hardening, CVE, SBOM, поддержкой и LTS).

- Старые образы (включая версии) будут перемещены в Bitnami Legacy repository (без обновлений и поддержки).


Рекомендации пользователям:

- Обновить CI/CD пайплайны, Helm репозитории и ссылки на образы.

- Протестировать hardened образы на hub.docker.com/u/bitnamisecure.

- Для production подписаться на Bitnami Secure Images (для поддержки и обновлений).

- Как временное решение - использовать Bitnami Legacy repository.


Различия репозиториев:

- Bitnami Mainline: актуальные образы (бесплатные и enterprise). После 28 августа 2025 - только hardened образы.

- Bitnami Legacy: архив старых версий (без обновлений).


Бесплатные образы сохранятся, но в ограниченном количестве и только "latest" версии. Для продолжения поддержки старых версий и приложений необходимо подписаться на Bitnami Secure Images. Исходный код Bitnami доступен на GitHub (Apache 2 license).


Для продолжения поддержки Helm charts рекомендуется подписка на Bitnami Secure Images. Временное решение - указать Bitnami Legacy repository в настройках Helm chart.

Подробности https://github.com/bitnami/containers/issues/83267

Вышла новая версия https://github.com/romashqua/alertcli - консольной утилиты для просмотра алертов. теперь не нужно собирать ее из исходников.

alertcli alerts list -A -u https://alertmanager.k8s.dev.corp | grep -v ScrapePoolHasNoTargets
ALERT                                  SEVERITY      STATE    SINCE      INSTANCE                                                                  SUMMARY                                                                                                    SILENCED BY   INHIBITED BY
KubernetesJobFailed                    warning       active   25h0m0s    victoria-metrics-k8s-stack-kube-state-metrics.victoria-metrics.svc:8080   Kubernetes Job failed (instance victoria-metrics-k8s-stack-kube-state-metrics.victoria-metrics.svc:8080)

Появилась легковесная замена sentry только с обработкой exception https://github.com/rom8726/warden-ce

#работа

А наш непубличный, но веселый стартап ищет еще разработчиков!

Команда выходцев из Grafana Labs, финансирование на несколько лет вперед, open source продукт.

Ищем опытного фуллстека со знанием React и готовностью ринуться в Rust. Можно и парт-тайм, и фулл-тайм ($90k-150k), релокация в Великобританию, или удаленка из Канады/Европы/Израиля/Грузии/Амении/Казахстана.

Пишите мне на почту matvey@archestra.ai с темой "Job", скидывайте гитхаб и 1-2 абзаца про себя.

Шер, репост по друзьям и знакомым!

Выпустили версию 0.2.1 плагина для wal-g и приглашаем всех к тестированию и использованию)

https://github.com/wal-g/cnpg-plugin-wal-g/releases/tag/v0.2.1

Из вкусного - прозрачный retention и удаление бэкапов (удаление ресурса Backup действительно удаляет бэкап из стораджа, retention работает с ресурсами Backup и опционально не трогает ручные бэкапы), поддержка полных и инкрементальных бэкапов (тип созданного бэкапа прописывается в labels), шифрование, подхватывание изменений конфигурации на лету без перезапуска, контроль потребления ресурсов и производительности (можно кастомизировать ограничения ресурсов на сайдкар wal-g, а также ограничивать нагрузку на диск/сеть и параллельность работы)

Несколько ссылок по проверке Custom Resource Definitions в Kubernetes:

1) https://ianhomer.com/kubernetes-crd-auto-completion/ - инструкция по добавлению проверки Custom Resource Definitions в IDE, pipeline, pre-commit

2) https://kubespec.dev/ - отображение изменений в ресурсах Kubernetes

3) https://github.com/datreeio/CRDs-catalog - каталог Custom Resource Definitions. Так же репозиторий содержит утилиту для добавления # yaml-language-server: $schema= в начало файла для автоматического определения yaml схемы в IDE для его валидации.

4) https://github.com/imroc/kubeschema.nvim - нативная поддержка схемы kubernetes для neovim

Как чинить rabbitmq кластер, если дроп очереди не помогает.

kubectl exec -it service-rabbitmq-0 -- rabbitmqctl stop_app
kubectl exec -it service-rabbitmq-0 -- rabbitmqctl reset
kubectl exec -it service-rabbitmq-0 -- rabbitmqctl join_cluster rabbit@service-rabbitmq-1
kubectl exec -it service-rabbitmq-0 -- rabbitmqctl start_app

Проект https://github.com/external-secrets/external-secrets приостанавливает создание новых релизов пока не будет как минимум пяти постоянных сопровождающих.

Поддержка сообщества
• PR-проекты сообщества будут продолжать рассматриваться и объединяться.
• В основной ветке будут доступны изменения.
• Поддержка через GitHub Discussions, Slack и комментарии к выпускам прекращена.
• Новые версии, включая 0.19.x и 1.0.x, не будут публиковаться.

Вышла первая версия helm чарта VictoriaLogs Collector - для сбора логов из контейнеров Kubernetes и отправки их в VictoriaLogs. Желаю развития проекту.

https://github.com/VictoriaMetrics/helm-charts/releases/tag/victoria-logs-collector-0.0.1

#кулстори #connectionpool

вводные:
представим, что есть у нас классный бэкенд, он готов обрабатывать много запросов, он стейтлесс, поэтому мы с вами ожидаем, что мы его легко можем замасштабировать горизонтально. для верности мы даже проведем нагрузочные тесты и по-прежнему все отлично, при пиковой нагрузке добавляем +1 инстанс и выдерживаем её.

проблема:
запускаем нашего красавчика в проде и дальше видим, что происходит ужасное, у нас в 100% cpu утилизирован 1 под. изучив логи, трейсы и другую телеметрию становится ясно - только этот под обрабатывает запросы, а остальные из ReplicaSet стоят, курят. скажите "виноват балансировщик"? смотрим дальше и выясняем, что запросы летят от соседнего сервиса (сервиса А) и ходит он по svc name, запросов довольно мало, то есть между вами никакого балансировщика нет.

что же происходит?
чтобы не тратить драгоценные миллисекунды и ресурсы на tcp-хендшейки, клиенты используют пулы соединений (connection pools). благодаря http keep-alive, однажды открытое соединение не закрывается, а кладётся в пул, чтобы его можно было быстро переиспользовать.
и вот что получается на практике:
1. наш сервис А (клиент) хочет сделать первый запрос. он обращается к dns: "дай айпишник для svc name".
2. dns честно отдаёт ему ip одного из подов сервиса Б.
3. клиент устанавливает с этим конкретным подом соединение (открывает сокет) и отправляет запрос.
4. получив ответ, он не рвёт коннект, а аккуратно возвращает его в свой пул.
когда прилетает второй, третий, сотый запрос. зачем клиенту снова идти в dns и создавать новый коннект, если есть готовенький коннек? он просто берёт его из пула. в итоге все запросы летят в один и тот же под сервиса Б, и вся наша красивая схема с горизонтальным масштабированием не работает.

как решить проблему?
например, можно пустить трафик через ингресс - через него идет, скорее всего, много трафика и поэтому пулы коннектов будут шире. в таком случае нжинкс или любой другой балансировщик будет держать свой набор сокетов и коннектов к сервису Б, за счёт чего размажется трафик. это добавляет латенси, но вот прям элегантные решения пока не нашел :)

знайте! ваши запросы не балансируются через service ip сущность кубрнетеса, через нее происходит только резолвинг, а сами коннекты в итоге устанавливаются pod2pod, и запросы летят тоже pod2pod

Выложены доклады с DevOops 2024

Слайды доступны на сайте
https://devoops.ru/archive/2024/schedule/days/

YouTube - https://youtube.com/playlist?list=PL-ety8gh7rToGNJOxs1oZtpUXJfADb1mX
VK - https://vkvideo.ru/playlist/-149053226_19

В sentry kubernetes версии v27.3.0 добавили очистку старых данных в clickhouse https://github.com/sentry-kubernetes/charts/pull/1876

Зарелизился helm чарт для трейсов от VictoriaMetrics с версией 0.0.1 - аналог grafana tempo
https://github.com/VictoriaMetrics/helm-charts/releases/tag/victoria-traces-single-0.0.1
https://github.com/VictoriaMetrics/helm-charts/releases/tag/victoria-traces-cluster-0.0.1

VictoriaTraces использует в 3,7 раза меньше оперативной памяти и в 2,6 раза меньше процессора, чем другие решения, такие как Grafana Tempo.

Базовый алгоритм при выборе схемы должен быть следующим:

Помещаются ли все ваши логи на 1 сервер? Если да, то вам не нужен кластер, просто используйте VictoriaLogs без vmauth.
Если нужен HA 2, то разверните еще один экземпляр VictoriaLogs и реплицируйте логи в оба хранилища (например, через vlagent или vector); в такой схеме понадобится vmauth или любой другой балансировщик, чтобы балансировать нагрузку между кластерами.

Если логи не помещаются на 1 сервер, то вам нужен кластер из нескольких vlstorage. В такой схеме vlselect нужен для агрегирования результата при поиске и vlinsert для шардирования логов между vlstorage; vmauth может пригодиться, если у вас несколько vlselect, и вы хотите распределить нагрузку.
Если нужен HA 2, то разверните несколько таких кластеров с одинаковой конфигурацией; используйте vmauth для балансировки нагрузки между кластерами (между всеми vlselect что у вас есть).

См. также схему кластерной VictoriaLogs с HA=2. vlagent - это буфер, который реплицирует логи и является устойчивым к недоступности одного из кластеров.

🚀 Flux 2.7.0 — новый релиз с важными обновлениями

### 🔑 Ключевые изменения:

* 📦 GA-релиз Image Automation APIs (ImagePolicy, ImageRepository, ImageUpdateAutomation)
* 🔄 Поддержка отслеживания изменений в ConfigMaps и Secrets
* 🔐 Аутентификация удалённых кластеров через Workload Identity
* ✅ Расширенная проверка готовности зависимостей (CEL expressions)
* 🔑 Поддержка глобальных SOPS Age ключей
* 🧩 Опциональные Kustomize components
* ♻️ Новый подход к управлению жизненным циклом — RetryOnFailure (HelmRelease)
* 🔒 Поддержка mTLS при отправке алертов и работе с GitHub App
* 📊 OpenTelemetry tracing для Kustomization и HelmRelease
* 🧩 Поддержка сторонних source-контроллеров и новых паттернов работы с артефактами

### ⚡️ Совместимость

* Kubernetes: поддерживаются версии 1.32, 1.33, 1.34
* OpenShift: установка через Flux Operator в OperatorHub с поддержкой multi-tenancy, sharding, scaling и синхронизации состояния кластера.

### ⚠️ Важно при апгрейде

* API v1beta1 и v2beta1 полностью удалены.
* Если вы не используете Flux Operator, необходимо запустить команду:

flux migrate

https://github.com/fluxcd/flux2/releases/tag/v2.7.0

Perses теперь поддерживает VictoriaLogs

Яндекс облако выложил на GitHub Network Block & File Store https://github.com/ydb-platform/nbs - аналог NFS

Очень добротный доклад на тему "Логи под нагрузкой как выбрать хранилище и не пожалеть — разбираем ELK, Loki и VictoriaLogs"

+ Инструмент, который использовался для тестирования в докладе https://github.com/lHumaNl/DBLogsComparator

https://tube.pflb.ru/w/j4Tzu3pJw54sHqcNEVHaGU

Разработка проекта Ingress NGINX будет полностью прекращена в марте 2026 года. После этой даты — никаких обновлений и исправлений уязвимостей. Подробнее https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

29 версия Docker повысило минимальную версия API до 1.44
Error response from daemon: client version 1.43 is too old.
Minimum supported API version is 1.44, please upgrade your client to a newer version
Подробнее https://www.docker.com/blog/docker-engine-version-29/

В self-hosted версию sentry добавили поддержку S3 NodeStore.
Подробнее https://github.com/getsentry/self-hosted/pull/3498