Что почитать, чтобы отвлечься от ваших кластеров

Подборка для длинных выходных

➡️ Brendan Gregg's Website
Это просто кладезь знаний от человека, который посвятил себя оптимизации Linux. Он не просто рассказывает, что делать, а объясняет, почему и как это работает. Его инструменты — мастхэв для тех, кто хочет копаться в системе на уровне ядра и видеть, где у нее узкие места.

➡️ Systems Performance, 2nd Edition
Это как Библия для системного администратора. Всё, что нужно знать про тюнинг под высокие нагрузки, — от анализа I/O до оптимизации памяти, — тут есть. Книга толстая, но она того стоит, если хотите понимать, как система работает, а не просто тыкать наугад, когда нужно вытянуть перформанс.

➡️ Joel Spolsky's Blog
Особенно обратите внимание на «The Law of Leaky Abstractions». Он объясняет, почему важно понимать, что происходит «под капотом», даже если вы используете самые крутые фреймворки. Он основал Stack Overflow и, наверное, что-то понимает в IT.

➡️ «Awesome Falsehood»
Это просто must-read для любого инженера. Список всех самых распространенных заблуждений, которые только можно себе представить. Почитайте, чтобы не наступать на те же грабли, что и все остальные. На Хабре, кстати, есть переводы на русский – «Заблуждения программистов о времени» и «о картах» — чтобы было понятнее, о чем речь.

➡️ «Wat» Talk
А это чтобы немного расслабиться и понять, что мир неидеален. Знаменитая лекция про странности Ruby и JavaScript. Помогает не воспринимать баги слишком серьезно и вообще немного философски относиться к разработке.

Уроки Google

Вчерашний масштабный сбой в Google Cloud, наряду с инцидентом в Cloudflare, а также недавний пример с падением Yandex Cloud, стали очередным напоминанием о важности диверсификации в построении современных систем.

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

➡️Пример Cloudflare

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

🟠Географически распределять нагрузку, что снижает риск одновременного выхода из строя всех серверов.
🟠Быть ближе к пользователю, что улучшает скорость доступа к контенту.
🟠Избегать монополизации, что снижает зависимость от одного поставщика услуг.

Казалось бы, идеальная стратегия диверсификации! Но…

Привет, я Google Cloud и сегодня я упал.

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

➡️Мораль истории

🟠Диверсификация - это хорошо, но она должна быть продуманной. Недостаточно просто распределить ресурсы между разными дата-центрами. Нужно убедиться, что критически важные компоненты не зависят от одного единственного поставщика, даже если это Google Cloud или AWS (у AWS тоже происходят большие сбои).
🟠Необходима возможность не зависеть от одного вендора. Что произойдет, если одна из ваших критичных зависимостей станет недоступна на многие часы или дни? Компании, для которых особенно критична стабильная работа с гарантиями 99.99% надежности, идут в направлении собственных ДЦ и мульти клауд архитектур. И да, это очень дорого.

Если хотите научиться в надежность систем, welcome на курс по SRE. На 3 недели станете SRE для сервиса покупки билетов. Наплыв посетителей, отказ инфраструктуры, сбой платежной системы, а следом еще и DoS-атака. Как восстановить работу сервиса – решать вам.

Атаки на инфраструктуру через забытые ресурсы

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

Относительно легко в такой системе получить «забытые» ресурсы. Настроили что-то с недостаточно жесткими ограничениями, потом оказалось, что нужно делать по-другому, а созданные ресурсы никуда не делись и остались работать. И хорошо, если остались они только во внутренней сети, без возможности достучаться до них снаружи.

А что финансы и оплата всего забытого добра? На фоне общих отчетов какой-нибудь забытый кластер или открытый S3 bucket (классика) будут незаметны в большинстве случаев.

Типовые случаи:

➡️ Неправильно настроенный S3 bucket

🟠 Сценарий

Компания A использовала S3 bucket для хранения бэкапов логов веб-серверов. После миграции на новую систему логирования, старый bucket был забыт. Bucket остался с прежними настройками доступа, включая возможность чтения для аутентифицированных(!) AWS пользователей.

