Этот кейс показывает, как мигрировать с хрупкой инфраструктуры на базе EC2 на AWS EKS с GitOps через ArgoCD, Jenkins и SonarQube для платформы сокращения ссылок

В результате деплои ускорились на 80%, а инфраструктура получила возможность самовосстановления

➜ https://medium.com/@chi.naedu/from-fragile-vms-to-bulletproof-gitops-modernizing-a-devops-platform-on-aws-eks-81db558cb7d4

👉 DevOps Portal

Docker 101: пробрасываем порт контейнера, чтобы открыть приложение с хоста

Новое практическое задание: веб-приложение запущено внутри контейнера, но браузер не может достучаться до него по IP-адресу. Пересоздайте контейнер так, чтобы приложение было доступно на 80-м порту хоста:
https://labs.iximiuz.com/challenges/docker-101-container-publish-port

👉 DevOps Portal

Архитектура Argo CD: разбор

К концу этого материала вы:

Поймёте, как Argo CD реально работает под капотом.

Внутри:

- Ключевые компоненты и их фактические роли
- Как они взаимодействуют между собой и синхронизируют изменения
- Как Argo CD хранит данные и как правильно настраивать бэкапы
- Как запускать Argo CD в режиме высокой доступности
- Безопасность и мониторинг (Prometheus + Grafana)

и многое другое…

Подробный гайд: https://devopscube.com/argo-cd-architecture

👉 DevOps Portal

В этой статье объясняется, почему 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

Что будет, если убрать репликацию с диска?☁️

В K2 Cloud проверили и запустили сетевые нереплицируемые NVMe-диски, одни из самых быстрых в РФ. Диск не хранит копии данных, поэтому вся его мощность работает на скорость.

20 октября на онлайн-митапе ребята покажут, где рождается скорость, как устроен такой диск внутри и как не уронить систему при отказе.

Участие бесплатное. Подробности и регистрация по ссылке.

Как работает 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

💻Практический вебинар «СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ»

📹 15 октября в 11:00 Мск за 90 минут на практике построим реальную стратегию и разберём:

🔹 как определить RPO и RTO для критичных сервисов;
🔹 как защитить бэкапы от шифровальщика;
🔹 как учесть зависимости систем и ресурсы для восстановления;
🔹 как каналы связи влияют на скорость бэкапа и восстановления;
🔹 когда достаточно обычных бэкапов, а когда нужны репликация, Hardened Repository и DRaaS;
🔹 как подготовить план аварийного восстановления и протестировать его.

🧑‍💻 Каждый участник выберет свой критичный сервис и проработает его

🎁 Всем прошедшим практикум передадим методику и пакет документов для реализации стратегии резервного копирования и восстановления:
— Матрица систем и зависимостей
— Таблица определения и согласования RPO / RTO
— Технический runbook аварийного восстановления
— Отчёт о тестовом восстановлении ИТ-сервиса
— Карта готовности одного критичного сервиса к восстановлению
— Рабочая тетрадь «Стратегия восстановления данных и ИТ-сервисов»

👉 Приходите, будет полезно. Регистрация тут

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

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

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

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

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

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

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

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

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

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

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

👉 DevOps Portal