Linux для контейнеров: network namespaces

Network namespaces позволяют Docker и Kubernetes создавать для приложений иллюзию, что они работают в отдельном сетевом окружении: с изолированным набором сетевых устройств, IP-адресов, правил роутинга и т.д.

Разберитесь, как работают netns: https://labs.iximiuz.com/challenges/linux-network-namespace

👉 DevOps Portal

Быстрый Linux-совет

Нужен только один столбец из файла?

Выполните:

cut -d',' -f2 ~/Desktop/members.csv

Команда cut извлекает из текстовых файлов указанные поля или символы.

👉 DevOps Portal

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

https://github.com/ctrox/zeropod

👉 DevOps Portal

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

При работе с Kubernetes возможности eBPF позволяют видеть каждый системный вызов (syscall) и каждый сетевой пакет на уровне ядра Linux. Но сама по себе эта информация не отвечает на главный вопрос: какому Pod, контейнеру или Namespace принадлежит событие?

Именно эту проблему решает Inspektor Gadget — open-source инструмент для диагностики и отладки Kubernetes-кластеров и Linux-хостов на базе eBPF.

Он автоматически связывает события ядра с объектами Kubernetes, что значительно упрощает поиск проблем. Что умеет Inspektor Gadget?

В режиме реального времени отслеживает:
• DNS-запросы;
• TCP-соединения;
• открытие файлов;
• запуск процессов внутри контейнеров.

Захватывает сетевые пакеты внутри любого контейнера с использованием фильтров в стиле tcpdump (pcap).

Позволяет мгновенно обнаруживать:
• OOM Kill;
• потерю TCP-пакетов;
• TCP Retransmissions;
• другие проблемы на уровне ядра.

Фильтрует события по имени Pod или контейнера, причём фильтрация выполняется непосредственно в ядре, что минимизирует накладные расходы.

Помогает автоматически генерировать:
• Seccomp Profiles;
• Kubernetes NetworkPolicies
• на основе реального поведения приложений во время выполнения.

Важно: Inspektor Gadget запускается как privileged DaemonSet, поскольку eBPF требует доступа к ядру Linux. Для многопользовательских кластеров рекомендуется использовать встроенные механизмы ограничения запуска отдельных gadgets.

GitHub: https://github.com/inspektor-gadget/inspektor-gadget

👉 DevOps Portal

У небольших команд GPU-запросы очень прикладные:

прогнать модель, ускорить рендер, обработать тяжелые данные. Дальше DevOps раскладывает задачу на рабочие параметры — модель GPU, количество карт на сервер, срок запуска, питание, SLA, формат доступа к ресурсу.

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

Из свежего, и пока мало кто в курсе — Московский кластер видеоигр и анимации начал сдавать в аренду выделенные GPU. Посмотрел, что там по конфигурации 👇

Из карт — H100 и RTX Ada 5000/6000, от 1 до 8 GPU на сервер, ресурс закрепляется за арендатором. Закрывает AI/ML, LLM, inference, 3D/Render, VDI.

Если нужен не отдельный GPU-сервер, а колокейшн — там же от 1U до полной стойки 42U на 10 кВт (можно расширить до 20), два независимых ввода питания на стойку.

Цены конкурируют с коммерческими ЦОДами — площадку субсидирует город.

👉 DevOps Portal

Нативные sidecar-контейнеры в Kubernetes

Sidecar — это вспомогательный процесс, который запускается рядом с основным приложением. Такой паттерн удобен, когда дополнительную функциональность лучше подключить отдельно: например, сетевой прокси, сборщик и отправщик логов, коллектор метрик или агент, который загружает секреты.

Основная сложность - правильно управлять жизненным циклом sidecar-контейнера: он должен запускаться раньше приложения, продолжать работать вместе с ним, перезапускаться при неожиданном завершении и останавливаться только после завершения самого приложения.

Раньше для реализации паттерна sidecar приходилось писать собственные скрипты, но нативная поддержка sidecar-контейнеров в Kubernetes через init-контейнеры с restartPolicy: Always заметно упростила этот процесс.

В этом практическом туториале рассказывают, как работают нативные sidecar-контейнеры в Kubernetes, чем они отличаются от обычных и init-контейнеров, а также как попрактиковаться в их использовании на нескольких реалистичных сценариях:
https://labs.iximiuz.com/tutorials/kubernetes-native-sidecars