🟠 Атака

Хакер получил доступ к скомпрометированному аккаунту одного из сотрудников компании A. Используя эти credentials, он обнаружил старый S3 bucket и скачал резервные копии логов, содержащие конфиденциальную информацию о пользователях, включая имена, адреса электронной почты и пароли. Да, в логах веб сервера чего только не попадается.

🟠Последствия 

Утечка данных привела к репутационным потерям и штрафам со стороны регуляторов (GDPR).

➡️ Забытый сервисный аккаунт с большими правами

🟠 Сценарий

В публичном облаке был создан сервисный аккаунт для управления инфраструктурой. После изменения процессов автоматизации,  аккаунт был забыт, но продолжал существовать с избыточными правами и без должного мониторинга (использование ролей, сервисных аккаунтов и прочих credentials тоже нужно мониторить — ваш кэп).

🟠 Атака 

Злоумышленник, получивший доступ к учетным данным одного из сотрудников компании через фишинговую атаку, обнаружил служебный аккаунт с избыточными правами. Он использовал этот аккаунт для создания новых виртуальных машин и запуска процессов майнинга, а также скачал бэкапы развернутых в облаке БД.

🟠 Последствия 

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

➡️ Атака на цепочку поставок через незащищенный container registry

🟠Сценарий 

Компания X использовала устаревшую версию библиотеку в одном из сервисов.  Как потом выяснилось, с известной уязвимостью. Компания не проводила регулярное сканирование образов (почему это важно, и как привести в порядок свои процессы с точки зрения безопасности — на интенсиве Слёрма «DevSecOps Bootcamp»).

🟠 Атака 

Злоумышленник смог проэксплуатировать уязвимость, используй готовые инструкции.

🟠 Последствия 

Через уязвимость получилось выполнить неаутентифицированные запросы во внутренние системы компании, создав множество проблем и вытягивая данные, к которым не должен был иметь доступ. Вспомните уязвимость Log4j (пример).

Уроки

Эти примеры подчеркивают важность проактивного управления ресурсами и регулярного аудита инфраструктуры.

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

Rancher в продакшен: вебинар уже через час

В 19:00 встречаемся на бесплатном вебинаре с Вячеславом Федосеевым, чтобы обсудить:

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

Подробно расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, и почему все продолжают использовать его неправильно.

➡️ Ссылки на трансляцию придут в бота. Подключайтесь!

🐈 Стартуем через 5 минут 🐈

Подключайтесь!

Заметки про публичные облака, или что можно узнать, если внимательно читать документацию

Примеры будут про AWS, т.к. это все еще самое большое публичное облако, но с небольшими допущениями может быть применимо к любым облакам.

➡️ AWS случайным образом сопоставляет физические AZ с названиями AZ для каждой учетной записи. В результате us-east-1a для вашей учетной записи AWS может отличаться от us-east-1a для другой учетной записи AWS и находиться в другом датацентре.

➡️ В рамках одного типа экземпляров (например, m5.large) могут использоваться разные поколения серверов с разной производительностью и разными поколениями процессоров. Это приводит к тому, что производительность ваших приложений на одном и том же классе инстансов может заметно отличаться.

➡️ Некоторые сервисы AWS доступны не во всех регионах или имеют разные версии и возможности в зависимости от региона. Например, новые типы инстансов могут появляться сначала в us-east-1.

➡️ Облачные ресурсы можно быстро масштабировать, но не всегда мгновенно. В периоды пиковых нагрузок ресурсы могут быть недоступны из-за недостатка ресурсов в конкретном регионе.

Пример: ваш кластер k8s автоматически скейлит кол-во нод через karpenter, но выбранный тип инстансов «закончился» на текущий момент и кластер остался без дополнительных нод, что привело к деградации сервиса.

➡️ Провайдеры могут обновлять свои сервисы без согласования с клиентом (это все равно прописано в условиях использования сервиса, но кто их читает, да?)), что иногда приводит к проблемам. Особенно это касается managed сервисов. Почитайте этот тред в reddit.

