Снижение задержек в Kubernetes на 70% для маркетплейса ТоргОнлайн

В январе 2026 года к нам обратилась команда маркетплейса ТоргОнлайн — крупной торговой площадки с оборотом более 2 млрд рублей в месяц. Платформа обслуживала ~120 микросервисов на кластере Kubernetes из 48 узлов с 96-ядерными серверами и сетью 25 Gbps.

Проблема выглядела парадоксально: клиенты фиксировали задержку 100+ мс для каждого сотого запроса, тогда как серверная телеметрия показывала response time не выше 10 мс. Расхождение наблюдалось стабильно у 99 из 100 пар взаимодействующих сервисов.

Бизнес-последствия были существенными:

• Конверсия в покупку снижалась на 3-5% в часы пик из-за «подвисаний» UI
• SLA перед мерчантами по API-интеграциям нарушался 2-3 раза в неделю
• Команда потратила 3 месяца на безуспешные попытки решить проблему самостоятельно

Наша команда из 3 DevOps-инженеров и сетевого специалиста приступила к диагностике немедленно. Срок проекта — 4 недели, из которых 2 недели заняло расследование и 2 недели — внедрение решения.

Мы начали с анализа распределённых трейсов в Jaeger, которые уже были развёрнуты у клиента. Критически важным было то, что ТоргОнлайн не использовал head-based sampling — сохранялись все спаны, что позволило нам точно выявить паттерн так называемого client-server span gap.

Мы разработали трёхуровневую стратегию, которая полностью устранила влияние сетевых прерываний на прикладные процессы. Суть подхода — выделить отдельные CPU-ядра исключительно для обработки сетевого трафика.

Архитектура 96-ядерного сервера с двумя NUMA-нодами до и после оптимизации:

Для понимания NUMA-топологии сервера мы использовали:

# Визуализация топологии процессора
lstopo-no-graphics

# NUMA node 0: cores 0-47
# NUMA node 1: cores 48-95
# Каждая NUMA-нода имеет свой контроллер памяти

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

Для применения настройки на всех 48 узлах кластера мы написали Ansible-плейбук, который стал частью стандартной подготовки нового узла у клиента:

---
- name: Kubernetes node network IRQ isolation
  hosts: k8s_workers
  become: yes
  vars:
    nic_interface: eno1
    nic_queues: 4
    network_cores: "1-2,49-50"
    system_cores: "0,3-48,51-95"
  tasks:
    - name: Reduce NIC queue count
      command: ethtool -L {{ nic_interface }} combined {{ nic_queues }}
      
    - name: Get IRQ numbers for NIC
      shell: grep {{ nic_interface }} /proc/interrupts | awk '{print $1}' | tr -d ':'
      register: irq_numbers

    - name: Pin IRQs to dedicated cores
      copy:
        content: "{{ item.1 }}"
        dest: "/proc/irq/{{ item.0 }}/smp_affinity_list"
      loop: "{{ irq_numbers.stdout_lines | zip(['1','49','2','50']) | list }}"

    - name: Disable irqbalance
      systemd:
        name: irqbalance
        state: stopped
        enabled: no

    - name: Create cpuset for network processing
      shell: |
        mkdir -p /sys/fs/cgroup/cpuset/networkcpus
        echo "{{ network_cores }}" > /sys/fs/cgroup/cpuset/networkcpus/cpuset.cpus
        cat /sys/fs/cgroup/cpuset/cpuset.mems > /sys/fs/cgroup/cpuset/networkcpus/cpuset.mems
        echo 1 > /sys/fs/cgroup/cpuset/networkcpus/cpuset.cpu_exclusive

Плейбук применялся rolling-методом — по 4 узла одновременно — чтобы не повлиять на доступность сервисов. Каждый узел проходил через корректный drain перед настройкой.

После применения настроек на всех узлах кластера мы провели недельный мониторинг. Результаты превзошли ожидания:

Потеря 4 ядер из 96 (4.2%) на каждом узле не привела к заметному снижению ёмкости кластера — overhead был компенсирован тем, что приложения перестали терять CPU-время на обработку прерываний.

Клиент ТоргОнлайн зафиксировал рост конверсии на 2.1% в первую неделю после внедрения, что в денежном выражении составило дополнительные 42 млн рублей в месяц. Подробнее о наших подходах к оптимизации Kubernetes — на itfresh.ru.

На основе этого проекта мы составили чек-лист инструментов для диагностики сетевых задержек в Kubernetes, который теперь используем во всех аналогичных проектах:

• Jaeger — распределённый трейсинг, обязательно без head-based sampling для полноты данных
• tcpdump + Wireshark — анализ пакетов на уровне ядра, выявление буферизации
• cpudist (BCC project) — off-CPU анализ пауз с привязкой к конкретным процессам
• perf — профилирование стек-трейсов с частотой 1000 Гц для выявления прерываний
• lstopo-no-graphics — визуализация NUMA-топологии сервера
• ethtool — управление параметрами NIC, включая число очередей
• /proc/interrupts — мониторинг распределения прерываний по ядрам

# Быстрая проверка: есть ли проблема с IRQ на ваших нодах?
# Запустите на любом узле Kubernetes:

# 1. Проверить количество NIC queues
ethtool -l eno1 | grep Combined

# 2. Посмотреть распределение IRQ по ядрам
cat /proc/interrupts | head -1 && cat /proc/interrupts | grep eno1

# 3. Проверить off-CPU паузы (требует BCC)
cpudist --offcpu -p $(pgrep -f your-app) 10 1

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

Наши рекомендации для высоконагруженных Kubernetes-кластеров:

• Выделяйте CPU для сетевых IRQ на узлах с трафиком свыше 5 Gbps. Потеря 2-4 ядер окупается стабильностью латентности
• Отключайте irqbalance на production-узлах и фиксируйте IRQ affinity вручную
• Используйте guaranteed QoS и static CPU policy для latency-sensitive workloads
• Мониторьте span gap между клиентом и сервером, а не только серверное время ответа
• Инвестируйте в off-CPU профилирование — стандартный мониторинг CPU utilization не покажет проблемы с прерываниями

Мы внедрили аналогичную оптимизацию для 6 других клиентов с кластерами от 20 до 200 узлов. Во всех случаях результаты были сопоставимы: снижение p99 латентности на 60-75%.