👉 DevOps Portal

Большинство инструментов безопасности для Kubernetes лишь уведомляют о проблеме уже после того, как она произошла.

KubeArmor работает иначе.

Это опенсорсный инструмент безопасности, который на уровне ядра контролирует, какие процессы могут запускаться, к каким файлам можно обращаться и какие сетевые запросы разрешены внутри ворклоадов.

Вместо простого алерта он блокирует действие ещё до его выполнения.

Что умеет KubeArmor

— Блокирует неожиданный запуск процессов или доступ к файлам внутри пода ещё до того, как это произойдёт.
— Применяет принцип минимально необходимых прав с помощью вайтлистинга процессов и сетевых подключений для каждого ворклоада.
— Ограничивает доступ к чувствительным путям, например к бандлам сертификатов и секретам, чтобы их нельзя было прочитать или изменить.
— Применяет политики харденинга, сопоставленные с MITRE, CIS и STIG, без необходимости писать их самостоятельно.
— Обеспечивает детальную видимость происходящего в рантайме с помощью eBPF, включая информацию о подах, контейнерах и неймспейсах.

https://github.com/kubearmor/KubeArmor

👉 DevOps Portal

Создаём контейнер наподобие Docker с нуля

Освойте ключевые пространства имён Linux, собрав небольшой, но реалистичный контейнер, используя только штатные команды Linux: unshare, mount и pivot_root. Никакой магии рантайма и (почти) никаких упрощений.

Изучаем здесь

👉 DevOps Portal

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

Инструмент распространяется в виде одного бинарника, напрямую подключается к Kubernetes API и не требует установки компонентов внутри кластера.

➜ https://github.com/skyhook-io/radar

👉 DevOps Portal

Большинство пользователей Kubernetes до сих пор не знают о существовании этого типа томов

Он называется ImageVolume.

Вот как он работает

Функция Image Volume позволяет использовать OCI-образы в качестве томов непосредственно внутри Pod’ов Kubernetes.

Что такое OCI-образы?

Это стандартизированный формат, который определяет структуру контейнерных образов.

С помощью ImageVolume можно хранить в образах файлы моделей, бинарные файлы, конфигурации и другие данные, а затем монтировать их в Pod’ы.

Вот практическое руководство, в котором показано, как работает эта функция и как её использовать.

Полезная возможность, о которой стоит знать.

https://devopscube.com/oci-image-volume-kubernetes-pods/

Примечание: ImageVolume подходит для любых workload’ов, которым удобно поставлять данные внутри образа: файлы моделей, датасеты, конфигурации, статические ресурсы и даже инструменты.

👉 DevOps Portal

Как работает сетевая подсистема контейнеров

Большинство Docker-инсталляций и Kubernetes-кластеров используют одинаковую схему сетей на основе мостов. Как лучше всего разобраться, как это устроено?

Попробуйте воссоздать такую сетевую конфигурацию с нуля, используя только стандартные Linux-команды: https://labs.iximiuz.com/tutorials/container-networking-from-scratch

👉 DevOps Portal

В этом руководстве показано, как построить SaaS-архитектуру с отдельным окружением для каждого пользователя в EKS Auto Mode: один pod, один поддомен и один persistent volume на пользователя, wildcard TLS и общий ALB.

➜ Читайте тут

👉 DevOps Portal

Компьютерные сети 101: сокеты

Лучший способ понять, что такое сокеты и как они работают - написать несколько простых клиент-серверных программ. Хорошая новость: для этого достаточно нескольких строк на Python или Go. А если хочется испытать себя, попробуйте C - кода будет больше, зато вы окажетесь максимально близко к реальному системному API.

Несколько задач для практики в безопасном и контролируемом окружении с полезными подсказками:

— Написать простой TCP Echo-сервер
https://labs.iximiuz.com/challenges/write-tcp-echo-server

— Задача попроще: написать клиент для сервера телеметрии
https://labs.iximiuz.com/challenges/write-tcp-client-for-telemetry-server

— Задача посложнее: написать клиент для чат-сервера
https://labs.iximiuz.com/challenges/write-tcp-client-for-chat-server

— Сделать сервер, который работает и с TCP-, и с Unix-сокетами
https://labs.iximiuz.com/challenges/write-stream-echo-server

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

👉 DevOps Portal

