CORTEL

👏Топ-5 постов #ЗаметкиИнженера

➡️ Надёжный способ бэкапа PostgreSQL
Разбор pg_dump для логических бэкапов: plain SQL, custom и directory-форматы, параллельный дамп через -Fd -j, выборочный дамп таблиц и схем, и pg_dumpall для бэкапа всего кластера с ролями. В комплекте — пайплайн с gzip и автоочисткой через find.

➡️ Загадка зависшего Temporal UI. Часть 1 — расследование
Реальный кейс: UI Temporal отдаёт 200 ОК, но данные не грузятся. Алерты молчат, CPU и память в норме, а запросы к БД зависают на 8 минут. Корень проблемы оказался в переполненном пуле соединений PgBouncer — начало трилогии с разбором архитектуры и метафорой автопарка.

➡️ Live Migration: как переместить работающую ВМ без простоя
Как KVM/QEMU переносит ВМ между серверами, пока пользователи продолжают работать. Разбор четырёх фаз: подготовка, pre-copy с итеративной синхронизацией «грязных» страниц памяти, короткий stop-and-copy и запуск на целевом хосте.

➡️ Terraform
Декларативный IaC от HashiCorp: описываете желаемое состояние, а Terraform сам приводит инфраструктуру к нему. Связка init / plan / apply, state-файлы, модули как Lego-кубики и универсальный HCL для AWS, GCP и других провайдеров — один код, разные облака.

➡️ Горячие клавиши для управления процессами в Linux-терминале
Подборка из 7 must-have комбинаций: Ctrl+C (SIGINT), Ctrl+Z (SIGTSTP с возвратом через fg/bg), Ctrl+D (EOF), Ctrl+S/Ctrl+Q (заморозка вывода), Ctrl+L и Ctrl+R. Минимум команд — максимум контроля над процессами и сессиями.

#ЗаметкиИнженера

Всего 2 дня...‼️

До, без преувеличений, главного мастер-класса этой весны!
28 мая встречаемся в прямом эфире с Вероникой Нечаевой, нашим директором по ИБ, чтобы от и до разобраться с темой моделирования угроз.

Напомним главное
1️⃣Мастер-класс будет в 2 частях. 28 мая - вся необходимая теоретическая база по МУ. 4+ часа контента, разбор ваших ситуаций и ответы на вопросы. В июне встречаемся на практической части, где создадим МУ с 0 по шаблону (да, его тоже дадим!).

2️⃣Повторов не планируем. Успевайте 28 мая, чтобы быть онлайн, спросить Веронику обо всех тонкостях, получить записи, к которым можно вернуться и оставаться на связи даже после МК.

3️⃣Для участия нужно зарегистрироваться и оплатить участие. Все детали - по ссылке. Вас ждёт обновлённый МК и 10+ часов контента без воды.

Количество участников ограничено, чтобы уделить время каждому. Мест всё меньше.

🔙ЗАРЕГИСТРИРОВАТЬСЯ🔜

🔫 Multus CNI — плагин для Kubernetes, позволяющий подключать поды к нескольким сетевым интерфейсам. Решает задачу «одна сетевая карта на под» по умолчанию, добавляя дополнительные интерфейсы через механизм CNI-цепочки.

💬 Основной функционал:
— Поддержка нескольких CNI-конфигураций для одного пода
— Делегирование создания интерфейсов сторонним CNI-плагинам
— Интеграция с сетевыми ресурсами через CRD NetworkAttachmentDefinition
— Совместимость с любыми CNI-плагинами, поддерживающими стандарт интерфейса

💬 Ключевые особенности:
— Мульти-интерфейсность — один под может иметь eth0 (основная сеть) и net1, net2 для изолированных сетей или прямого доступа к устройствам
— NetworkAttachmentDefinition (NAD) — CRD для описания дополнительных сетей: тип CNI, параметры IPAM, VLAN, gateway
— Изоляция трафика — разные интерфейсы могут принадлежать разным VRF или сетевым доменам
— Прозрачность для приложений — дополнительные интерфейсы видны как обычные сетевые устройства внутри контейнера

