Вышел годный инструмент, который помогает изучать Linux на практике

Shell Gym – интерактивный тренажёр командной строки Linux, созданный на основе многолетнего опыта преподавания. По сути, автор выделил ядро iximiuz Labs и превратил его в отдельный демон.

https://github.com/iximiuz/shellgym

👉 DevOps Portal

Большинство считает, что Kubernetes Gateway API предназначен только для Ingress. Но это не так.

Gateway API также умеет управлять east-west-трафиком – то есть взаимодействием между сервисами. Разберёмся, как это работает

Для начала нужно понять, что такое инициатива GAMMA.

GAMMA — Gateway API for Mesh Management and Administration

Изначально Gateway API был разработан для управления ingress-трафиком.

То есть трафиком, который поступает извне кластера к сервисам внутри него – это сценарий north-south.

GAMMA расширяет возможности Gateway API на внутренний трафик service mesh – то есть на east-west-трафик.

Это означает, что одни и те же ресурсы Gateway API можно использовать как для Ingress, так и для service mesh.
Но есть важное отличие 👇

Обычно при использовании таких ресурсов Gateway API, как HTTPRoute, GRPCRoute и других, в качестве parentRef указывается Gateway.

Именно Gateway является точкой входа, которой принадлежат IP-адрес и порты, принимающие трафик извне кластера.

Однако в подходе GAMMA при настройке mesh-трафика ресурсы Gateway API, например HTTPRoute, могут использовать в качестве parentRef не Gateway, а Service.

После этого HTTPRoute определяет, как должен маршрутизироваться трафик, поступающий на этот Service: распределение по весам, разделение трафика и другие правила.

Схема прохождения трафика выглядит так:

client → общий Service (backend) → Services отдельных версий (backend-v1, backend-v2) → pods

При этом нельзя использовать паттерн «общий Service + subsets», как в связке Istio VirtualService и DestinationRule.

Причина в том, что Gateway API проектируется как единый стандарт, который должен работать с разными реализациями service mesh, включая Istio, Linkerd и другие.

👉 DevOps Portal

В этой статье рассказывается, как спроектировать ИИ-агента для SRE-задач, который анализирует алерты, логи, данные Kubernetes, ранбуки, деплои и сигналы систем наблюдаемости, чтобы диагностировать инциденты и предлагать безопасные действия.

Читайте тут

👉 DevOps Portal

🍻 Сегодня отмечается день системного администратора 🍻

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

В 2026 году этот день выпал на 31 июля.

Поздравляем всех сисадминов с праздником!

@linuxos_tg

С Днём сисадмина — праздником тех, кто держит прод в проде

На ежегодном слёте сисадминов записали интервью: спросили, что в работе любят больше всего и как справляются со стрессом.

Помогает и банальное: в Яндекс 360 управление сотрудниками, доступами и сервисами собрано в одной админке.

👉 DevOps Portal

KubeGUI — десктопное приложение с графическим интерфейсом для управления Kubernetes-кластерами, визуализации ресурсов и работы с ними.

➜ https://github.com/gerbil/kubegui

👉 DevOps Portal

Трекинг экспериментов в MLOps

В машинном обучении при каждом обучении модели создаётся новый запуск обучения.

Эксперимент - это набор таких запусков.

Трекинг экспериментов - это автоматическое логирование важной информации о каждом запуске обучения.

Например, во время каждого запуска обучения ML-модели сохраняются следующие данные:

- Параметры: алгоритм, гиперпараметры, версия датасета.
- Метрики: точность, F1-мера, время обучения.
- Артефакты: файл модели, файлы окружения и другие материалы.
- Метаданные: информация о расположении артефактов, сигнатура модели, пример входных данных, пользовательские метаданные и другое.

Это похоже на то, как в CI-системах отслеживаются SHA коммита, номер сборки, логи и другие данные.

Трекинг экспериментов выполняет ту же задачу для запусков обучения моделей машинного обучения.

Поэтому запуск обучения без трекинга - это как CI-сборка без истории сборок.

Самый распространённый инструмент для трекинга экспериментов - MLflow.

👉 DevOps Portal

Разбираем MLflow на практических примерах

Вот разбор про MLOps, где рассмотрели MLflow — один из ключевых инструментов в MLOps.

В материале:
- Что такое трекинг экспериментов
- Как устроена архитектура MLflow
- Развёртывание MLflow в Kubernetes — практика
- Локальное обучение модели для прогнозирования оттока сотрудников и трекинг запусков через MLflow — практика
- Регистрация моделей и управление ими в MLflow Model Registry
И многое другое.

https://newsletter.devopscube.com/p/mlfow

👉 DevOps Portal

Kubeswitch — CLI-инструмент, который упрощает переключение между разными контекстами kubectl.

Kubeswitch можно использовать как полноценную замену kubectx.

➜ https://github.com/danielfoehrKn/kubeswitch

👉 DevOps Portal

Kubernetes Job и JobSet: в чём разница

Разбираемся

Job/CronJob запускает одну конкретную batch-нагрузку.

Например: ETL-задачу, резервное копирование, генерацию отчётов и т. д.

JobSet, в свою очередь, запускает несколько скоординированных Job как единую распределённую нагрузку.

Каждая Job в наборе может иметь собственный шаблон Pod и связанные с ним настройки, но весь набор при этом работает как единое целое.

Под капотом JobSet запускает дочерние Job в индексированном режиме. Это означает, что каждый Pod получает стабильный индекс и hostname, например worker-0, worker-1 и т. д.

Кроме того, JobSet создаёт headless-сервис, через который Pod могут обнаруживать друг друга.

Основной сценарий использования JobSet — нагрузки AI/ML и HPC.

