Разгружаем etcd

Представим ситуацию: поток записи и чтения в кластере такой, что etcd еле справляется, iops дисков ушли в потолок, расти уже некуда.

➡️ Давайте просто добавим больше нод! И тут кроется подвох. Дело в том, что etcd работает на основе алгоритма RAFT. И даже чтение данных, не говоря уже о записи, происходит через лидера. Думаю, тут я ни для кого не открыл ничего нового.

Как работает запись в etcd:

🟠 API-сервер отправляет запрос на запись одной из нод etcd.
🟠 Если повезло и запрос попал на лидера, то лидер реплицирует запись на мажоритарное количество нод (например, 2 из 3 или 3 из 5). Только после этого запись считается успешной.
🟠 Если же запрос прилетел на реплику, то он все равно перенаправляется лидеру.
🟠И только после записи на лидере и мажоритарном количестве реплик API-сервер получает подтверждение.

Теперь, зная это, давайте подумаем о масштабировании etcd.

➡️ Представьте себе кластер с 7 нодами etcd. В этом случае запись нужно реплицировать на 4 из 7 нод, что может существенно замедлить процесс (хотя все, конечно, относительно).

Оптимальным считается иметь 3-5 нод etcd. Это обеспечивает достаточную отказоустойчивость и не перегружает репликацию между нодами etcd. Однако, в таком сетапе мы все равно ограничены ресурсами одной ноды.

Но есть решение! Хотя и применять его стоит с большой осторожностью.

Можно вынести хранение events в отдельный кластер etcd (а это, как минимум, еще 3 ноды в ваш кластер). Для этого в конфиге API-сервера нужно указать следующее:

# /etc/kubernetes/manifests/kube-apiserver.yaml
command:
  - kube-apiserver
  - --etcd-servers-overrides=/events#https://etcd-events.example.com:2379
  ...

Разобраться в тонкостях работы etcd можно в гайде от Слёрма ➡️ в боте.

Rancher в продакшен: лучшие практики управления кластерами

Мы с Вячеславом Федосеевым (и Маркусом, конечно же) решили провести совместный веб и поговорить про Rancher. Будем обсуждать:

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

Подробно покажем и расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, поделимся собственным опытом и best practices.

Когда: 16 июня в 19:00 мск

Занять место на вебинаре ➡️ через бота.

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

Все мы знаем базовые правила.

➡️ Не храните секреты в коде, будь то код приложения или код инфры (terraform, ansible, puppet, etc.).
➡️ Разделяйте prod и dev. Лучше на разные облачные аккаунты, чтобы уменьшить blast radius.
➡️ Руководствуйтесь принципом наименьших привилегий. Да, часто хочется просто накинуть побольше прав очередной IAM роли и не разбираться, а какие права реально нужны.

Но раз за разом эти простые вещи игнорируются в силу разных причин. Ловите чек-лист, на что обратить внимание, чтобы потом не было мучительно больно:

🟠 Безопасность

➡️ Least privilege: начинать с широких прав доступа кажется удобным, но приводит к огромным проблемам безопасности в будущем.

➡️ Использование IAM ролей (или аналогов)
- Использовать IAM роли для доступа к ресурсам.
- Не использовать статические креды для доступа.
- Использовать короткоживущие ключи доступа.
- Использовать AssumeRole (или аналоги), чтобы позволить, например, EC2 инстансу, временно получить нужные права доступа.

➡️ Регулярная ротация ключей и сертификатов: своевременная ротация ключей доступа и SSL/TLS сертификатов - must have, особенно для прода. Многие подобные ротации в публичных облаках работают из коробки, а где-то нужно дополнительно это настроить.

➡️ Проверка неиспользуемых ролей (пример)

➡️ Включать MFA для всех аккаунтов, особенно для root аккаунта.

➡️ Федеративные аккаунты: должен быть ровно один аккаунт, через который можно управляться всеми остальными (пример)

➡️ Сегментация сети: изоляция различных сред (dev, staging, prod) с помощью VPC и Security Group.

➡️ Шифрование данных: шифрование данных как при хранении (at rest) так и при передаче (in transit). At rest — не опциональный момент и должен быть включен обязательно.

🟠 Infrastructure as code

➡️ Terraform: автоматизация развертывания и управления инфраструктурой. Это позволяет отслеживать изменения, автоматизировать развертывание и избежать ручных ошибок.

➡️ Версионирование IaC: хранить код инфраструктуры в git.

➡️ Автоматизированные пайплайны для развертывания IaC: Интегрировать IaC с CI/CD пайплайнами.

🟠 Мониторинг и логирование

➡️ Централизованное логирование: собирать логи со всех компонентов системы в централизованное хранилище для упрощения анализа и отладки.

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

➡️ Алерты: никто не будет постоянно смотреть в ваши метрики и логи. Без алертов они почти бесполезны для раннего выявления проблем.

🟠 CI/CD

➡️ Автоматизация всего, что возможно: автоматизация развертывания, тестирования, масштабирования и восстановления.

➡️ CI/CD: непрерывная интеграция и непрерывная доставка - основа современной разработки.

➡️ Автоматизированные тесты: писать и запускать тесты (unit, integration, end-to-end) в CI/CD пайплайне.

🟠 Стоимость

➡️ Использовать reserved instances, saving plans или аналоги для сокращения расходов

➡️ Использовать менее отказоустойчивые решения для тестовых сред. Вам не нужно тройное резервирование БД, S3 и так далее практически никогда для dev/staging.

➡️ Автоскейлинг: выключить тестовые среды на ночь — тоже вариант экономии. Увеличивать ресурсы на проде, зная заранее паттерны нагрузки — так же полезно.

➡️ Удаление неиспользуемых ресурсов: регулярно проверять и удалять неиспользуемые ресурсы.

➡️ Выбор правильного типа инстанса: использование правильного размера и типа инстанса для задач. Недоиспользование ресурсов один из ключевых факторов повышенной стоимости инфраструктуры. Но не стоит забывать про сезонные скачки нагрузки. То что сегодня кажется ненужным, в сезон распродаж приводит к нерабочему проду, потому что он не справляется с нагрузкой и приходится срочно скейлить ресурсы.

➡️ Тегирование ресурсов: правильная система тегов для отслеживания стоимости и принадлежности ресурсов командам.

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

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

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

➡️ 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?