Kubernetes позволяет добавлять собственные API

В Kubernetes есть мощный механизм под названием API Aggregation Layer.

Он помогает добавлять кастомные API в кластер.

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

Классический пример использования Aggregation Layer в Kubernetes - это реализация Metrics Server.

Metrics Server реализует Metrics API как дополнительный API-сервер, используя Aggregation Layer.

Это означает, что хоть Metrics Server и является отдельным сервисом, к его API можно обращаться так, как будто он - нативная часть Kubernetes API.

В целом, поток запросов выглядит так:

- Когда вы запускаете kubectl get pods, запрос уходит на /api/v1/pods и маршрутизируется в Core API Server.

- Когда вы запускаете kubectl top pods, запрос уходит на /apis/metrics.k8s.io/v1beta1/ и маршрутизируется в Metrics Server.

Prometheus Adapter также использует этот механизм, чтобы отдавать кастомные метрики по адресу /apis/custom.metrics.k8s.io/

👉 DevOps Portal

Свежий сбой в AWS (US-EAST-1)

Самое время пересмотреть стратегии аварийного восстановления в облаке (объяснённые простым языком)

Любая стратегия Disaster Recovery начинается с определения:

🔹RTO (Recovery Time Objective) —
сколько простоя вы можете себе позволить?

🔹RPO (Recovery Point Objective) —
какую потерю данных вы готовы терпеть?

Стратегии Disaster Recovery:

1. Backup and Restore → регулярные бэкапы и восстановление после инцидента
RTO: от нескольких часов до нескольких дней, RPO: момент последнего бэкапа

2. Pilot Light → ядро системы находится в standby и разворачивается при необходимости
RTO: от минут до часов, RPO: зависит от частоты репликации

3. Warm Standby → укороченная «живая» копия среды, которую можно быстро расшscaleить
RTO: минуты, RPO: от нескольких минут до часов

4. Hot / Multi-Site → оба сайта работают активно с мгновенным фейловером
RTO: близок к нулю, RPO: секунды

👉 DevOps Portal

Уменьшили размер Docker-образа с 588 MB до 47,7 MB

Исходная сборка:

🔹Полноценный базовый образ Python 3.9
🔹Множество инструкций RUN, создающих лишние слои
🔹Отсутствие .dockerignore
🔹Одностадийная сборка со всеми зависимостями

Применённые оптимизации:

1. Более лёгкий базовый образ
- Перешли на Python 3.9-alpine
- Образ стал легче на ~95% и быстрее скачивается

2. Оптимизация слоёв
- Объединили связанные команды
- Убрали избыточные инструкции RUN

3. .dockerignore
- Исключили venv, кэши и временные файлы
- Сократили контекст сборки

4. Multi-stage build
- Отдельный stage для сборки зависимостей
- Production-stage с минимальным runtime-набором

Результат:

🔹Размер образа: 47,7 MB (с 588 MB)
🔹Снижение размера: −91,89%
🔹Более быстрый старт контейнера
🔹Меньше времени деплоя и меньше места в registry

Маленькие оптимизации дают большой эффект. Каждый сэкономленный мегабайт ускоряет каждый билд.

👉 DevOps Portal

Cовременная, легковесная дашборда для Kubernetes, которая предоставляет метрики в реальном времени, поддержку мультикластерных окружений, редактирование YAML и управление ресурсами через интуитивно понятный UI

GitHub: kite

👉 DevOps Portal

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

Логи упакованы в .gz? Их не нужно распаковывать, чтобы читать или искать по содержимому.

Используй инструменты с префиксом z прямо по месту:

zcat — просмотреть файл

zless — пролистывать содержимое

zgrep — искать внутри файла

zegrep — искать с расширенными регулярками (ERE)

zfgrep — искать по фиксированным строкам

zcmp/zdiff — сравнивать файлы

Эти команды позволяют анализировать сжатые логи без предварительной распаковки, идеально для быстрых сеансов устранения неполадок ✌️

