Запутались, когда использовать Kubernetes Operators, а когда Helm? Это для вас.

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

Kubernetes Operator: обеспечивает расширенное управление за счёт автоматизации, учитывающей жизненный цикл, для сложных приложений

Helm: упрощает деплой приложений с помощью готовых шаблонов, называемых chart’ами, и идеально подходит для настройки простых, воспроизводимых окружений

👉 DevOps Portal

В этом репозитории вы найдёте роадмап для изучения Kubernetes с нуля (от уровня новичка до продвинутого).

Внутри много ссылок на курсы, статьи, материалы по теме

Забираем на GitHub

👉 DevOps Portal

Знаете ли вы?

SSH-сессии не исчезают, когда вы отключаетесь.

Пути:

/var/log/wtmp — история входов

/var/log/btmp — неудачные попытки входа

/var/log/lastlog — последний вход

Что могут увидеть специалисты по цифровой криминалистике:

- успешные логины;

- неудачные brute-force попытки;

- исходные IP-адреса;

- длительность сессий;

-какая учётная запись использовалась.

Вы отключились. Linux сохранил журнал посещений.

👉 DevOps Portal

Учимся сетям на практике

Вот пример сложной сетевой топологии, которую можно развернуть в playground от iximiuz Labs, где узлы – это реальные виртуальные машины, соединённые с произвольным количеством сетевых бриджей.

Пора поработать руками:
https://labs.iximiuz.com/playgrounds/flexbox

👉 DevOps Portal

Когда-нибудь задумывались, как Kubernetes-сервисы обрабатывают балансировку нагрузки?

Вот как это работает.

По умолчанию компонент kube-proxy в Kubernetes использует iptables для маршрутизации запросов (также поддерживается IPVS).

В iptables есть функция, называемая statistic mode random probability.

Эта функция является частью iptables и используется для фильтрации пакетов и NAT. Она позволяет создавать правила, которые случайным образом матчят определённый процент пакетов.

Например, мы протестировали endpoint сервиса, указывающий на деплоймент из трёх подов.

Он показал значение statistic mode random probability = 0.33, что по сути распределяет трафик между тремя подами.

Это скорее вероятностное распределение трафика, а не полноценная балансировка нагрузки.

- Оно не учитывает фактическую нагрузку на серверы.
- Не гарантирует равномерное распределение трафика во времени.
- Не поддерживает session persistence (липкие сессии)

👉 DevOps Portal

Нашёл максимально залипательный способ прокачать system design и облачную архитектуру – игра Server Survival

Это 3D tower defense, где вы играете за облачного архитектора: строите инфраструктуру, раскидываете файрволы, балансировщики, сторэджи, отбиваетесь от дудоса, следите за бюджетом и здоровьем сервисов.

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

И да, проект опенсорс, код на GitHub

@IT_Portal

Самый распространённый способ запустить контейнер — использовать Docker CLI. Но что именно делает команда docker run? Чем она отличается от:

🔹 podman run

🔹 nerdctl run

🔹 ctr run

🔹 runc create/start

Мини-курс, чтобы научиться запускать контейнеры с разными рантаймами:
https://labs.iximiuz.com/skill-paths/run-containers-across-runtimes

👉 DevOps Portal

Репозиторий для изучения Prometheus и понимания, зачем и где его использовать

https://github.com/acend/prometheus-training

👉 DevOps Portal

Тормозят Docker-сборки? Используй мощь build cache

Build cache переиспользует слои образа и метаданные, чтобы ускорить сборку. Когда ты пересобираешь образ без изменений или с минимальными изменениями, билдер повторно использует результаты предыдущей сборки.

На картиинке наглядный пример того, как build cache работает между сборками

Если хочешь ускорить сборки, в этом туториале разобраны ключевые концепции и практики, которые помогают выжать максимум из кэша:
https://depot.dev/blog/ultimate-guide-to-docker-build-cache