Multus расширяет стандартную модель сети Kubernetes, позволяя объединять несколько CNI в одном кластере и предоставлять подам гибкие сетевые конфигурации без изменения основного CNI. Это особенно востребовано в сценариях, где часть рабочих нагрузок требует прямого доступа к физическим интерфейсам или изолированных каналов, а остальные продолжают использовать общий overlay.

👉 Git
#полезное

💎 Бэкапы, которые нельзя зашифровать

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

Но бэкапы тоже могут оказаться под ударом 🤯
Если к ним есть доступ из основной инфраструктуры, злоумышленник может зашифровать или удалить не только рабочие данные, но и резервные копии.

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

👉 В новом материале разобрали, как после атаки шифровальщика пересобрали архитектуру резервного копирования и усилили защиту бэкапов с помощью Hardened Repository.

#статья

🔄 ReportPortal — open-source платформа для агрегации и анализа результатов автотестов из разных фреймворков в едином дашборде.

Решает проблему разрозненных отчётов: вместо десятков HTML-страниц от Allure, JUnit или Pytest в артефактах CI — единая лента запусков с историей, логами и аналитикой в реальном времени.

💬 Основной функционал:
— Сбор результатов автотестов через агенты для популярных фреймворков (JUnit, TestNG, Cucumber, Pytest, Mocha, Jest, NUnit, Robot Framework и др.).
— Реалтайм-отображение прогона: видно прохождение тестов прямо во время выполнения, не нужно ждать окончания сборки.
— Хранение логов, скриншотов и вложений (через S3) с привязкой к конкретным шагам теста.
— Интеграции с баг-трекерами (Jira, Rally, Azure DevOps)

💬 Ключевые особенности:
— Развёртывание через Docker Compose или Helm-чарт в Kubernetes — удобно для self-hosted сценариев, данные остаются под контролем.
— Дашборды и виджеты — кастомные графики flaky-тестов, time-to-fix, статистики по продуктам и командам.
— REST API для CI/CD — встраивается в пайплайны GitLab/Jenkins/GitHub Actions и позволяет автоматически проверять статус прогона перед деплоем.
— Лицензия Apache 2.0 — без ограничений в коммерческом использовании.

ReportPortal закрывает боль командной работы с автотестами: появляется единая база знаний по тестированию, где видна динамика, повторяющиеся падения и узкие места

👉 Git
#полезное

🖥 modprobe — утилита для загрузки и выгрузки модулей ядра во время работы системы.

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

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

➡️ Где располагаются модули?

Все скомпилированные модули лежат в /lib/modules/$(uname -r)/, разложенные по категориям (kernel/drivers/, kernel/fs/, kernel/net/ и т.д.). Имеют расширение .ko (kernel object).

➡️ Основные команды

Посмотреть загруженные модули

lsmod

Загрузить модуль

sudo modprobe overlay

modprobe сам найдёт зависимости и подгрузит их.

Выгрузить модуль

sudo modprobe -r overlay

Информация о модуле

modinfo overlay

➡️ Как загружать модули при старте системы?

Разовая загрузка через modprobe живёт до ребута. Чтобы модуль подгружался автоматически — необходимо написать его в конфиг.

Создание файла со списком модулей (по одному на строку):

sudo nano /etc/modules-load.d/k8s.conf

Внутри конфига

br_netfilter
overlay

После ребута модули загрузятся автоматически.

Как заблокировать модуль (blacklist)?

Иногда нужно запретить автозагрузку — например, конфликтующий драйвер или дырявый протокол.

Создание файла блок-лист:

sudo nano /etc/modprobe.d/blacklist-custom.conf

Внутри конфига

# Отключение Bluetooth
blacklist btusb
blacklist bluetooth

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

sudo update-initramfs -u   # Debian/Ubuntu
sudo dracut -f             # RHEL/Fedora

modprobe — базовый инструмент, без которого не настроить ни Kubernetes-ноду, ни туннилирование, ни кастомные сетевые правила.

#линуксятина

⛔️️️️ГЛАВНАЯ ОШИБКА ПРИ СОСТАВЛЕНИИ МОДЕЛИ УГРОЗ

