В этой статье объясняется, почему Ingress заменяют на Gateway API, за что на самом деле отвечают новые ресурсы Gateway, Route и Policy, а также как выбрать gateway-контроллер перед миграцией

➜ https://www.romaglushko.com/blog/k8s-gateway-api/

👉 DevOps Portal

В этой статье разбирается, как спроектировать production-ready MCP-сервер для платформенных команд: governance, клиенты для бэкендов, определения инструментов и аутентификация вынесены в четыре отдельных слоя. Также рассматриваются RBAC и деплой, которые необходимо настроить до того, как сервер получит доступ к реальному кластеру

➜ https://dev.to/agenticdevops/mcp-server-architecture-for-platform-teams-giving-ai-live-access-to-your-infrastructure-3n76

👉 DevOps Portal

Docker 101: Как достучаться до контейнера без проброса порта

Знали, что IP-адрес контейнера может быть доступен напрямую с Docker-хоста? Это значит, что обращаться к приложениям внутри контейнеров можно без проброса портов - важный момент для понимания того, как устроена сеть в Docker.

Попробовать на практике:
https://labs.iximiuz.com/challenges/docker-101-container-find-ip-address

👉 DevOps Portal

Обработка миллионов файлов – это та точка, где большинство распределённых систем хранения начинают тормозить.

По мере роста количества файлов основной проблемой становится их быстрый поиск.

Большинство систем держат единый индекс, в котором хранится информация о размещении всех файлов.

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

В CubeFS это реализовано иначе.

Система разбивает файловый индекс между несколькими серверами.

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

Поэтому система остаётся быстрой даже тогда, когда множество приложений одновременно читают миллионы файлов.

Если ты работаешь с данными для обучения ИИ или обрабатываешь большие датасеты, такая архитектура имеет значение.

Github: cubefs

👉 DevOps Portal

Как работает Kubernetes Cluster Autoscaler? Базовый флоу выглядит так

Pending Pod → Cluster Autoscaler → добавление ноды → Scheduler размещает Pod

Когда Pod переходит в состояние Pending, потому что scheduler не может найти ноду с достаточным количеством ресурсов, Cluster Autoscaler проверяет, поможет ли добавление новой ноды из одной из настроенных node group запустить этот Pod.

Если да, он масштабирует соответствующую node group вверх.

После того как новая нода присоединяется к кластеру, scheduler размещает на ней ожидающий Pod.

В обратную сторону это тоже работает.

Если нода долго остаётся недозагруженной и её Pods можно безопасно перенести на другие ноды, Cluster Autoscaler дренирует эту ноду и уменьшает размер node group.

Cluster Autoscaler часто используют вместе с HPA.

Вот как они работают в связке:

- Когда трафик растёт, HPA создаёт больше Pods
- Из-за нехватки ресурсов на нодах часть Pods переходит в Pending
- Cluster Autoscaler замечает это и добавляет новые ноды
- После этого pending Pods планируются на новых нодах

Вот практический гайд по настройке Cluster Autoscaler в AWS EKS.

Читать: https://devopscube.com/cluster-autoscaler/

👉 DevOps Portal

В этом туториале показано, как разворачивать и масштабировать большие языковые модели (LLM) в Kubernetes с помощью KServe, использовать KEDA для масштабирования в зависимости от нагрузки и запускать инференс через vLLM

➜ https://medium.com/@sowmithdurusoju/serving-llms-at-scale-a-practical-guide-with-kserve-keda-vllm-kubernetes-e93ba6b1a65e

👉 DevOps Portal

Интересный и полезный опенсорс-инструмент

Как часто приходилось открывать консоль AWS и другие инструменты, чтобы ответить на простые вопросы:
- У каких ресурсов отсутствуют обязательные метки?
- Есть ли хранилища, доступные публично?
- В каких неймспейсах Kubernetes отсутствуют NetworkPolicy?
И так далее...

Ответы на эти вопросы есть, но для их поиска часто приходится переключаться между сервисами, проверять несколько аккаунтов или писать скрипты.

А что, если на эти вопросы можно было бы отвечать с помощью простого SQL-запроса?

Именно для этого существует Steampipe.

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

В подробной статье разобраны возможности Steampipe, способы его использования и основные сценарии применения.

Читать статью: devopscube.com/steampipe-tuto

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

Наиболее полезные сценарии использования:
- Анализ данных сразу из нескольких сервисов.
- Инвентаризация ресурсов в нескольких аккаунтах.
- Разовые проверки безопасности.
- Анализ облачных расходов в рамках FinOps.

Примечание: Steampipe не пытается заменить AWS Config или CSPM-платформы. Это просто более удобный способ разобраться, какие ресурсы на самом деле находятся в облаке, когда нужно быстро получить ответ

👉 DevOps Portal

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

Со временем в Kubernetes-кластерах могут накапливаться неиспользуемые ресурсы: например, ConfigMaps и Secrets, которые больше никому не нужны, или Services, не связанные ни с одним Pod.

Сегодня они могут не вызывать проблем, но со временем способны привести к сбоям, уязвимостям в безопасности и неэффективному расходованию ресурсов.

Искать такие ресурсы вручную по всем namespaces неудобно. Здесь и помогает Popeye.

Popeye — опенсорсный инструмент от создателя k9s, который проверяет ресурсы работающего Kubernetes-кластера на ошибки конфигурации и наличие неиспользуемых ресурсов.

Что умеет 👇
- Находит неиспользуемые ConfigMaps, Secrets, ServiceAccounts, PV, PVC и RBAC-роли.
- Выявляет Services без endpoints или соответствующих Pods.
- Проверяет Pods на отсутствие проб, лимитов ресурсов и использование тега latest у образов.
- Показывает распределение CPU и памяти при наличии metrics-server.
- Оценивает состояние кластера по шкале от 0 до 100.
- Экспортирует отчёты в форматах HTML, JSON, YAML, JUnit и Prometheus.
- Может запускаться как CronJob и отправлять отчёты в S3.

Начать работу: github.com/derailed/popeye

Примечание: Popeye работает в режиме read-only, поэтому ничего не изменяет в кластере.

👉 DevOps Portal

Kubernetes: Client-Side Apply vs Server-Side Apply

При выполнении команды kubectl apply по умолчанию используется Client-Side Apply (CSA).

При использовании Client-Side Apply утилита kubectl анализирует манифест, ранее применённую конфигурацию и текущее состояние объекта в кластере.

На основе этих данных kubectl определяет, что изменилось, и отправляет необходимый патч на API-сервер Kubernetes.

Server-Side Apply (SSA) работает иначе.

При выполнении команды kubectl apply --server-side операцию применения конфигурации выполняет сам API-сервер Kubernetes.

Главное отличие — владение полями.

В руководстве ниже подробно объясняется эта разница.

Подробное руководство: https://skills.devopscube.com/kubernetes-client-side-vs-server-side-apply/

👉 DevOps Portal

В этом кейсе показано, как WSC Sports полностью перестроила модель деплоя: от пайплайнов с helm upgrade до полноценного GitOps на базе ArgoCD ApplicationSets.

Рассматриваются:
- Архитектура монорепозитория с единым Helm-чартом;
- Теневые деплои;
- AppProjects;
- Механизмы заморозки кода в CI.

➜ https://medium.com/@elad320011/gitops-at-enterprise-scale-inside-wsc-sports-deployment-platform-5ee373431309

👉 DevOps Portal