👉 DevOps Portal

Kubernetes совет

Удалить все поды в неймспейсе

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

Сделать это можно с помощью флага --all

👉 DevOps Portal

Большинство людей сразу прыгают в Prometheus и Grafana, не понимая, какую именно задачу они на самом деле решают.

Я постоянно вижу это на собеседованиях. Человек говорит: «Мы используем Prometheus для мониторинга», но при этом не может объяснить, почему логи и метрики требуют разных пайплайнов, или что вообще происходит, когда CloudWatch перестаёт справляться на масштабе.

В observability вы решаете две принципиально разные проблемы.

Логи отвечают на вопрос "что произошло". Произошла ошибка. Пришёл запрос. Упал запрос к базе данных.
Это события - истории, которые рассказывает ваше приложение.

Метрики отвечают на вопрос "как система чувствует себя прямо сейчас". Латентность 200 мс. CPU 75%. 500 запросов в минуту. Это измерения.

Разные типы данных. Разные способы сбора. Разное хранение. И именно здесь большинство людей путается.

В прошлом месяце на моём DevOps-буткемпе мы собрали полноценную систему observability для микросервисов в Kubernetes.

Логи

Для логов мы использовали Fluentd sidecar-контейнеры, которые шарят volume с основным контейнером приложения:
- приложение пишет логи в volume;
- Fluentd читает их и отправляет дальше;
- чёткое разделение ответственности;
- на небольшом масштабе логи просто улетают напрямую в CloudWatch.

Но когда у вас тысячи строк логов в секунду, приходится добавлять слои:
- Lambda для форматирования.
- Kinesis для буферизации.
- OpenSearch для быстрых запросов по петабайтам данных.
- S3 для долгосрочного бэкапа.

Мы держали 7 дней в OpenSearch для активных расследований. 30 дней — в CloudWatch. Годы — в S3 для комплаенса. У каждого слоя разные характеристики по цене и производительности.

Метрики

Для метрик Prometheus скрейпит application endpoints каждые 30 секунд:
- разработчики инструментируют код клиентскими библиотеками Prometheus;
- экспонируют /metrics endpoint;
- Prometheus сам подтягивает данные.

Мы создали ServiceMonitor’ы, которые говорят Prometheus, какие pod’ы скрейпить на основе label’ов:
- Как только поднимаются новые pod’ы, Prometheus их обнаруживает и начинает скрейпить.
- Дальше Grafana визуализирует всё это.
- Мы импортировали готовые дашборды с grafana.com для мониторинга Kubernetes.
- И также собрали кастомные панели под метрики конкретного приложения.

Логи и метрики идут параллельно.

Когда что-то ломается, метрики показывают вам всплеск: error rate подпрыгнул в PM. Латентность выросла со 100 мс до 2 секунд.

Дальше вы идёте в логи: фильтруете по тому же окну времени, находите stack trace’ы и видите, что именно упало.

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

Мы всё это реализовали и оттраблшутали в лайв-созвоне: нагенерили метрики и логи и собрали дашборды в Grafana

Прочитать подробный пост можно здесь: https://open.substack.com/pub/akhileshmishra/p/youre-not-ready-for-kubernetes-observability

👉 DevOps Portal

How-To: как собрать eBPF-фаервол, который фильтрует пакеты по диапазонам IP

В большинстве туториалов показывают, как заблокировать один конкретный IP-адрес. Но в реальном мире (Kubernetes, автоскейлинг нод, короткоживущие ворклоады, managed-сервисы и т. п.) IP-адреса постоянно меняются, поэтому на практике имеет смысл работать именно с CIDR-диапазонами.

В этой статье вы узнаете, как правильно блокировать целые подсети:
https://labs.iximiuz.com/tutorials/ebpf-firewall-ed03d648

👉 DevOps Portal

Простой способ создавать свои DevOps-лабы