👉 DevOps Portal

В чём разница между этими двумя DNS-запросами?

На вид они похожи, но на самом деле показывают совершенно разные вещи.

В первом случае:

— nslookup http://academy.networkchuck.com

Ты обращаешься к своему дефолтному DNS-резолверу (роутер или DNS от провайдера).
✅ Рекурсивный lookup — он пройдёт по всей цепочке CNAME до финального IP.
❌ Non-authoritative — ответ может быть из кэша и потенциально устаревшим.

Во втором случае:

— nslookup http://academy.networkchuck.com http://ns.cloudflare.com

Ты напрямую спрашиваешь авторитативный DNS-сервер.
✅ Ответ приходит прямо из первоисточника.
❌ Он покажет только то, что знает сам сервер — lookup остановится на первом CNAME.

И что же лучше? Зависит от задачи.

- Используй дефолтный резолвер, если тебе просто нужен конечный IP как можно быстрее.
- Обращайся к авторитативному серверу, если нужно проверить, кто чем реально управляет.

👉 DevOps Portal

Основы сетей - Проброс портов

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

Практика:

🔸socat: https://labs.iximiuz.com/challenges/port-forwarding-using-socat
🔸netcat: https://labs.iximiuz.com/challenges/port-forwarding-using-netcat
🔸без прокси: https://labs.iximiuz.com/challenges/port-forwarding-without-proxy

👉 DevOps Portal

Как HTTP(S)-порты пробрасываются из VM, у которых есть только приватные IP-адреса

- У каждого bare-metal хоста есть только один публичный IP-адрес

- DNS-запись *.node-xyz.iximiuz.com и wildcard-сертификат Let’s Encrypt указывают на этот IP

- Каждый раз, когда наружу пробрасывается порт VM, генерируется новый случайный поддомен

- Этот рандомный поддомен не существует за пределами конкретного хоста, он известен только соответствующему bare-metal серверу

- Все запросы к этому поддомену приходят на единственный публичный IP хоста, где слушает ingress-прокси (Envoy)

-Интерфейс VM виден только внутри её «обёртки» — Docker-контейнера (для дополнительной изоляции), поэтому Envoy не может достучаться до VM напрямую

- Вместо этого Envoy прокидывает запросы к поддомену в локальный UNIX-сокет, смонтированный в контейнер-обёртку VM

- Этот UNIX-сокет открыт специальным процессом-forwarder’ом (крошечный Go-сервис), который работает внутри контейнера-обёртки

