Вышла первая версия 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

Проект Minio теперь распространяется только в виде исходного кода. Если вы хотите создавать контейнеры, вам придётся делать это самостоятельно. Подробнее: https://github.com/minio/minio/issues/21647