➡️ Стоимость использования ресурсов может вырасти неожиданно для вас, и вы не сможете с этим ничего сделать.

Неожиданные ошибки в k8s, или imagePullPolicy, который вас обманывал

*Суть проблемы в официальном блоге. Всего лишь 10 лет прошло от момента создания issue 😂

➡️ В чем была проблема с Image Pull Policy в Kubernetes до версии v1.33

До выхода k8s 1.33 существовала уязвимость в механизме работы с приватными образами, связанная с политикой imagePullPolicy: IfNotPresent.

Если приватный образ, для получения которого нужен секрет для container registry, уже был скачан на узел одним подом с нужным секретом, то любой другой под, даже не имеющий доступа к этому секрету, мог использовать этот образ, просто потому что он уже есть на ноде. То есть, доступ к приватному образу получали все поды на узле, а не только те, кто был на это явно авторизован.

🟠 Пример:

- Под A в Namespace X скачал приватный образ Foo с помощью Secret 1.
- Под B в Namespace Y на том же узле указывает тот же образ Foo, но не указывает никаких секретов.
- Благодаря политике IfNotPresent, kubelet не скачивает образ заново, а просто запускает контейнер на основе уже имеющегося локально образа - даже если у Pod B нет прав на доступ к этому образу.

🟠 Почему это плохо:

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

➡️ Что изменилось в k8s 1.33

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

🟠 Для активации нового поведения:

- Необходимо включить фичу KubeletEnsureSecretPulledImages (пока в alpha и не включена по умолчанию).

Зоны ответственности kubelet

➡️ Kubelet получает манифесты подов (PodSpecs) в основном от API-сервера, но также берет их напрямую из файловой системы ноды (по умолчанию из каталога /etc/kubernetes/manifests). Это позволяет запускать control plane еще до того, как доступен API-сервер, решая проблему курицы и яйца при инициализации кластера.

➡️ После получения манифестов kubelet приводит в соответствие текущее состояние подов на ноде с желаемым состоянием, описанным в манифесте. Для запуска и управления контейнерами он взаимодействует с container runtime (containerd, CRI-O). Аргумент --container-runtime-endpoint сообщает kubelet, где находится этот container runtime.

➡️ Kubelet не только запускает поды, но и постоянно мониторит их состояние. Он реализует  liveness, readiness и startup пробы.

➡️ Kubelet регулярно отправляет информацию о статусе подов и самогй ноды в API-сервер, что позволяет control plane отслеживать состояние ноды и запущенных на ней подов.

➡️ Через kubelet реализуется доступ к exec, logs и другим операциям — все эти запросы идут через API-сервер, который в свою очередь обращается к kubelet для получения данных с нужной ноды (или нод).

➡️ Kubelet отвечает за контроль ресурсов узла: при возникновении нехватки ресурсов (например, памяти) инициирует вытеснение (eviction) подов с наименьшим приоритетом. При этом учитывается поле priorityClassName: поды с более низким приоритетом будут удалены первыми, чтобы освободить ресурсы для более важных сервисов (подробнее тут).

Почему неплохо всё это знать?

Бывают разные кейсы. Пример — этот тред на реддите, или почему важны лимиты. Под на ноде съедал всю память и из-за этого крешился kubelet, делая ноду недоступной. Упс.

Service mesh в K8s: костыль или must have?

➡️ прямой эфир в понедельник!

Специальный гость — Георг Гаал, Principal DevOps Engineer, Zodia Markets.

Эфир пройдет в формате интервью. Мы с Маркусом подготовили для Георга каверзные вопросы про стандартные и не очень способы применения service mesh. Попробуем выяснить: есть ли жизнь после сервис меша?

➡️ Встречаемся прямо здесь, на канале, 23 июня в 18:00 мск. Эфир бесплатный, предварительная регистрация не нужна.

Ждём вас!

Сбор ответов для State of DevOps Russia 2025 заканчивается

