В WireGuard mesh проблема с фрагментацией часто выглядит как случайный сбой: SSH работает, ping проходит, а HTTPS зависает после ClientHello. Причина обычно в том, что реальный путь уже меньше стандартного MTU из-за WG, VLAN, VXLAN, AmneziaWG или внешнего туннеля. Проверяйте по порядку: - найдите минимальный размер пакета через ping с DF; - посчитайте MTU каждого вложенного туннеля; - проверьте, доходят ли ICMP Packet Too Big; - сравните MSS в SYN-пакетах на входе и выходе. TCP MSS Clamping задают на границе туннеля, например через nftables или iptables. Но значение должно следовать из реального MTU: грубое MSS MSS 1200 может скрыть проблему и снизить throughput, а слишком большое значение вернет black hole PMTUD. Практический контроль после изменений: curl крупного ответа, iperf3 через mesh, tcpdump с фильтром tcptcpflags & tcp-syn != 0 и тест нескольких направлений. Разбор MTU, MSS и WireGuard-сценариев: https://ftops.space
Большинство реализаций Zero-Trust в bare-metal Kubernetes кластерах ломаются на стыке CNI и оверлейной сети. Когда ноды распределены по разным дата-центрам и связываются через WireGuard, стандартный механизм NetworkPolicy на базе iptables с трафиком внутри туннеля работает по остаточному принципу. Метаданные источника теряются, conntrack переполняется при частой ротации подов, а компрометация одного узла открывает доступ ко всему оверлею. Настоящая сетевая микросегментация требует переноса контрольной плоскости безопасности прямо в сетевой стек ядра. Использование eBPF позволяет отбросить громоздкий netfilter и привязывать правила не к нестабильным IP-адресам, а к криптографической идентичности пода (Identity-Aware Security). Пакет проверяется еще на уровне eBPF-программы до того, как ядро потратит ресурсы на аллокацию sk_buff или обработку таблицы маршрутизации. Чтобы zero-trust не превратился в декоративный конфиг, соблюдайте базовые регламенты: - Отключайте дефолтный ингресс в namespace и вводите явную политику Default Deny для всех подов. - Переводите CNI на eBPF datapath с валидацией L7-трафика без зависимости от сетевых интерфейсов ноды. - Аудируйте попытки несанкционированного межсервисного взаимодействия через eBPF-события в реальном времени, а не по логам фаервола. Подробные схемы строгой сегментации и развертывания безопасных K3s-кластеров на собственном железе вы найдете на https://ftops.space.
On-call дежурство — не героизм, а инженерный процесс
Каждый инженер знает это ощущение: только закрыл глаза, а в голове крутится «а вдруг я что-то сломал тем правилом в firewall?». Спать спокойно на дежурстве — это вопрос не воли, а архитектуры системы.
Первое, что я ввёл в практику на всех продакшен-нодах: rollback-таймер перед любой сетевой правкой. Принцип прост — применяешь изменение и тут же запускаешь at-задачу на откат через 3-5 минут. Если всё работает — отменяешь вручную. Если потерял связь — система сама откатится. Реализуется одной строкой:
at now + 5 minutes <<< "restore-network-rules.sh"
Второе — watchdog-демоны. Systemd умеет перезапускать сервисы, но это не watchdog в полном смысле. Настоящий watchdog проверяет не то, что процесс жив, а то, что он реально отвечает: слушает порт, отдаёт 200, пишет heartbeat в файл. Сам процесс пишет timestamp каждые N секунд, внешний скрипт по cron проверяет свежесть — и если timestamp устарел, бьёт тревогу и перезапускает. Это честнее, чем «процесс есть, а толку ноль».
Третье — культура надёжности начинается до того, как ты лёг спать. Runbook для каждого алерта. Алерты только на то, что требует немедленного действия человека (не просто «CPU 80%» — это информация, не алерт). Автоматический откат там, где это безопасно. Тогда on-call перестаёт быть ночным кошмаром и становится редкой необходимостью.
Спишь спокойно не потому, что ничего не ломается. А потому что система знает, что делать, когда ломается.
#ftops #devops #linux #freebsd #sre #инфраструктура
Каждый инженер знает это ощущение: только закрыл глаза, а в голове крутится «а вдруг я что-то сломал тем правилом в firewall?». Спать спокойно на дежурстве — это вопрос не воли, а архитектуры системы.
Первое, что я ввёл в практику на всех продакшен-нодах: rollback-таймер перед любой сетевой правкой. Принцип прост — применяешь изменение и тут же запускаешь at-задачу на откат через 3-5 минут. Если всё работает — отменяешь вручную. Если потерял связь — система сама откатится. Реализуется одной строкой:
at now + 5 minutes <<< "restore-network-rules.sh"
Второе — watchdog-демоны. Systemd умеет перезапускать сервисы, но это не watchdog в полном смысле. Настоящий watchdog проверяет не то, что процесс жив, а то, что он реально отвечает: слушает порт, отдаёт 200, пишет heartbeat в файл. Сам процесс пишет timestamp каждые N секунд, внешний скрипт по cron проверяет свежесть — и если timestamp устарел, бьёт тревогу и перезапускает. Это честнее, чем «процесс есть, а толку ноль».
Третье — культура надёжности начинается до того, как ты лёг спать. Runbook для каждого алерта. Алерты только на то, что требует немедленного действия человека (не просто «CPU 80%» — это информация, не алерт). Автоматический откат там, где это безопасно. Тогда on-call перестаёт быть ночным кошмаром и становится редкой необходимостью.
Спишь спокойно не потому, что ничего не ломается. А потому что система знает, что делать, когда ломается.
#ftops #devops #linux #freebsd #sre #инфраструктура
On-call дежурство — не героизм, а инженерный процесс
Спать спокойно не потому что ничего не ломается. А потому что система знает что делать, когда ломается.
Подробнее о культуре надёжности: https://ftops.space
Спать спокойно не потому что ничего не ломается. А потому что система знает что делать, когда ломается.
Подробнее о культуре надёжности: https://ftops.space
Стандартная команда kubectl cordon или drain изолирует узел только с точки зрения планера Kubernetes. Для распределенного хранилища Longhorn это пустой звук: его собственный контроллер ориентируется на кастомные ресурсы node.longhorn.io. Если запустить процедуру обслуживания сервера без предварительной блокировки сторедж-слоя, можно получить дисковый шторм и непредсказуемый сплит-брейн реплик. Корректный протокол планового вывода bare-metal узла требует строгого порядка действий: 1. Перевести allowScheduling в false в CRD Longhorn для целевого узла. 2. Включить флаг evictionRequested, чтобы реплики плавно перетекли на другие физические диски до остановки подов. 3. Дождаться перехода всех Volume в состояние Healthy и только после этого выполнять kubectl drain. В условиях K3s кластеров на собственном железе игнорирование этого порядка приводит к тому, что при перезагрузке узла система начинает синхронизировать гигабайты данных поверх не полностью остановленного I/O. Это особенно критично...
Стандартная команда kubectl cordon или drain изолирует узел только с точки зрения планера Kubernetes. Для распределенного хранилища Longhorn это пустой звук: его собственный контроллер ориентируется на кастомные ресурсы node.longhorn.io. Если запустить процедуру обслуживания сервера без предварительной блокировки сторедж-слоя, можно получить дисковый шторм и непредсказуемый сплит-брейн реплик. Корректный протокол планового вывода bare-metal узла требует строгого порядка действий: 1. Перевести allowScheduling в false в CRD Longhorn для целевого узла. 2. Включить флаг evictionRequested, чтобы реплики плавно перетекли на другие физические диски до остановки подов. 3. Дождаться перехода всех Volume в состояние Healthy и только после этого выполнять kubectl drain. В условиях K3s кластеров на собственном железе игнорирование этого порядка приводит к тому, что при перезагрузке узла система начинает синхронизировать гигабайты данных поверх не полностью остановленного I/O. Это особенно критично при срочной накатке патчей безопасности ядра Linux, когда окно обслуживания строго ограничено. Практические регламенты по управлению отказоустойчивостью распределенных хранилищ и сетевых мешей разбираем в блоге https://ftops.space.
FTOPS.SPACE: СУТОЧНЫЙ СРЕЗ АНАЛИТИКИ
12.09.2026 22:34 MSK
1. МЕТРИКИ АУДИТОРИИ И ОХВАТ
Telegram @runas_daemon
- Подписчиков: 85
- Публикаций за сутки: 10 (все слоты отработаны по расписанию)
Meta Threads @ftops.space
- Подписчиков: 6
- Просмотры профиля за сутки: 1 235 / 3 221 (рост x2.6 внутри суток)
- Лайки: 5 | Replies: 4 | Reposts: 0 | Quotes: 0
- Engagement rate по просмотрам: ~0.28%
2. АНАЛИЗ ВОВЛЕЧЕННОСТИ
Threads-аудитория реагирует органично: 4 replies при 5 лайках - нетипично высокое соотношение для технического канала. Посты вызывают реакцию комментария, а не пассивный скролл. Нулевые reposts и quotes ожидаемы для узкоспециализированного bare-metal/DevOps-контента: инженеры сохраняют, а не репостят.
Рост просмотров x2.6 за сутки (1235 -> 3221) объясняется либо попаданием поста в рекомендации алгоритма Threads, либо активностью в пиковые вечерние часы.
Telegram-канал стабилен: 85 подписчиков при плотности 10 постов/день - нагрузка на аудиторию на грани насыщения. Отток надо мониторить.
3. СТРАТЕГИЧЕСКИЕ РЕКОМЕНДАЦИИ
- Постмортемы реальных инцидентов (split-brain, quorum loss, failover) дают наибольший organic reach в инженерных лентах.
- Сравнение bare-metal vs cloud по TCO с конкретными цифрами - формат, который репостят коллеги и цитируют в чатах.
- Рассмотреть сокращение Telegram-кадентности до 7-8 постов/день для снижения fatigue без потери охвата.
- Для роста Threads-аудитории: добавить 1 пост в неделю с открытым техническим вопросом без ответа в тексте - drives replies и буст алгоритма.
Следующий срез: завтра в 22:30 MSK.
https://ftops.space
12.09.2026 22:34 MSK
1. МЕТРИКИ АУДИТОРИИ И ОХВАТ
Telegram @runas_daemon
- Подписчиков: 85
- Публикаций за сутки: 10 (все слоты отработаны по расписанию)
Meta Threads @ftops.space
- Подписчиков: 6
- Просмотры профиля за сутки: 1 235 / 3 221 (рост x2.6 внутри суток)
- Лайки: 5 | Replies: 4 | Reposts: 0 | Quotes: 0
- Engagement rate по просмотрам: ~0.28%
2. АНАЛИЗ ВОВЛЕЧЕННОСТИ
Threads-аудитория реагирует органично: 4 replies при 5 лайках - нетипично высокое соотношение для технического канала. Посты вызывают реакцию комментария, а не пассивный скролл. Нулевые reposts и quotes ожидаемы для узкоспециализированного bare-metal/DevOps-контента: инженеры сохраняют, а не репостят.
Рост просмотров x2.6 за сутки (1235 -> 3221) объясняется либо попаданием поста в рекомендации алгоритма Threads, либо активностью в пиковые вечерние часы.
Telegram-канал стабилен: 85 подписчиков при плотности 10 постов/день - нагрузка на аудиторию на грани насыщения. Отток надо мониторить.
3. СТРАТЕГИЧЕСКИЕ РЕКОМЕНДАЦИИ
- Постмортемы реальных инцидентов (split-brain, quorum loss, failover) дают наибольший organic reach в инженерных лентах.
- Сравнение bare-metal vs cloud по TCO с конкретными цифрами - формат, который репостят коллеги и цитируют в чатах.
- Рассмотреть сокращение Telegram-кадентности до 7-8 постов/день для снижения fatigue без потери охвата.
- Для роста Threads-аудитории: добавить 1 пост в неделю с открытым техническим вопросом без ответа в тексте - drives replies и буст алгоритма.
Следующий срез: завтра в 22:30 MSK.
https://ftops.space
Автоматический бэкап etcd в S3 создаёт опасную иллюзию защищенности, которая рушится при первом реальном инциденте в HA-кластере K3s. Когда вы запускаете процедуру восстановления на одном из мастеров, встроенный etcd пытается накатить снепшот поверх текущей структуры Raft. Если остальные управляющие узлы продолжают работать или сохранили старые данные в локальном хранилище, кластер мгновенно рассинхронизируется и блокирует операции записи. Рабочий регламент аварийного восстановления требует жесткой технической последовательности: - Полная остановка службы k3s на всех control-plane узлах кластера. - Очистка каталога /var/lib/rancher/k3s/server/db/etcd на всех ведомых мастерах для уничтожения старого состояния Raft. - Запуск процедуры cluster-reset на первичном узле с флагами --etcd-s3-enabled, --etcd-s3-bucket и указанием конкретного файла через --cluster-reset-restore-path или --etcd-s3-snapshot-name. - Проверка запуска одиночного кворума и последовательное переприсоединение остальных ...
Автоматический бэкап etcd в S3 создаёт опасную иллюзию защищенности, которая рушится при первом реальном инциденте в HA-кластере K3s. Когда вы запускаете процедуру восстановления на одном из мастеров, встроенный etcd пытается накатить снепшот поверх текущей структуры Raft. Если остальные управляющие узлы продолжают работать или сохранили старые данные в локальном хранилище, кластер мгновенно рассинхронизируется и блокирует операции записи. Рабочий регламент аварийного восстановления требует жесткой технической последовательности: - Полная остановка службы k3s на всех control-plane узлах кластера. - Очистка каталога /var/lib/rancher/k3s/server/db/etcd на всех ведомых мастерах для уничтожения старого состояния Raft. - Запуск процедуры cluster-reset на первичном узле с флагами --etcd-s3-enabled, --etcd-s3-bucket и указанием конкретного файла через --cluster-reset-restore-path или --etcd-s3-snapshot-name. - Проверка запуска одиночного кворума и последовательное переприсоединение остальных серверов через сброс их локальной базы. Отдельная точка отказа — учетные данные S3 и node-token. Если восстановление выполняется на с нуля развернутый нод, K3s не сможет прочитать настройки S3 из неинициализированной базы. Все ключи доступа, эндпоинты и параметры bucket должны быть явно прописаны в файле конфигурации config.yaml до момента выполнения команды сброса, иначе старт завершится ошибкой авторизации API. Разборы сетевых инцидентов, регламенты сборки отказоустойчивых bare-metal инфраструктур и сценарии DR регулярно выходят в проекте https://ftops.space.
Гиперскейлеры продают гигагерцы и гигабайты, но умалчивают про реальную структуру сетевых задержек. В пулах EKS или GKE межзональный трафик проходит через слои виртуализации vNIC, фильтры гипервизора и оверлейные сети. Результат — устойчивый p99 latency между нодами на уровне 1.8–3.2 миллисекунд. В K3s-кластере на голом железе с прямым 10GbE/100GbE L2-фабриком и eBPF-маршрутизацией без оверлея межнодовая задержка падает до 80–150 микросекунд. Для транзакционных баз данных и распределенного кэша это разница между падением пропускной способности и стабильной работой под пиковой нагрузкой. Финансовая модель облака окончательно ломается на блочных хранилищах и межзональном egress. Гарантированные 30 000 IOPS на io2 или gp3 с высоким лимитом операций обходятся в месяц дороже, чем разовый закуп двух корпоративных U.3 NVMe накопителей с ресурсом 3 DWPD. K3s на bare-metal позволяет отдавать подам сырые диски через Local Path Provisioner или собирать распределенное хранилище на Rook-Ceph с прям...
Гиперскейлеры продают гигагерцы и гигабайты, но умалчивают про реальную структуру сетевых задержек. В пулах EKS или GKE межзональный трафик проходит через слои виртуализации vNIC, фильтры гипервизора и оверлейные сети. Результат — устойчивый p99 latency между нодами на уровне 1.8–3.2 миллисекунд. В K3s-кластере на голом железе с прямым 10GbE/100GbE L2-фабриком и eBPF-маршрутизацией без оверлея межнодовая задержка падает до 80–150 микросекунд. Для транзакционных баз данных и распределенного кэша это разница между падением пропускной способности и стабильной работой под пиковой нагрузкой. Финансовая модель облака окончательно ломается на блочных хранилищах и межзональном egress. Гарантированные 30 000 IOPS на io2 или gp3 с высоким лимитом операций обходятся в месяц дороже, чем разовый закуп двух корпоративных U.3 NVMe накопителей с ресурсом 3 DWPD. K3s на bare-metal позволяет отдавать подам сырые диски через Local Path Provisioner или собирать распределенное хранилище на Rook-Ceph с прямой PCI-пропускной способностью. Вы убираете из бюджета наценку гиперскейлера за эмуляцию дискового контроллера и плату за внутренний сетевой трафик. Переход на bare-metal K3s требует инженерной зрелости: вы сами отвечаете за драйверы, жизненный цикл ядра Linux (включая своевременный патчинг уязвимостей масштаба Pedit COW), тюнинг sysctl и настройку WireGuard mesh для связывания площадок. Но в обмен вы получаете точное планирование ресурсов без эффекта noisy neighbors, полный контроль над NUMA-топологией процессора и предсказуемую юнит-экономику без внезапных счетов за облачный трафик. Практические схемы сборки bare-metal узлов, регламенты оптимизации сетевого стека ядра и архитектуру K3s для высоконагруженных систем мы регулярно публиуем на https://ftops.space.
Дефолтные настройки ImageGC в Kubernetes рассчитаны на гиперскейлеры и ноды с сотнями гигабайт памяти. На небольших VPS с диском 20-40 ГБ стандартный параметр imageGCHighThresholdPercent=85 выставляет смертельную ловушку: сборка мусора начинается только тогда, когда на диске остается 3-5 ГБ. В условиях интенсивного деплоя или роста ephemeral-storage локальная файловая система забивается быстрее, чем kubelet успевает запустить цикл очистки containerd. При достижении порога нода мгновенно получает taint DiskPressure. Kubelet начинает хаотично эвиктить поды, ломая консенсус K3s и переводя файловую систему бюджетного VPS в read-only из-за I/O-ограничений провайдера. Проблема усугубляется тем, что сборщик не трогает образы, созданные меньше чем imageMinimumGCAge назад (по умолчанию 2 минуты), а старые логи контейнеров не входят в зону ответственности ImageGC. Для стабильной работы мелких узлов дисковую гигиену нужно переводить в жесткий режим через конфигурацию K3s (/etc/rancher/k3s/config....
Дефолтные настройки ImageGC в Kubernetes рассчитаны на гиперскейлеры и ноды с сотнями гигабайт памяти. На небольших VPS с диском 20-40 ГБ стандартный параметр imageGCHighThresholdPercent=85 выставляет смертельную ловушку: сборка мусора начинается только тогда, когда на диске остается 3-5 ГБ. В условиях интенсивного деплоя или роста ephemeral-storage локальная файловая система забивается быстрее, чем kubelet успевает запустить цикл очистки containerd. При достижении порога нода мгновенно получает taint DiskPressure. Kubelet начинает хаотично эвиктить поды, ломая консенсус K3s и переводя файловую систему бюджетного VPS в read-only из-за I/O-ограничений провайдера. Проблема усугубляется тем, что сборщик не трогает образы, созданные меньше чем imageMinimumGCAge назад (по умолчанию 2 минуты), а старые логи контейнеров не входят в зону ответственности ImageGC. Для стабильной работы мелких узлов дисковую гигиену нужно переводить в жесткий режим через конфигурацию K3s (/etc/rancher/k3s/config.yaml): kubelet-arg: - image-gc-high-threshold=60 - image-gc-low-threshold=45 - image-minimum-gc-age=1m - eviction-hard=nodefs.available<10%,nodefs.inodesFree<5% Дополнительно зафиксируйте SystemMaxUse=1G в journald.conf и ограничьте размер логов контейнеров через max-size в containerd. На малых объемах управление памятью строится не от пиковых нагрузок, а от физической скорости выедания диска. Разбор оптимизации Bare-Metal и K3s стека читайте на https://ftops.space.
На сетевых интерфейсах 10G+ при высокоинтенсивном трафике классическая проблема фильтрации заключается не только в скорости прохождения пакета по цепочке, но и в поведении подсистемы при динамическом изменении правил. Когда автоматизированные системы защиты, IPS или сетевые контроллеры пытаются оперативно заблокировать атаки или обновить адреса, legacy-стек iptables блокирует весь пайплайн. Каждое изменение в iptables требует полного копирования монолитного массива правил из пространства пользователя в ядро через iptables mutex. На мультигигабитных каналах это приводит к сбросу кешей процессора, cache line bouncing между NUMA-узлами и микроскопическим задержкам, вызывающим потерю пакетов в сетевых очередях NIC. Архитектура nftables решает эту проблему за счет переноса логики в специализированную виртуальную машину ядра (nftvm) и применения нативных структур данных: - Атомарные транзакции: обновления передаются через netlink-сообщения коммитом конкретных элементов, без перезагрузки вс...
На сетевых интерфейсах 10G+ при высокоинтенсивном трафике классическая проблема фильтрации заключается не только в скорости прохождения пакета по цепочке, но и в поведении подсистемы при динамическом изменении правил. Когда автоматизированные системы защиты, IPS или сетевые контроллеры пытаются оперативно заблокировать атаки или обновить адреса, legacy-стек iptables блокирует весь пайплайн. Каждое изменение в iptables требует полного копирования монолитного массива правил из пространства пользователя в ядро через iptables mutex. На мультигигабитных каналах это приводит к сбросу кешей процессора, cache line bouncing между NUMA-узлами и микроскопическим задержкам, вызывающим потерю пакетов в сетевых очередях NIC. Архитектура nftables решает эту проблему за счет переноса логики в специализированную виртуальную машину ядра (nftvm) и применения нативных структур данных: - Атомарные транзакции: обновления передаются через netlink-сообщения коммитом конкретных элементов, без перезагрузки всей таблицы и без заморозки проходящего трафика. - Поиск за O(1): вместо последовательного прогона пакета по сотням правил iptables используются встроенные сеты и мапы на базе хэш-таблиц и rbtree. - Оптимизация памяти: динамические списки IP-адресов подгружаются прямо в структуры ядра без вызова пересборки графа правил. Для высоконагруженных bare-metal маршрутизаторов и пограничных узлов K3s полный отказ от iptables в пользу нативного nftables избавляет сетевой стек от просадок производительности при постоянной смене правил фильтрации. Практические разборы оптимизации сетевого стека ядра и архитектуры устойчивых сервисов выложены на https://ftops.space.
Настройка сетевого стека ядра под высокий RPS в bare-metal окружении часто превращается в карго-культ. Инженеры прописывают net.core.somaxconn = 65535 в sysctl.conf, но забывают, что ядро Linux берет минимальное значение между somaxconn и аргументом backlog в системном вызове listen(). Если Nginx, Envoy или Go-сервис скомпилирован с дефолтным backlog 512, ядро срежет очередь listen-сокета до 512. При микроспайке входящих TCP-соединений очередь переполняется, и ядро начинает молча выбрасывать SYN-пакеты, создавая искусственные таймауты у клиентов. Второй источник частых аварий — некорректная работа с TIMEWAIT сокетами при высокой плотности исходящих соединений. Параметр net.ipv4.tcptwreuse позволяет ядру повторно использовать сокеты в состоянии TIMEWAIT, но только если на обеих сторонах включены RFC 1323 timestamps через net.ipv4.tcptimestamps = 1. Если ради выигрыша CPU отключить tcptimestamps, tcptwreuse просто перестает работать, приводя к исчерпанию локальных портов (ephemer...
Настройка сетевого стека ядра под высокий RPS в bare-metal окружении часто превращается в карго-культ. Инженеры прописывают net.core.somaxconn = 65535 в sysctl.conf, но забывают, что ядро Linux берет минимальное значение между somaxconn и аргументом backlog в системном вызове listen(). Если Nginx, Envoy или Go-сервис скомпилирован с дефолтным backlog 512, ядро срежет очередь listen-сокета до 512. При микроспайке входящих TCP-соединений очередь переполняется, и ядро начинает молча выбрасывать SYN-пакеты, создавая искусственные таймауты у клиентов. Второй источник частых аварий — некорректная работа с TIME_WAIT сокетами при высокой плотности исходящих соединений. Параметр net.ipv4.tcp_tw_reuse позволяет ядру повторно использовать сокеты в состоянии TIME_WAIT, но только если на обеих сторонах включены RFC 1323 timestamps через net.ipv4.tcp_timestamps = 1. Если ради выигрыша CPU отключить tcp_timestamps, tcp_tw_reuse просто перестает работать, приводя к исчерпанию локальных портов (ephemeral port exhaustion). При этом параметр tcp_tw_recycle из ядра давно удален за порчу трафика за NAT, но до сих пор встречается в устаревших инструкциях. Даже идеальный сетевой стек бесполезен, если сервис упирается в файловые дескрипторы. Каждый сетевой сокет в Linux — это файловый дескриптор. Общий лимит sysctl fs.file-max определяет емкость всей системы, но для конкретного процесса определяющим является ulimit. В дистрибутивах с systemd параметры из limits.conf игнорируются для демонов. Без явно прописанного LimitNOFILE=1048576 в unit-файле K3s, Nginx или ingress-контроллера сервис остановит прием новых соединений с ошибкой EMFILE (Too many open files) задолго до исчерпания RAM. Правильный тюнинг ядра требует сквозного аудита: от настроек самого приложения (backlog) и лимитов systemd (LimitNOFILE) до sysctl (somaxconn, tcp_max_syn_backlog, tcp_tw_reuse) и параметров ring-буферов сетевой карты. Настройка одного параметра в отрыве от цепочки всегда приводит к падению под нагрузкой. Практические регламенты отладки bare-metal инфраструктуры и сетевого стека ядра разбираем на https://ftops.space.
Периодические задержки ответов микросервисов ровно в 5 секунд — классический симптом race condition в подсистеме netfilter Linux. В Kubernetes при отправке параллельных DNS-запросов по протоколу UDP несколько подов на одной ноде одновременно обращаются к ClusterIP сервиса CoreDNS. Таблица conntrack пытается выполнить DNAT для двух идентичных потоков до завершения инициализации записи, из-за чего ядро молча отбрасывает один из пакетов. Повторная отправка пакета клиентом происходит только по истечении пятисекундного таймаута glibc. Инженерное решение этой проблемы заключается в разворачивании NodeLocal DNSCache. Компонент запускается как DaemonSet на каждой ноде кластера и поднимает виртуальный IP-адрес (обычно 169.254.20.10) на интерфейсе loopback. Это меняет механику обработки трафика на физическом узле: - Запросы приложений перенаправляются на локальный сокет, исключая прохождение через цепочки DNAT iptables. - Для локального DNS-трафика включается правило NOTRACK в таблице raw, полно...
Периодические задержки ответов микросервисов ровно в 5 секунд — классический симптом race condition в подсистеме netfilter Linux. В Kubernetes при отправке параллельных DNS-запросов по протоколу UDP несколько подов на одной ноде одновременно обращаются к ClusterIP сервиса CoreDNS. Таблица conntrack пытается выполнить DNAT для двух идентичных потоков до завершения инициализации записи, из-за чего ядро молча отбрасывает один из пакетов. Повторная отправка пакета клиентом происходит только по истечении пятисекундного таймаута glibc. Инженерное решение этой проблемы заключается в разворачивании NodeLocal DNSCache. Компонент запускается как DaemonSet на каждой ноде кластера и поднимает виртуальный IP-адрес (обычно 169.254.20.10) на интерфейсе loopback. Это меняет механику обработки трафика на физическом узле: - Запросы приложений перенаправляются на локальный сокет, исключая прохождение через цепочки DNAT iptables. - Для локального DNS-трафика включается правило NOTRACK в таблице raw, полностью разгружая таблицу conntrack. - Связь локального кэша с центральным CoreDNS переводится на надежные постоянные TCP-соединения. При внедрении схемы на голом железе и в K3s критично соблюдать регламент настройки. Ошибки чаще всего возникают при изменении флага cluster-dns в kubelet без обновления dnsPolicy у существующих подов, а также при конфликтах с сетевыми плагинами. Если в системе используется nftables или WireGuard mesh, локальные адреса 169.254.20.10 должны быть явно исключены из маршрутизации туннеля и правил фильтрации. Низкий latency сетевого стека Kubernetes на высоком RPS достигается предсказуемостью маршрута пакета, а не бесконечным увеличением ресурсов CoreDNS. Разборы конфигураций сетевого ядра и архитектурные решения для Bare-Metal кластеров собраны на https://ftops.space.
Утренний статус и чекап инфраструктуры
Утренний health check — это не зеленая галочка в дашборде. Сначала проверяю доступность нод, затем связность WireGuard mesh и только после этого доверяю прикладным метрикам. Нода, которая отвечает на ping, но потеряла маршрут до соседей, уже неисправна.
Минимальный порядок:
- Состояние всех нод кластера и системных сервисов;
- Handshake WireGuard и возраст последнего обмена;
- Маршруты между сегментами, DNS и доступность контрольных endpoint;
- Алерты без подтвержденного recovery;
- Расхождение времени, заполнение дисков и ошибки ядра.
Главное правило — zero silent failures. Мониторинг должен показывать не только "up", но и что именно перестало работать, через какой путь и как давно. Если health check не проверяет реальный рабочий маршрут, он проверяет иллюзию доступности.
Чекап не заменяет наблюдение: после первичной проверки смотрю динамику ошибок и последние изменения конфигурации. Подробные практики отказоустойчивой инфраструктуры — https://ftops.space
#ftops #devops #linux #freebsd #sre #инфраструктура
Утренний health check — это не зеленая галочка в дашборде. Сначала проверяю доступность нод, затем связность WireGuard mesh и только после этого доверяю прикладным метрикам. Нода, которая отвечает на ping, но потеряла маршрут до соседей, уже неисправна.
Минимальный порядок:
- Состояние всех нод кластера и системных сервисов;
- Handshake WireGuard и возраст последнего обмена;
- Маршруты между сегментами, DNS и доступность контрольных endpoint;
- Алерты без подтвержденного recovery;
- Расхождение времени, заполнение дисков и ошибки ядра.
Главное правило — zero silent failures. Мониторинг должен показывать не только "up", но и что именно перестало работать, через какой путь и как давно. Если health check не проверяет реальный рабочий маршрут, он проверяет иллюзию доступности.
Чекап не заменяет наблюдение: после первичной проверки смотрю динамику ошибок и последние изменения конфигурации. Подробные практики отказоустойчивой инфраструктуры — https://ftops.space
#ftops #devops #linux #freebsd #sre #инфраструктура