На практике всё едет в тартарары не туда ещё до отбора самих угроз. Гораздо раньше, на этапе, где нужно ответить на вопрос:

что именно мы защищаем?

То есть определить границы информационной системы, состав объекта защиты и исходные данные.

Если границы ИС определены неверно, дальше некорректным становится всё — от состава компонентов до выводов по достаточности защиты.

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

Качественная Модель угроз начинается с описания:

1. Что является объектом защиты.
2. Где проходят границы ИС.
3. Как выглядит архитектура.
4. Какие есть исходные данные.
5. Какие допущения приняты.

И только после этого можно переходить к нарушителям, уязвимостям и угрозам.

Если вы хотите сделать МУ вместе с Вероникой Нечаевой в прямом эфире по готовому шаблону, то не откладывайте.

Места в группу заканчиваются, а стартуем уже через неделю, 28 мая.

👉 ХОЧУ С ВАМИ, РЕГИСТРИРУЮСЬ 👈

▶️ GitHub расследует возможный взлом внутренних репозиториев.

По данным ИБ-сообщества, хакерская группа TeamPCP заявила, что получила доступ примерно к 4 тыс. приватных репозиториев GitHub и выставила данные на продажу — от $50 тыс.

Предварительно, точкой входа могло стать скомпрометированное расширение для VS Code.

Сегодня разработческая среда — это доступ к репозиториям, токенам, CI/CD, облакам, секретам, внутренним пакетам и production-инфраструктуре.
Одно расширение в IDE может стать входной дверью в компанию.

💻 Pod-Level Resource Managers — новая альфа-функция Kubernetes 1.36

Она расширяет работу Topology Manager, CPU Manager и Memory Manager в kubelet: теперь они умеют работать с ресурсами, заданными на уровне всего пода через .spec.resources, а не только по отдельным контейнерам.

🔵 Зачем это нужно?

Раньше менеджеры ресурсов в kubelet работали строго по контейнерам — каждому выделялись свои CPU и память, NUMA-выравнивание делалось индивидуально. Для типовых нагрузок это нормально, но для производительных приложений возникают проблемы:

— ML-тренировки с main-контейнером и sidecar'ами, которым нужен общий NUMA-узел
— Базы данных, где shared-память и кэш CPU должны быть выровнены для всего пода

В таких сценариях нужны эксклюзивные NUMA-выровненные ресурсы для всего пода как единого целого, а не для каждого контейнера по отдельности.

🔵 Пример использования

apiVersion: v1
kind: Pod
metadata:
  name: tightly-coupled-database
spec:
  # Pod-level resources establish the overall budget and NUMA alignment size.
  resources:
    requests:
      cpu: "8"
      memory: "16Gi"
    limits:
      cpu: "8"
      memory: "16Gi"
  initContainers:
  - name: metrics-exporter
    image: metrics-exporter:v1
    restartPolicy: Always
  - name: backup-agent
    image: backup-agent:v1
    restartPolicy: Always
  containers:
  - name: database
    image: database:v1

'Здесь 8 CPU и 16Gi памяти выделяются на весь под целиком. Kubelet через Topology Manager выровняет их по одному NUMA-узлу, а CPU Manager закрепит эксклюзивные ядра на уровне пода.

🔵 Что с CPU-квотами?

Меняется и работа CPU-квот в cgroup.
Раньше каждый контейнер получал свою квоту (cpu.max), и неиспользованный CPU одного контейнера не передавался другому. Теперь квота задается на родительском cgroup пода — контейнеры внутри могут брать из общего пула, пока не упрутся в общий лимит пода. Это удобно, когда основной контейнер периодически просит дополнительный CPU, а sidecar'ы работают неравномерно.

Pod-Level Resource Managers — логичный шаг в эволюции управления ресурсами k8s. Они закрывают старую боль с распределением CPU и памяти между контейнерами одного пода и делают кластер удобнее для чувствительным к производительности нагрузкам. Пока это альфа — нужно включать feature gate, и для прода рановато, но для тестов уже можно попробовать.

👉 Подробнее в официальном блоге Kubernetes

#заметкиИнженера

Ваши отзывы 🥰

Да, после практикума по модели угроз у вас точно не останется вопросов.