- Forwarder делает io.Copy(UNIX socket, VM's private IP:port)

Профит! Десятки полностью изолированных VM на одном bare-metal хосте, и у каждой свой публичный URL

👉 DevOps Portal

Если вы хотите избавиться от сотен уязвимостей (CVE) в своих контейнерных образах, первым шагом будет понять, откуда они берутся

Типичные источники:

- «Толстый» базовый образ

- Забытые инструменты сборки

- Устаревшие зависимости

Простое решение? Многоэтапная сборка с более свежим и лёгким базовым образом.

Пример анализа базового образа: Более глубокий взгляд на Docker-образы Node.js: «Помогите, в моём Node-образе есть Python!»

👉 DevOps Portal

💡 Быстрый совет по Linux 🐧

Найдите недавно изменённые файлы за последние 5 минут:

find . -type f -mmin -5

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

👉 DevOps Portal

Совет по Docker

Вот как проанализировать, что раздувает образ

Как вы знаете, любой Docker-образ состоит из слоёв.
Каждый слой добавляется отдельной строкой в вашем Dockerfile.
И по этим слоям можно понять, почему образ получился большим, медленно собирается или плохо кэшируется.

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

Можно использовать утилиту dive.
Она даёт визуальное представление:

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

Когда вы начинаете анализировать слои образа, вы сможете выявить:
- Какая команда добавляет лишний вес
- Как оптимизировать Dockerfile для более маленьких и эффективных сборок

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

👉 DevOps Portal

Многие не до конца понимают, чем отличаются конвейеры CI/CD в DevOps и GitOps

В DevOps-конвейере CI/CD весь процесс выполняется единым потоком - от коммита кода, тестов, сборки, создания образа до прямого деплоя в кластер Kubernetes.

Такой подход быстрый и централизованный, но жёстко связывает деплой с процессом CI, оставляя мало возможностей для разделения или дополнительного контроля.

В GitOps-конвейере CI отвечает за тесты и сборку, а деплой выполняется через Git-коммиты: контроллер синхронизирует изменения из репозитория с кластером.

Вот инфографика, чтобы помочь вам лучше разобраться 👍

👉 DevOps Portal

Вот интересный факт о Linux

Вы можете запустить полноценное отдельное ядро Linux внутри одного процесса на своей машине. Без root-доступа и без какого-либо ПО для виртуализации.

Это User-Mode Linux (UML) - специальный порт ядра, который работает как обычное пользовательское приложение.

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

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

Хотите разобраться глубже? Ознакомьтесь с полной статьей: тык

👉 DevOps Portal

Actions Runner Controller (ARC) — это контроллер Kubernetes для self-hosted раннеров GitHub Actions.

С помощью ARC вы можете:

🔹Развертывать self-hosted раннеры в кластерах Kubernetes простым набором команд

🔹Автоматически масштабировать раннеры по требованию

GitHub: actions-runner-controller

👉 DevOps Portal

GitLab Architecture: A Complete Guide

В этом вводном гайде вы узнаете:

- Основные компоненты GitLab
- Хранилище GitLab
- Высокая доступность и масштабируемость
- Аутентификация и авторизация
- Мониторинг GitLab с помощью Prometheus и Grafana

Подробное руководство: https://devopscube.com/gitlab-architecture/

👉 DevOps Portal

Как (и зачем) использовать containerd? 🧐

containerd — вероятно, самый широко используемый контейнерный рантайм:

🔹Docker использует его под капотом для запуска контейнеров и хранения образов.

🔹Kubernetes использует его как CRI-рантайм для запуска Pod'ов.

Практикуйтесь в работе с containerd: https://labs.iximiuz.com/courses/containerd-cli

👉 DevOps Portal

Это CSI-драйвер для хранилищ S3 (или совместимых с S3)

Этот инструмент может динамически создавать (выделять) бакеты и монтировать их в любой контейнер через FUSE-маунт

GitHub: k8s-csi-s3

👉 DevOps Portal

Большинство инженеров DevOps сосредоточены на автоматизации

Но, DevOps сегодня - это гораздо больше, чем просто CI/CD-пайплайны.

Это также про понимание того, как на самом деле работают системы и как проектировать их так, чтобы они выдерживали сбои.

В этом контексте есть одна концепция, которую должен знать каждый инженер DevOps: Write-Ahead Log (WAL), или «журнал предварительной записи».

Вот короткий пост, где объясняют, как работает WAL, с простыми примерами из реальной практики. Прочитать можно здесь: https://newsletter.devopscube.com/p/write-ahead-log-wal

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

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

👉 DevOps Portal

Бесплатный лайфхак для Linux 😎

Многие про это не знают или почти не пользуются.

В Linux можно сделать файл или каталог неудаляемым с помощью команды chattr, установив флаг +i:

sudo chattr +i -V CH-13.pdf

Флаг +i запрещает удалять, изменять и переименовывать файл, даже root не сможет этого сделать, пока флаг не снят.
Опция -V включает подробный вывод (verbose), чтобы увидеть, что именно команда делает.

Чтобы вернуть всё обратно:

sudo chattr -i CH-13.pdf

👉 DevOps Portal

Dockly

Это интерактивный терминальный интерфейс для управления контейнерами Docker.

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

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

GitHub: dockly

👉 DevOps Portal