Linux 101: монтируем диск с уже записанными данными и читаем его содержимое

Практика по работе с накопителями в Linux:

1. Найти неподключённый диск
2. Примонтировать его к директории в корневой файловой системе
3. Найти флаг на примонтированном диске

Практическое задание: https://labs.iximiuz.com/challenges/storage-simple-mount

👉 DevOps Portal

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

https://github.com/philippemerle/Awesome-Kubernetes-Architecture-Diagrams

👉 DevOps Portal

Небольшой совет по Linux

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

$ mkdir project
$ cd project

Эти два шага можно объединить в одну команду:

$ mkdir app && cd $_

Переменная $_ разворачивается в последний аргумент предыдущей команды, которым в данном случае является app.

Небольшой трюк, который позволяет сэкономить несколько нажатий клавиш при работе в терминале

👉 DevOps Portal

Прокачайте навыки работы с Kubernetes на реалистичных сценариях:

Создать собственный PriorityClass и назначить его рабочей нагрузке
https://labs.iximiuz.com/challenges/create-and-assign-a-custom-priorityclass-to-a-workload-b3699c08

Расширить кластер дополнительным диапазоном Service CIDR для команды разработки
https://labs.iximiuz.com/challenges/extend-the-cluster-with-an-additional-service-cidr-for-the-dev-team-5251bc66

Включить отдельные DNS-записи для каждого Pod в Deployment
https://labs.iximiuz.com/challenges/enable-per-pod-dns-records-for-deployment-1c6a4201

Разобраться, почему Pod’ы приложения-календаря со списком задач зависли в состоянии Pending
https://labs.iximiuz.com/challenges/troubleshoot-why-the-calendar-todo-app-pods-are-stuck-in-pending-9f571aa2

Повторно подключить сохранённый PV с помощью нового PVC и восстановить потерянную базу данных MariaDB
https://labs.iximiuz.com/challenges/reclaim-retained-pv-with-new-pvc-and-restore-lost-mariadb-database-783fe3ae

Настроить обязательное использование TLS для продакшен-Deployment с Nginx
https://labs.iximiuz.com/challenges/enforce-tls-policy-on-production-nginx-deployment-a9190dec

Подключить конфигурационный файл, не перезаписывая существующую директорию из образа
https://labs.iximiuz.com/challenges/inject-configmap-file-without-overwriting-existing-directory-23bcc10e

Закрепить клиента за одним и тем же Pod с помощью Session Affinity в Service
https://labs.iximiuz.com/challenges/pin-a-client-to-the-same-pod-using-service-session-affinity-6b19b89f

Настроить Health Probes и корректное завершение работы для Kubernetes Deployment
https://labs.iximiuz.com/challenges/configure-health-probes-and-graceful-shutdown-kubernetes-deployment-90e57daa

👉 DevOps Portal

Как собрать мультиплатформенный контейнерный образ из отдельных одноплатформенных сборок?

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

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

Разобраться в магии этого процесса можно здесь:
https://labs.iximiuz.com/challenges/docker-push-multi-platform-image

👉 DevOps Portal

В качестве движка выполнения пайплайнов Kubeflow Pipelines использует Argo Workflows.

Это Kubernetes-native движок оркестрации DAG.

Что именно это означает?

DAG (Directed Acyclic Graph, направленный ациклический граф) описывает задачи и зависимости между ними.

Например:

- Сначала выполняется задача A
- После A запускаются задачи B и C
- Задача D запускается только после завершения B и C

Самое интересное — как Argo выполняет эти задачи.

В большинстве инструментов DAG описываются на Python.

В Argo DAG задаётся декларативно в YAML в виде CRD, а каждую задачу Argo выполняет как отдельный Kubernetes Pod.

Kubeflow использует Argo Workflows в качестве бэкенда и добавляет поверх него слой для задач AI/ML.

При работе с Kubeflow Pipelines вместо того, чтобы напрямую писать YAML-манифесты Argo Workflow, пайплайны нужно описывать в виде DAG на Python.

Для ML-команд это значительно удобнее, чем поддерживать сотни строк YAML с Kubernetes CRD.

Kubeflow SDK компилирует описание пайплайна на Python в YAML в формате Intermediate Representation (IR).

Затем оно преобразуется в специфичное для Argo описание и передаётся на выполнение.

👉 DevOps Portal