Вы можете задавать всё по вашей ситуации как в эфире, так и после – мы на связи.

В этот раз программа обновлена: будет ещё больше полезного, конкретного и актуального на реалии 2026.

Повторов не планируем! Давайте побережем ресурс нашей Вероники Нечаевой и не станем откладывать до следующего раза.

Стартуем уже в следующий четверг🔥

👉 РЕГИСТРАЦИЯ 👈

🧬 Инциденты виртуализации, которые стоили бизнесу данных и миллионов рублей

Сбой в слое виртуализации быстро отражается на работе всей инфраструктуры.

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

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

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

👉 В новом материале разобрали реальные инциденты: что стало причиной сбоев, к каким последствиям они привели и какие выводы стоит учесть при построении устойчивой инфраструктуры.

#статья

🎬Только для вас - отрывок из прошлого практикума по моделированию угроз!
30 секунд из 8+ часов контента.

Вероника Нечаева вместе с вами возьмёт шаблон МУ (да, его предоставим) и пойдёт по порядку - так, чтобы у вас получился готовый, качественный документ, по которому вы не только построите систему защиты, но и будете готовы ко всем проверкам регуляторов.

Не откладывайте регистрацию!
Стартуем менее чем через 2 недели и берём ОГРАНИЧЕННОЕ количество участников, чтобы уделить время каждому.

👉РЕГИСТРАЦИЯ👈

🖥 sysctl — утилита для чтения и изменения параметров ядра во время работы системы, без перезагрузки.

Под капотом это интерфейс к виртуальной файловой системе /proc/sys/, где каждый параметр представлен отдельным файлом.

Полезно, когда нужно подкрутить сеть, память, лимиты или поведение ядра под конкретную нагрузку — БД, k8s-нода, прокси, файловый сервер.

💬 Как устроено?

Все настройки лежат в /proc/sys/ и сгруппированы по разделам:
— net.* — сетевой стек (TCP/IP, маршрутизация, ARP)
— vm.* — управление памятью и swap
— kernel.* — параметры ядра (PID, dmesg, core dump)
— fs.* — файловые системы (inotify, лимиты файловых дескрипторов)

💬 Основные команды

Посмотреть все параметры:

sysctl -a

Прочитать конкретный параметр:

sysctl net.ipv4.ip_forward

Изменить параметр на лету (до перезагрузки):

sudo sysctl -w net.ipv4.ip_forward=1

💬 Как сделать настройки постоянными?

Изменения через -w живут до первого ребута. Чтобы параметры применялись при загрузке — необходимо добавить их в конфиг.

