STUN/TURN в Kubernetes

Вы хотите принять входящий RTP-трафик по UDP в приватном кластере Kubernetes. Что делать?
Динамические порты для VoIP (RTP) в приватном кластере — интересная задачка. Особенно если ноды без публичных IP, а трафик нужно принять снаружи. А еще в Kubernetes открыть диапазон портов для сервиса можно, например, с hostNetwork: true, потому что NodePort не поддерживает диапазоны портов. Кстати, с 2016 года висит issue — диапазоны портов на NodePort так и не подвезли.

🚀Тут выручают STUN и TURN.

☎️ VoIP-сессии (RTP) используют диапазон портов, а NAT и фаерволы могут это осложнить. STUN помогает клиентам узнать свой публичный IP и порт через NAT. TURN берёт на себя роль релея, если прямой путь заблокирован.

🌎 STUN: клиент отправляет запрос на STUN-сервер, получает ответ с внешним IP и портом. Потом сам решает, как отправлять пакеты. Быстро и просто, но не работает с симметричным NAT.
🔗 TURN: клиент подключается к TURN-серверу, тот выделяет порт и перенаправляет трафик.

🔧 Есть coturn — проверенный opensource-сервер для STUN и TURN. Разворачиваете с двумя сетевыми интерфейсами (приватным и публичным), настраиваете порты (обычно 3478 для STUN, плюс релейные для TURN), добавляете TLS для защиты. Поды VoIP-сервиса в K8s цепляются к нему через конфиги.

✅ STUN хорош для простых сценариев, TURN — для сложных. В приватном K8s они спасают RTP от проблем с NAT и фаерволами. Coturn выручает, если хочется свой сервер вместо облачных сервисов.

💡 kubectl explain

А вы знали, что kubectl explain выдает полную спеку ресурса с описанием всех параметров?

Например kubectl explain pods.spec.containers

🚨 А еще, если добавить
--recursive
, то покажет все возможные поля с описанием.

А так же, есть плагин https://github.com/keisku/kubectl-explore

What’s lacking in the original kubectl-explain?

- kubectl explain requires knowing in advance the resource name/fields.
- kubectl explain requires typing the accurate path to the resource name/field, which is a tedious and typo-prone.

📖 Kubernetes 1.33: что нового?

🛄 User namespaces для подов
Linux-поды теперь поддерживают user namespaces. Безопасность через ядро для ограничения привилегий.

🆙 Вертикальный апскейл без даунтайма
Stateful-процессы масштабируются вверх без остановки. Увеличение ресурсов без перезапусков.

🔧 Удаление Windows Host Networking
Альфа-фичу из 1.26 (KEP-3503) убирают — containerd не поддерживает это, как выяснилось.

Картинку сгенерил с помощью ChatGPT с четвертого раза своим дегенским промптом

🚀 syncgit — ClickOps + GitOps без дрифта

Любопытная тула для обьединения ClickOps и GitOps подходов к управлению ресурсами в Kubernetes.

🙏 Теперь можно делать изменения напрямую в кластере, не переживая, что тот же ArgoCD отклонит эти изменения, так как они сразу попадут в git-репозиторий, а оттуда через ArgoCD синхронизируются в кластере. Таким образом мы исключаем configration drift, оставляя возможность ручного управления.

📖 подробнее объяснение концепции тут и как это работает с ArgoCD тут

🚀 Исследование DevOps в России 2025

«Экспресс 42» запустил ежегодный опрос про состояние DevOps. Цель — собрать 4000+ ответов от инженеров, разработчиков, админов, тестировщиков и IT-руководителей.

🔍 Фокус года: Developer Experience. Как внутренние платформы, ML/AI, облака и ИБ влияют на жизнь разработчиков.

🎁 Бонусы:
- Доступ к результатам исследования.
- Шанс выиграть мерч, промокоды или билеты на Highload++ и DevOpsConf.

Если вы связаны с DevOps — пройдите опрос. Чем больше ответов, тем точнее картина.

💡 А вы знали, что в logrotate daily и size — не работают вместе?

В logrotate нельзя просто заюзать daily и size вместе — они взаимоисключающие. Size плюёт на время ротации, а daily не смотрит на размер логов. Итог? Логи либо растут, либо ротируются когда не нужно.

maxsize <size> -- ротирует логи, если они перевалили за размер, учитывая время (daily, weekly, monthly). Так мы получим что хотели.

📜 man logrotate

maxsize size: Log files are rotated when they grow bigger than size bytes even before the specified time interval. Both size and timestamp are considered.

Один гений решил не читать доки — дальше вы знаете что произошло. 😎

🚀 GPU-шаринг в Kubernetes: Project HAMi

Ранее уже писал про шаринг GPU в Kubernetes и репостил про сложности мониторинга. Сейчас наткнулся на более зрелый проект — k8s-vGPU-scheduler, который теперь называется Project HAMi (Heterogeneous AI Computing Virtualization Middleware).

💡 Почему вообще появился HAMi? По словам разработчиков, потому что ни одно из существующих решений не покрывает реальные потребности:

- Time slicing — просто в конфигурации, но нет изоляции и плохо с производительностью.
- MPS — поддерживает параллельные вычисления, но снова нет изоляции.
- MIG — есть изоляция, но нужна статичная конфигурация ноды, и работает только на дорогих картах.
- vGPU — платное, требует виртуализации, не вписывается в kubernetes-native подход.

🔧 Что умеет HAMi:
- Использование vGPU с любым значением памяти
- Гибкая конфигурация нагрузок: тип карты, affinity и т.д.
- Метрики GPU на уровне контейнеров с готовыми дашбордами
- Динамический MIG — без ребутов и статических настроек
- Работает с любыми видеокартами, не только A100
- Поддержка NVLink уже на подходе

👀 Выглядит как очень интересное решение для AI-нагрузок в Kubernetes.

🚀 Argo CD 3.0

🧱 Что изменилось:

– argocd-server теперь один бинарник
– убрали redis
– добавили lua-плагины
– много упрощений вокруг rbac

🏠 Проект становится проще и взрослее в плане архитектуры, но глобально — ничего не поменялось. Можно не спешить обновляться.