До завершения ежегодного исследования состояния DevOps осталось 2 дня.

Это исследование — единственное в своем роде в России. Оно позволяет получить полную картину того, как развивается DevOps в стране, какие инструменты и практики используют команды, с какими вызовами сталкиваются компании. Каждый новый голос делает исследование точнее и полнее, поэтому я прошу вас пройти его.

➡️ Результаты исследования будут доступны каждому участнику. А еще организаторы разыграют в лотерею мерч, промокоды и билеты на Highload++ и DevOps Conf.

20 минут вашего времени — возможность повлиять на будущее DevOps в России.

Пройти опрос — по ссылке.

Привет! Это Маркус.

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

➡️ Напоминаю: сегодня в 18:00 мск мой человек встречается с Георгом Гаалом, Principal DevOps Engineer, Zodia Markets.

Будем задавать ему всякие каверзные вопросы про сервис мэш и кубернетисы ваши (если я не просплю, конечно).

Кто придёт — лапки вверх 😻

Overengineering, который медленно убивает ваш продукт

👉 Второй вебинар серии FinOps 25 июня в 17:00 мск

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

На вебинаре мы:

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

🔹 расскажем о причинах overengineering – от карго культа до CV driven development.

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

Занять место в один клик — через бота.

Kubernetes — всё. Что вместо него?

Kubernetes стал стандартом де-факто в мире контейнеров и DevOps. Но может ли его что-то заменить?

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

➡️ Внутри есть мини-интервью со мной, рассказываю про service mesh: что это, как устроено и кому нужно. А ещё делюсь промокодом на скидку 10% на интенсив по service mesh.

Но своим подписчикам готов отдать его прямо в посте: SM_SKOBKI

Смотреть интервью — по ссылке.

BARE METAL PROVISIONING

Вы, конечно, читали документацию Kubernetes. Следуйте инструкции, и получите кластер. Но есть одна маленькая деталь, когда дело касается автоматизации добавления воркер нод — нужно сначала установить ОС!

Как только у вас появилась ОС, её можно настраивать по сети. Ansible? Кастомные скрипты по SSH? Выбирайте свой любимый инструмент, который приносит меньше всего боли! В облаках, конечно, все проще. Создали AMI со всем необходимым, засунули kubeadm join в userdata, и готово! Хотя, конечно, проще взять EKS.

Бывают разные кейсы, и, например, здесь описано, как при помощи синей изоленты, AWS SSM, userdata и EC2 metadata API (169.254.169.254/latest/meta-data) автоматизировать добавление новых воркер нод, поднятых через terraform на EC2.

Но это все еще недостаточно интересно, мы же тут про настоящий bare metal говорим! Как автоматизировать процесс подключения новых воркер нод на bare metal?

🐈 Ответ: PXE (будьте здоровы!)
PXE — Preboot Execution Environment.

➡️ Что нам понадобится?

🟠 DHCP-сервер: будет выдавать машинам IP-адреса, а также сообщать, с какого TFTP-сервера нужно тянуть образ.

🟠 TFTP-сервер: TFTP (Trivial File Transfer Protocol) — это такой очень простой (до неприличия) протокол передачи файлов, который используется, чтобы отдать образ по сети на машину, у которой еще нет даже намека на операционную систему. TFTP-сервер раздаст загрузочные файлы, необходимые для старта установки.

➡️ Как это работает?

1. DHCP Discovery: PXE-клиент, вшитый в прошивку сетевой карты, отправляет DHCP DISCOVER.
2. DHCP Offer: DHCP-сервер отвечает с IP, TFTP сервером (option 66) и bootfile (option 67), используя MAC-адрес для кастомизации.
3. TFTP Download: клиент качает bootloader (например, pxelinux.0 или ipxe.efi) через TFTP (по UDP!, вот где UDP используется в реальном мире, не всем же по TCP ходить).
4. Bootloader Config: Bootloader ищет конфигурационный файл (например, MAC-адрес-специфичный, или default), определяющий kernel и initrd.
5. Kernel & Initrd: скачиваются kernel (vmlinuz) и initrd через TFTP.
6. OS Install: ядро загружается, initrd монтируется, и запускается установщик ОС. Здесь уже важно сделать образ, который «сам» поставится, вплоть до успешного kubeadm join.

