DevOps Portal | Linux

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

Вместо tail смотри лог-файлы в реальном времени с флагом +F:

less +F hello.txt

В чём плюс? Когда выходишь из просмотра лога, экран не заливается кучей строк.

Нажмите Ctrl+C, чтобы остановить просмотр в реальном времени и перейти в обычный режим навигации less (скроллинг, поиск и т.д.).

Нажмите Shift+F, чтобы снова начать следить за файлом в реальном времени.

Нажмите q, чтобы полностью выйти из less.

Это даёт возможность гибко переключаться между статическим просмотром и live-мониторингом

👉 DevOps Portal

Бывали ли у вас ситуации, когда использовать Kubernetes — это уже перебор, но деплоить на пачку VM с самописными скриптами или Ansible-плейбуками тоже не особо хочется?

Docker Swarm может быть жив или мёртв — вопрос спорный, но сама ниша никуда не делась. И такие проекты, как Kamal (от 37signals) и Uncloud (от Паши Свидерского), пытаются её закрыть.

Если вы ещё не слышали про последний, Uncloud — это лёгкий (по сравнению с Kubernetes) инструмент для деплоя и управления контейнеризованными приложениями в сети Docker-хостов.

Антон Овчинников недавно опубликовал пошаговый гайд на iximiuz Labs, в котором показано, как развернуть кластер Uncloud на нескольких VM. Рекомендуем посмотреть:
https://labs.iximiuz.com/tutorials/uncloud-create-cluster-ebebf72b

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

👉 DevOps Portal

Let’s Encrypt начал выдавать TLS-сертификаты для IP-адресов и запустил короткоживущие 6-дневные сертификаты

Теперь можно поднимать HTTPS напрямую на IPv4/IPv6 без доменного имени – удобно для homelab, тестовых стендов, временных сервисов, внутренних бэкендов и начальной настройки серверов. Сертификаты для IP выдаются только в short-lived формате и живут 160 часов (чуть больше 6 дней)

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

Для получения нужен ACME-клиент с поддержкой профиля shortlived (например, свежий Certbot). Для IP валидация только через http-01 или tls-alpn-01 – dns-01 не поддерживается

@linuxos_tg

Что на самом деле происходит, когда вы запускаете контейнер самой типичной командой docker run nginx?

На первый взгляд кажется, что Nginx становится вашим foreground-процессом в терминале – он перехватывает stdio-потоки и реагирует на сигналы, когда вы нажимаете Ctrl+C или меняете размер окна терминала.

Но в реальности терминалом управляет процесс Docker-клиента, а сам Nginx работает в фоне или вообще на удалённой машине. При этом между docker CLI, dockerd (основным Docker-демоном) и containerd (низкоуровневым container runtime) происходит довольно сложная проксировка данных и сигналов — из-за чего всё ощущается как простой локальный запуск.

Почему это важно? Понимание того, как работает docker run под капотом — ключ к пониманию Kubernetes и других продакшн-рантаймов. В продакшене контейнеризованные приложения обычно работают в фоне, но Kubernetes и похожие системы позволяют стримить логи приложений и даже переподключаться к процессам в контейнерах, используя те же самые трюки, что и Docker.

Подробнее о магии за командой docker run — в подробном разборе (с кучей практических упражнений):
https://labs.iximiuz.com/tutorials/docker-run-vs-attach-vs-exec

👉 DevOps Portal

Откопал полезную базу по Linux / Unix от Tutorialspoint – простые и понятные объяснения без лишней воды

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

Каждая тема с примерами команд и лаконичными пояснениями

Забирайте тут

👉 DevOps Portal

Linux-совет для DevOps-инженеров

Как получить публичный IP сервера с помощью команды?

Можно использовать curl и публично доступные сервисы, чтобы получить внешний адрес, как показано на изображении.

Для AWS и GCP всегда используйте соответствующий metadata-сервис, чтобы получать публичный IP.

Примечание: не используйте публично доступные сервисы в реальном проекте или продакшн-коде. Всегда консультируйтесь с вашей командой по безопасности по доступным вариантам

👉 DevOps Portal

Этот туториал показывает, как задеплоить полноценный LGTM observability-стек (Loki, Grafana, Tempo, Mimir) с использованием OpenTelemetry в Kubernetes для единого сбора метрик, логов и трейсов

Читайте тут

👉 DevOps Portal

Аннотации в Kubernetes часто объясняют просто как метаданные

Большинство знают, что аннотации используются такими инструментами, как Prometheus или Ingress-контроллеры.

Но многие не осознают, какая мощь в них скрыта.

Аннотации не имеют фиксированной структуры – Kubernetes их не валидирует и не пытается интерпретировать. И именно поэтому они настолько мощные.

Они работают как механизм расширения Kubernetes.

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

Именно так Kubernetes эволюционирует, не ломая старые конфигурации.

Аннотации не предназначены для селекции или фильтрации – для этого есть labels.

Аннотации существуют для описания поведения и контекста, а не идентичности.

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

Аннотации не бесконечны – у них есть лимит в 256 КБ, с которым многие из вас наверняка сталкивались.

Аннотации не обязаны жить только на Pod’ах.

Одни инструменты читают их из Service, другие – из Namespace, а некоторые даже используют аннотации на Node. Механизм один и тот же, меняется только область применения.

Хороший реальный пример – Argo CD Image Updater.

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

Вся логика работы управляется через аннотации.

Никаких новых CRD.
Никаких кастомных конфигов.
Просто метаданные, которые управляют автоматизацией.

Вот разбор этого на практическом примере.

Читайте здесь: https://devopscube.com/setup-argocd-image-updater

Примечание: аннотации – это не конфигурация, это средство коммуникации.

Когда начинаешь смотреть на них именно так, многие архитектурные решения Kubernetes внезапно становятся понятными

👉 DevOps Portal

Используйте эту команду kubectl, чтобы мгновенно найти pod’ы с утечками ресурсов или чрезмерным потреблением по всему кластеру Kubernetes

👉 DevOps Portal

Kargo — это платформа непрерывной доставки и оркестрации жизненного цикла приложений для Kubernetes.

Она основана на принципах GitOps и интегрируется с Argo CD, чтобы упростить и автоматизировать поэтапный (progressive) rollout изменений на протяжении всего жизненного цикла приложения

https://github.com/akuity/kargo

👉 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

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

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

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

👉 DevOps Portal

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

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

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

👉 DevOps Portal

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

GitHub: k8s-gpu-analyzer

👉 DevOps Portal

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

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

Читать тут

👉 DevOps Portal

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

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

👉 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

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

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

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

👉 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

Kubernetes совет

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

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

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

👉 DevOps Portal