Примерно год iximiuz Labs поддерживает создание кастомных плейграундов: вы выбираете стандартную базу (Ubuntu-VM, Docker-хост, Kubernetes-кластер и т.д.) и донастраиваете её под свои задачи с помощью скриптов, похожих на cloud-init.

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

- Init-скрипты запускаются при каждом старте плейграундов, увеличивая time-to-prompt, иногда весьма существенно
- Некоторые задачи провижининга гораздо проще решать запуском shell-команд вручную (попутно чиня упавшие шаги)
- Некоторые "случайные" состояния VM имеет смысл сохранить как переиспользуемые кастомные плейграунды (но задним числом заскриптовать их уже нельзя)

К счастью, с появлением "persistent playgrounds" в ноябре стало возможным сохранять остановленный плейграунд как кастомный. При этом результат ничем не отличается от любого другого плейграунда: вы получаете read-only шаблон, который можно перезапускать сколько угодно раз, делиться им с другими или встраивать в туториалы, челленджи и уроки курсов. Магия 🧙

Попробуйте сами: http://labs.iximiuz.com/playgrounds

👉 DevOps Portal

Мини-курс по containerd обновлён и переведён на недавно вышедшую версию containerd 2.2.1. Если нужно глубже разобраться, как контейнеры управляются низкоуровневыми рантаймами (тем самым слоем под Docker или Kubernetes), это хорошая отправная точка

https://labs.iximiuz.com/courses/containerd-cli

👉 DevOps Portal

Как установить и настроить kubectl на Linux

kubectl - это CLI-инструмент для взаимодействия с кластерами Kubernetes. Независимо от того, управляете ли вы контейнерами, деплоите приложения или устраняете проблемы в кластере, kubectl является вашим основным интерфейсом для работы с API-сервером K8s.

Читать тут

👉 DevOps Portal

Это инструмент на Golang, который анализирует распределение и использование GPU-ресурсов в кластерах Kubernetes, снижая нагрузку на API-server примерно до ~75 %, при этом предоставляя наглядную статистику использования по каждому node и pod

GitHub: k8s-gpu-analyzer

👉 DevOps Portal

Отладка контейнеров 101: как выполнять команды хоста внутри уже запущенного контейнера

Хорошие контейнерные образы должны содержать только те пакеты, которые необходимы приложению для работы в продакшене. Но что делать, если такой идеальный минималистичный контейнер начинает вести себя некорректно?

https://labs.iximiuz.com/challenges/docker-container-execute-commands-with-nsenter

👉 DevOps Portal

Все знают, что балансировщики нагрузки на eBPF превосходят user-space LB, потому что они избегают копирования пакетов и переключений контекста.

Но вот малоизвестный факт: ты можешь написать собственный eBPF-балансировщик, с выбором бэкенда и session affinity, всего в 200 строках на C.

Теодор снова это доказывает:
https://labs.iximiuz.com/tutorials/xdp-load-balancer-700a1d74

👉 DevOps Portal

Kubernetes Gateway API постепенно вытесняет кастомные API маршрутизации, используемые в service mesh

В материале разобрано, что такое GAMMA и как он работает

Опубликован подробный практический гайд, в котором ключевые концепции объясняются на наглядных примерах и иллюстрациях.

Что рассматривается в гайде:

- что из себя представляет подход GAMMA
- как он отделяет логику маршрутизации от реализации mesh
- реализация canary-деплоев с использованием GAMMA
- использование HTTPRoute совместно с DestinationRule в Istio
- production-кейс применения подхода GAMMA

Полный гайд:
https://devopscube.com/gateway-api-for-service-mesh/

Несмотря на то, что API VirtualService и DestinationRule в Istio по-прежнему широко используются,
GAMMA предлагает вендорно-независимый подход.

Это означает отсутствие жёсткой привязки к Istio-специфичным API, таким как VirtualService и DestinationRule.

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

👉 DevOps Portal