➡️ Кастомизация?

Вся кастомизация может быть основана на MAC-адресе добавляемой ноды. DHCP-сервер может выдавать разные параметры в зависимости от MAC-адреса, а TFTP-сервер может отдавать разные файлы конфигурации PXELINUX. Это позволяет автоматизировать установку разных операционных систем и конфигураций на разные машины. Но все же лучше делать единообразно.

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

Отсылаю тут к недавнему посту, почему важно знать как работает сеть, даже под десятью слоями абстракций. Если в указанной цепочке что-то сломается, расчехляйте ваши tcpdump.

А что насчет медведя? Отсылаю к другому посту про музыку для работы. Slaughter to Prevail как раз недавно выпустили новый трек RUSSIAN GRIZZLY IN AMERICA.

Две взрывных шутки из комментариев:

You can't make typical animal noises in the breakdown
Alex : hold my BEAR

Режиссёр: Сколько отсылок к России вы хотите добавить?
Саня: Да

А как вы автоматизируете процесс поднятия воркер нод, если у вас bare metal?

Архитектурные диаграммы для вашего k8s

Разобраться в инфраструктуре проще, когда она нарисована. И в этом нам поможет kubediagrams.

➡️ Что это такое?

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

➡️ Пример использования с проектом opentelemetry demo.

Этот проект был выбран, потому что для него нет готовой картинки в README на github (а там есть разные примеры, начиная от простых деплоев wordpress, заканчивая более сложными проектами типа cassandra).

Добавим репозиторий opentelemetry demo и поставим в кластер:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install my-otel-demo open-telemetry/opentelemetry-demo

Поставим kubediagrams прямо из github и запустим через python virtualenv:

git clone https://github.com/philippemerle/KubeDiagrams.git
python3 -m venv myenv; source myenv/bin/activate
pip install PyYAML diagrams

И получим ошибку 😟

Понадобилось доустановить graphviz для создания картинок. На macos ставится так:

brew install graphviz

Результат для opentelemetry demo:

kubectl get all -o yaml | ./KubeDiagrams/bin/kube-diagrams -o /tmp/otel.png -

Warning: картинка огромная, потому что компонентов много, и все они развернуты в одном namespace.

🐈 Дайджест материалов июня 🐈

Сегодня последний день месяца, а это значит, что пришло время подвести итоги и собрать в одном посте все полезные материалы.

➡️ Оптимизация запуска тяжелых образов для ML

➡️ Разгружаем etcd

➡️ Cloud native практики, которые постоянно нарушаются

➡️ Что почитать, чтобы отвлечься от кластеров

➡️ Атаки на инфраструктуру через забытые ресурсы

➡️ Заметки про публичные облака, или что можно узнать, если внимательно читать документацию

➡️ Неожиданные ошибки в k8s, или imagePullPolicy, который вас обманывал

➡️ Зоны ответственности kubelet

➡️ BARE METAL PROVISIONING

➡️ Архитектурные диаграммы для вашего k8s

Видеоматериалы:

🟣 Rancher в продакшен: вебинар с Вячеславом Федосеевым
→ YouTube
→ VK Видео
→ Rutube

🟣 Kubernetes — всё. Что вместо него? Свежий выпуск подкаста {между скобок}
→ YouTube

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

Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов

👉 воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.

Что будет на воркшопе:

Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала.

Практика:

🔹 Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;
🔹 Создание и отладка IaC (Kubernetes YAML, Ansible) с помощью AI-ассистентов: выявление и исправление ошибок;
🔹 Генерация понятной и структурированной документации к проектам с помощью AI;
🔹 Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.

А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.

Когда: в субботу, 5 июля

Узнать подробности и занять место на воркшопе — по ссылке.