Например, в Kubeflow Trainer JobSet используется для запуска распределённого обучения моделей.

👉 DevOps Portal

Изучите основы Kubernetes Ingress за 7 минут

В этом подробном материале разберём:

* Что такое Kubernetes Ingress?
* Как работает Kubernetes Ingress?
* Что такое Ingress Controller?
* Как работает Ingress Controller?
* Архитектуру Ingress и Ingress Controller

https://devopscube.com/kubernetes-ingress-tutorial/

Примечание: хотя Ingress по-прежнему остаётся самым распространённым вариантом, Kubernetes постепенно движется в сторону Gateway API для более продвинутого и гибкого управления трафиком.

Если сначала разобраться с Ingress, освоить Gateway API будет значительно проще.

👉 DevOps Portal

Xata — Kubernetes-native платформа для Postgres, предназначенная для запуска большого количества баз данных.

Поддерживает copy-on-write ветвление, scale-to-zero, автоскейлинг, высокую доступность (HA), бэкапы, REST API, CLI и RBAC.

https://github.com/xataio/xata

👉 DevOps Portal

Gang Scheduling в Kubernetes

Это одна из ключевых концепций в MLOps

Фреймворки для deep learning (TensorFlow, PyTorch и т. д.) требуют, чтобы во время обучения были запущены все воркеры.

Допустим, training job требует 8 воркеров, каждый из которых запрашивает по 1 GPU.

В Kubernetes-кластере свободно только 5 GPU.

Без gang scheduling стандартный scheduler обрабатывает каждый Pod независимо.

В результате 5 worker Pod'ов будут запланированы, а ещё 3 останутся в статусе Pending.

При этом 5 запущенных воркеров фактически не смогут начать обучение. GPU будут заняты, пока система ждёт оставшиеся воркеры.

При использовании gang scheduling scheduler сначала проверяет, достаточно ли ресурсов для запуска всего training job.

Если ресурсов хватает, все worker Pod'ы планируются одновременно.

Если нет — не планируется ни один Pod. Пять свободных GPU остаются доступными для других job'ов.

Это можно назвать подходом – «всё или ничего».

В первую очередь gang scheduling позволяет избежать неэффективного использования GPU из-за частично запланированных распределённых workload'ов.

Kubeflow Trainer поддерживает gang scheduling из коробки через podGroupPolicy.

Он работает с установленными в кластере плагинами для gang scheduling, например Coscheduling.

👉 DevOps Portal

K8up – это Kubernetes Operator, который позволяет:

- Делать бэкапы всех PVC с режимом доступа ReadWriteMany или с определённым label
- Запускать отдельные бэкапы по требованию
- Настраивать регулярный запуск бэкапов по расписанию

И многое другое

➜https://k8up.io/

👉 DevOps Portal

KEDA GPU Scaler — это внешний scaler для KEDA, который получает метрики NVIDIA GPU через NVML и автоматически масштабирует vLLM, Triton, training jobs и кастомные inference-нагрузки без необходимости использовать Prometheus.

https://github.com/pmady/keda-gpu-scaler

👉 DevOps Portal

DevOps-инструмент недели: Ray

ML-нагрузка может отлично работать на одной GPU.

Сложности начинаются, когда её нужно масштабировать на несколько GPU, работающих на разных нодах.

Именно здесь помогает Ray.

Ray – это опенсорс фреймворк с 43K+ звёзд на GitHub.

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

Ray можно запускать на ноутбуке, виртуальных машинах, bare-metal серверах, облачных инстансах или в Kubernetes.

Для Kubernetes обычно используется KubeRay – Kubernetes Operator для создания и управления Ray-кластерами.

Ray используют такие компании, как OpenAI, Uber, Spotify и Instacart, для масштабных AI- и ML-нагрузок.

https://github.com/ray-project/ray

👉 DevOps Portal

Canary vs Shadow Deployment vs A/B Testing

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

Разберём три распространённые стратегии деплоя моделей.

1. Canary Traffic Splitting
Небольшой процент реального трафика, например 10%, направляется на новую модель, после чего отслеживается её работа.

Если с предсказаниями всё в порядке, долю трафика постепенно увеличивают, пока она не достигнет 100%.

2. A/B Testing
Одну группу пользователей направляют на модель A, другую — на модель B с помощью sticky routing, после чего сравнивают бизнес-метрики: CTR, conversion rate, revenue и т. д.

3. Shadow Deployment
Каждый реальный запрос, как обычно, обрабатывается старой моделью, и пользователь получает именно её ответ.

При этом копия того же запроса в фоне также отправляется на новую модель.

После этого можно сравнить залогированные предсказания обеих моделей на одном и том же реальном трафике.

👉 DevOps Portal

20 Kubernetes-челленджей

Итак, вот 20 вопросов (и ответов):

1. Подсчёт endpoints

2. Ждём чуда

3. Я сказал стоп

4. Проектирование shared-кластеров

5. Kernel panic

6. Прыгай, кролик

7. Сколько — это слишком много

8. Держим свет включённым

9. Прожорливый etcd

10. Умножение pod’ов

11. В одиночку

12. Rollin’

13. All you can eat

14. Bounce

15. В кроличью нору

16. Throttled

17. Липкий бардак

18. Жив или мёртв

19. Связанный по рукам

20. Один, чтобы связать их всех

Вы можете использовать эти задания, чтобы прокачать свои знания, как (очень сложные) вопросы на собеседованиях или чтобы подготовиться к интервью

👉 DevOps Portal

KubePlumber проверяет работу сети Kubernetes изнутри кластера, тестируя:

* внутренний DNS,
* трафик между подами,
* внешний DNS,
* пропускную способность между нодами.

➤ https://github.com/David-VTUK/KubePlumber

👉 DevOps Portal