В этом туториале показано, как разворачивать и масштабировать большие языковые модели (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

Изучение Linux через устранение неполадок на серверах

Подборка практических сценариев по диагностике и устранению проблем, которые помогут прокачать навыки работы с Linux:

- Демон отправки логов, который не запускается — https://labs.iximiuz.com/challenges/linux-strace-failing-daemon
- Демон конвертации изображений с отсутствующими зависимостями — https://labs.iximiuz.com/challenges/linux-missing-shared-library
- Воркер-сервис, который постоянно исчезает — https://labs.iximiuz.com/challenges/linux-debug-vanishing-worker-service
- Несколько сервисов разработки, конфликтующих из-за одного порта — https://labs.iximiuz.com/challenges/linux-resolve-port-conflict
- Привилегированный демон с некорректно настроенным контролем доступа — https://labs.iximiuz.com/challenges/linux-restrict-unix-socket-access

Удачного хакинга!

👉 DevOps Portal

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

Окружения для разработки и тестирования часто работают 24/7, даже когда ими никто не пользуется.

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

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

Здесь на помощь приходит kube-green.

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

Что умеет kube-green 👇
- Масштабирует Deployments и StatefulSets до нуля на время простоя.
- Приостанавливает CronJobs на ночь.
- Восстанавливает рабочие нагрузки по заданному расписанию.
- Поддерживает настройку по дням недели и часовым поясам.
- Позволяет исключать отдельные ресурсы по именам или меткам.
- Поддерживает кастомные ресурсы через патчи.

С чего начать: GitHub

Примечание: масштабирование подов до нуля позволяет экономить только в том случае, если неиспользуемые ноды также масштабируются вниз. Чтобы действительно сократить расходы на инфраструктуру, используйте kube-green вместе с Cluster Autoscaler или Karpenter.

👉 DevOps Portal

Сетевые основы 101: Как работает маршрутизация трафика

Знаете ли вы, что компьютеры могут обмениваться данными только с соседями (участниками одной подсети)? Но как тогда мы передаём пакеты через Интернет? Именно здесь вступает в игру маршрутизация.

Узнайте больше: https://labs.iximiuz.com/challenges/networking-configure-basic-routing

👉 DevOps Portal

В этом туториале показано, как развернуть мультитенантную платформу Apache Spark в Kubernetes с использованием Spark Operator, Volcano, Helm, Airflow, общих образов, ограничений на рабочие нагрузки и мониторинга.

➜ https://medium.com/towards-data-engineering/building-a-production-grade-apache-spark-platform-on-kubernetes-2984e083dd71

👉 DevOps Portal

ИИ-агенты для DevOps-инженеров: объяснение принципов работы

ИИ-агенты становятся важной частью DevOps и платформенной инженерии.

Но прежде чем создавать собственного агента, необходимо разобраться, что именно делает приложение агентом.
В отличие от традиционного приложения, которое следует фиксированному набору инструкций, ИИ-агент может самостоятельно решать, что делать дальше, на основе полученной информации.

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

Начать изучение: https://newsletter.devopscube.com/p/ai-agents-part01

👉 DevOps Portal

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

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

Ситуация усложняется, когда у приложения несколько реплик.

Здесь на помощь приходит Kubetail — опенсорсный дашборд для просмотра логов Kubernetes в реальном времени, который позволяет собирать логи нескольких подов в одном интерфейсе.

Основные возможности:
• Просмотр логов нескольких подов и контейнеров в одном месте.
• Автоматическое обновление временной шкалы при запуске, остановке или замене подов.
• Фильтрация логов по временному диапазону, зоне доступности, архитектуре CPU или ноде.
• Переключение между несколькими кластерами через десктопное приложение.

Начать работу: GitHub

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

Вместо постоянного переключения между терминалами можно отслеживать происходящее в подах приложения через единый интерфейс.

👉 DevOps Portal

Подготовлены две новые практические задачи для освоения сетевого взаимодействия контейнеров:

Лёгкая: перенаправить запросы контейнера без изменения кода приложения — https://labs.iximiuz.com/challenges/docker-networking-redirect-app-to-request-sink

Сложная: перехватить и проанализировать зашифрованный трафик подозрительного контейнера — https://labs.iximiuz.com/challenges/docker-networking-intercept-encrypted-traffic

Удачного хакинга!

👉 DevOps Portal

В этом кейсе рассказывается, как платёжная компания перестроила процесс деплоя на Kubernetes, внедрив GitOps с Argo CD. Теперь каждое изменение в продакшене оформляется в виде Git-коммита, который проходит код-ревью, а подготовка к аудитам PCI перестаёт быть гаданием.

➤ https://dodopayments.com/engineering/deployment-pipeline-gitops-argocd-kubernetes

👉 DevOps Portal

31 октября AvitoTech собирает инфраструктурных инженеров на Avito Infraween Party 🤩

Вместо классических докладов — два круга открытых дискуссий: можно будет обсудить инфраструктурные задачи, поделиться своими кейсами и поспорить о решениях с экспертами AvitoTech и другими участниками.

А на афтерпати устроят настоящий чемпионат по метанию старой списанной техники 🔥

Победителей наградят реальными чемпионскими поясами!

Хороший повод пообщаться с инфракомьюнити — зарегаться можно тут!

P. S. Кстати, костюмы максимально приветствуются! Так что если хотите прийти в образе, welcome.

Fluentd vs Fluent Bit: что выбрать для Kubernetes?

Краткое сравнение 👇

Fluentd:
- Полноценный инструмент для обработки логов.
- Написан на Ruby (с расширениями на C).
- Справляется с высокими нагрузками и сложной маршрутизацией логов.
- Лучше всего подходит для централизованного сбора и обработки логов.
- Потребляет больше ресурсов (CPU и памяти).

Используйте Fluentd, если вам нужны продвинутые возможности фильтрации, парсинга и маршрутизации логов в больших масштабах.

Fluent Bit:
- Легковесный инструмент для пересылки логов.
- Написан на C (высокая производительность и минимальное потребление ресурсов).
- Отлично подходит для периферийных узлов, DaemonSet в Kubernetes и встраиваемых систем.
- Обычно используется для сбора и отправки логов во Fluentd, Elasticsearch или другие бэкенды.
- Оптимизирован для высокой производительности и низкого потребления ресурсов.

Используйте Fluent Bit, если вам нужен максимально легковесный сборщик логов, который не создаёт дополнительной нагрузки на узлы.

Примечание: оба инструмента имеют статус Graduated-проектов CNCF и широко используются в продакшене.

Хотите разобраться, как устроено логирование в Kubernetes?

Читайте здесь: https://devopscube.com/kubernetes-logging-tutorial/

👉 DevOps Portal

В этом туториале показано, как мигрировать кластер EKS с выведенного из эксплуатации контроллера ingress-nginx на Gateway API. Разбираются CRD контроллера AWS Load Balancer Controller и переключение трафика без простоя (zero-downtime).

➜ https://medium.com/@douglas0n/migrating-from-ingress-nginx-to-gateway-api-on-eks-0a514952e91b

👉 DevOps Portal