Главный файл: /etc/sysctl.conf
Дополнительные: /etc/sysctl.d/*.conf

💬 Пример
создание дополнительного конфига:

sudo nano /etc/sysctl.d/99-custom.conf

Добавляем в файл следующие строки

# Включить форвардинг пакетов
net.ipv4.ip_forward = 1

# Увеличить лимит открытых файлов
fs.file-max = 2097152

# Уменьшить агрессивность swap
vm.swappiness = 10

Применить без перезагрузки:

sudo sysctl --system        # применить все конфиги из /etc/sysctl.d/
sudo sysctl -p              # применить /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.d/99-custom.conf  # конкретный файл

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

#линуксятина

Перезапуск подов в Kubernetes.

Есть четыре разных перезапуска:

— Перезапуск контейнера — процесс убит и пересоздан, объект пода остался. UID и IP не меняются, restart count +1.
— Пересоздание пода — объект удалён, создан новый. UID новый, IP новый, restart count сбрасывается в 0.
— Rolling update — новый ReplicaSet поднимает новые поды, старые завершаются. Тоже новые UID и IP.
— In-place resize (1.35 GA) — cgroups обновляются, процесс не трогается. UID и IP неизменны.

Простой тест:
Изменился ли UID пода?
Если да — это пересоздание, а не перезапуск.
Если нет — тот же объект пода продолжил жить, перезапустился только процесс внутри.

➡️ Что часто упускают

kubelet следит за спецификацией пода — а не за ConfigMap'ами, Secret'ами или CRD Istio. Если вы обновили ConfigMap, но spec пода не изменился — kubelet ничего не сделает. Изменение для kubelet попросту невидимо.
Этот факт объясняет большую часть расследований «почему мой конфиг не обновился?» в проде.

💬 Что вызывает перезапуск, а что — нет?

— ConfigMap/Secret через env var — процесс читает переменные один раз при execve(). POSIX-контракт: никто извне не может их менять. Нужен явный rollout restart.
— ConfigMap/Secret как volume — kubelet делает атомарную подмену симлинка. Срабатывает IN_CREATE на ..data, а не IN_MODIFY на файле — большинство наивных реализаций reload этот момент пропускает. Приложение должно само перечитать файл.
— Смена образа — всегда пересоздание пода через rolling update. Новый ReplicaSet, новый UID, новый IP. Это не перезапуск.
— CPU/Memory в 1.35 GA — резайз без пересоздания пода. UID и IP не меняются. Контейнер перезапускается только если так указано в resizePolicy.
— Istio VirtualService / DestinationRule — никогда не перезапускает. Istiod пушит конфиг через xDS gRPC прямо в Envoy, в память. Файлов на диске нет.
— NetworkPolicy — никогда. CNI агент обновляет eBPF/iptables на ноде, поды не трогаются.

💬 Команды для проверки

Перезапуск или пересоздание?

 kubectl get pod <pod>  -n <namespace> -o custom-columns="NAME:.metadata.name,UID:.metadata.uid,IP:.status.podIP,RESTARTS:.status.containerStatuses[0].restartCount"

События в поде

kubectl describe pod  <pod>  -n <namespace>  | grep -A 20 "Events:" 

Понимание этих сценариев экономит время в инцидентах. Фраза «под перезапустился» слишком общая: сначала смотрим на UID и restart count. Так сразу видно, пересоздался сам pod или перезапустился только контейнер внутри.

С hot-reload сложнее. Он удобен, но не всегда даёт явный сигнал об ошибке: приложение может принять кривой конфиг, а проблема проявится позже и в другом месте. Пересоздание pod дороже, зато честнее: если что-то сломано, это быстрее станет видно по статусам, readiness и rollout.

#заметкиИнженера

⬆️ Как выбрать ИТ-инфраструктуру и не переплатить

Чаще начинают с технических параметров: серверов, облака, SLA и стоимости.

На практике начинать лучше с того, на чём держится бизнес:
— онлайн-продажи и клиентские сервисы;
— обработка заказов, логистика, документооборот;
— 1С, CRM, ERP и внутренние системы;
— интеграции с внешними площадками.
И определить требования к этим системам:
— RTO — сколько система может быть недоступна после сбоя;
— RPO — сколько данных можно потерять без критичных последствий.

Так становится понятнее, куда вообще двигаться: в паблик, частное облако, гибрид, выделенную инфраструктуру или резервную площадку.

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

👉 Как выбрать ИТ-инфраструктуру под задачи компании и не переплатить за лишнюю сложность — разобрали в новом материале.

#статья

А для тех, кто уже разобрался в теории и хочет перейти к практике, Вероника Нечаева проведёт МАСТЕР-КЛАСС ПО МОДЕЛИ УГРОЗ В 2 ЧАСТЯХ.

Выше - лишь часть отзывов с прошлого МК.
8+ часов контента, только практика, реальные кейсы, ответы на ВСЕ вопросы, юмор Вероники и полезные бонусы.

Никто не уйдёт без ответов и готовой модели угроз.

Первая встреча пройдёт уже 27-28 мая.

⁉️Места ограничены, поэтому успевайте.

👉ЗАРЕГИСТРИРОВАТЬСЯ👈

П-пятница-полезное! 😘

Друзья, если вы ещё не приступали к модели угроз или сомневаетесь в той, что есть, то этот пост - для вас!

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

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

1️⃣Модель угроз для информационных систем персональных данных: кто ответственный, когда и как составлять, с чего начинать и на что опираться. В общем, база.

2️⃣Подробно о методике ФСТЭК для МУ: углубляемся, разбираем нюансы, шаги и примеры.

🔝 Топ-5 постов #линуксятина

🔜 Вредоносное ПО в Linux
Разбор штатных утилит для обнаружения и устранения угроз: от анализа процессов и сетевых соединений до проверки учётных записей и логов. Никаких сторонних сканеров — только то, что уже есть в системе.

🔜 KVM + QEMU — виртуализация на Linux
Как запустить полноценную виртуальную машину с аппаратным ускорением: быстрый старт через qemu-system-x86_64 и управляемые ВМ через virt-install + virsh. Два подхода под разные задачи.

🔜 Загрузчики Linux
Обзор трёх способов загрузки системы: мощный GRUB для большинства случаев, минималистичный systemd-boot для UEFI и прямая запись в прошивку через efibootmgr — для тех, кто хочет убрать лишнее.

🔜 Netplan
Современный декларативный способ настройки сети через YAML-файлы. Пришёл на смену скриптам в /etc/network/interfaces и стал стандартом в Ubuntu Server и облачных образах Debian.

🔜 LabEx
Браузерная среда с полноценным терминалом Ubuntu — без виртуалок и доступа к реальному серверу. Готовые лабораторные работы по Linux, сети, Docker и DevOps с автоматической проверкой заданий.

📝 Обучающие материалы по модульной платформе Kubernetes

Совсем недавно мы делились изменениями в релизе nxs-universal-chart v.3.0. В первой статье из серии обучающих Пётр, DevOps-инженер компании Никсис, рассказал о том, как развернуть полностью готовый Inference контур в Kubernetes на основе KServe и Istio Gateway.

Из первой части вы разберете:
• 5 слоев inference-контура и функции каждого компонента;
• полный values.yaml файл на примере ai-inference-mesh и всё, что под капотом;
• рекомендации по настройке полноценного мониторинга моделей и правил безопасности

Приятного чтения и продуктивной недели!

#Хабр #статья_Никсис #kubernetes

💻 Node Affinity в Kubernetes: притягиваем поды к нужным нодам

В прошлый раз разобрали Taints и Tolerations: отсекаем лишних, пропускаем своих

Есть еще обратная сторона — Node Affinity.

Это правила в манифесте пода, которые говорят планировщику: «Хочу попасть на ноду с такими-то метками».
Своеобразная эволюция nodeSelector: та же идея, но с гибкой логикой, операторами и уровнями строгости.

💬 Чем отличается от Taints и Tolerations?

Taints & Tolerations работают от ноды: нода отталкивает всех, кто не имеет нужного toleration.
Node Affinity работает от пода: под сам тянется к нодам с нужными метками.

💬 Режимы работы

requiredDuringSchedulingIgnoredDuringExecution — жёсткое требование. Нет подходящей ноды — под уходит в Pending. Работает как nodeSelector, но с выразительным синтаксисом.

preferredDuringSchedulingIgnoredDuringExecution — мягкое предпочтение. Планировщик постарается найти нужную ноду, но если не найдёт — разместит на любой доступной. Задаётся с weight от 1 до 100: чем выше — тем приоритетнее.

IgnoredDuringExecution в обоих случаях означает одно: если метки на ноде изменились после запуска пода — под продолжает работать, пересчёта нет.

⭐️ Пример манифеста

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disk-type
          operator: In
          values:
          - ssd
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 80
      preference:
        matchExpressions:
        - key: zone
          operator: In
          values:
          - ru-east-1a

Под обязан попасть на ноду с disk-type=ssd и предпочтительно в зону ru-east-1a.

⭐️ Операторы

In / NotIn — значение входит или не входит в список.
Exists / DoesNotExist — ключ есть или отсутствует на ноде.
Gt / Lt — числовое сравнение значений меток, только для nodeAffinity.
NotIn и DoesNotExist дают поведение anti-affinity — отталкивание через правила самого пода, без taint на ноде.

💬 Когда что использовать?

— Жёстко изолировать ноды под GPU, CI-воркеры или конкретную команду → Taints + Tolerations
— Направить под на ноды с нужными характеристиками: SSD, зона, архитектура → Node Affinity
— Полный контроль над планированием → оба механизма вместе

В связке Taints держат чужих подальше, а Node Affinity точно доставляет своих куда нужно.

#заметкиИнженера