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

Изучение 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.