Зачем сравнивать iptables и IPVS в kube-proxy
kube-proxy превращает абстракции Kubernetes Service (ClusterIP/NodePort/LoadBalancer) в правила обработки пакетов на каждой ноде. В нормальных режимах он не проксирует трафик в userspace, а программирует ядро Linux: либо через netfilter/iptables, либо через IPVS.
На небольшом кластере разница может быть незаметна. Но на нагруженных нодах (много Services/Endpoints, высокий RPS, много коротких соединений, активный NAT) выбранный режим определяет:
- сколько CPU уходит на обработку пакетов и пересборку правил;
- как быстро и «болезненно» применяются изменения Endpoints при деплоях и autoscaling;
- насколько предсказуемо ведёт себя балансировка;
- как именно вы упрётесь в
conntrack(и какие будут симптомы).
Как kube-proxy «делает» Service: общая логика
Service в Kubernetes — это виртуальный IP/порт и политика доставки трафика на набор Pod’ов (Endpoints). kube-proxy на каждой ноде настраивает dataplane так, чтобы трафик на Service попадал на один из Pod IP.
ClusterIP: доступен внутри кластера. Пакет на serviceIP:port должен быть доставлен на выбранный endpoint.
NodePort: порт на каждой ноде, который пробрасывает трафик на те же endpoints, что и ClusterIP. Важный момент: клиент может прийти на NodePort ноды, где нет ни одного Pod этого сервиса — и всё равно ожидает доставку.
Session affinity (ClientIP): попытка «приклеить» клиента к конкретному endpoint’у на заданное время.
Hairpin NAT: частый кейс, когда Pod обращается к Service, а выбранный endpoint оказывается локальным (вплоть до того же Pod). Без корректного маскарадинга легко получить «почему сервис работает извне Pod, но из Pod на свой Service — нет».
iptables mode: что происходит под капотом
iptables-режим строит цепочки netfilter и правила DNAT/SNAT, которые «переписывают» destination на выбранный endpoint. Типичный путь: попадание пакета в цепочку сервиса, затем переходы по цепочкам endpoint’ов, где выполняется DNAT на Pod IP.
Плюсы iptables-режима:
- минимальные требования к ядру и модулям;
- простая операционная модель: всё видно через
iptables-save; - стабильное поведение, особенно в окружениях без IPVS.
Минусы:
- масштабирование по числу правил: много Services/Endpoints = длинные цепочки и больше работы на пакет;
- обновления правил могут быть заметно «дорогими» при churn Endpoints (rolling update, HPA);
- балансировка вероятностная (через match/statistic), а разбор «почему выбрало этот endpoint» не всегда очевиден.
Как посмотреть, что реально запрограммировал kube-proxy (iptables)
Для диагностики почти всегда нужен полный дамп таблиц (он может быть большим, но это самая честная картинка):
iptables-saveУчитывайте, что на части дистрибутивов iptables может быть фронтом к nftables. Для отладки это важно: вывод и «ощущения» от правил могут отличаться от ожидаемых, если вы думаете в категориях legacy-iptables.
IPVS mode: чем отличается логика
ipvs-режим использует Linux IP Virtual Server: ядро хранит сущности «виртуальный сервис» и «реальные серверы» (endpoints), а балансировка работает более «нативно» и обычно эффективнее на больших списках backend’ов.
Плюсы IPVS:
- лучше масштабируется при большом количестве endpoints: меньше накладных расходов на «пробег по правилам»;
- больше алгоритмов балансировки (например, round-robin, least-conn — зависит от настроек kube-proxy);
- часто даёт более ровные задержки под нагрузкой.
Минусы и особенности:
- нужны модули ядра IPVS и связанные зависимости;
- даже в IPVS-режиме iptables полностью не исчезает: остаются правила для NodePort, MASQUERADE и служебные цепочки;
- диагностика обычно требует
ipvsadm(или эквивалентов) и привычки смотреть таблицу IPVS.
Как посмотреть таблицу IPVS
Базовая команда для чтения текущего состояния:
ipvsadm -LnЧтобы увидеть счётчики и текущую активность:
ipvsadm -Ln --stats
ipvsadm -Ln --rateПо этим данным удобно ловить перекосы: один endpoint перегружен, другой простаивает, или сервис внезапно перестал получать трафик.
Если вы параллельно используете L4-схемы вокруг сервисов (VIP/keepalived, внешний балансировщик), полезно сверить общую картину с материалом про L4-балансировку на IPVS и keepalived.
conntrack: почему он становится «бутылочным горлышком»
conntrack — подсистема stateful-трекинга соединений в netfilter. Она хранит состояния потоков (включая NAT-сопоставления) и критически важна для DNAT/SNAT, возвратного трафика и части сетевых политик.
В Kubernetes conntrack всплывает почти всегда, когда:
- много NAT (Service DNAT, masquerade для выхода из Pod network, hairpin NAT);
- много коротких соединений (HTTP без keepalive, агрессивные таймауты, частые health-check);
- много UDP (DNS, QUIC, телеметрия) с большим числом «квазисоединений»;
- нагруженные NodePort/Ingress/LoadBalancer-концентрация на 1–2 нодах.
Симптомы проблем с conntrack
- случайные таймауты на сервисах при видимой «здоровости» Pod’ов;
- рост retransmits и непредсказуемые 502/504 на входе (если есть прокси/ингресс);
- в сообщениях ядра — признаки переполнения таблицы conntrack;
- kube-proxy/ingress «как будто ни при чём», но сеть деградирует на пиках новых соединений.
Если таймауты идут «пачками» и коррелируют с всплесками новых соединений, первым делом проверяйте заполнение conntrack и его лимиты.
nf_conntrack_max: ключевой лимит и как его проверить
Главный параметр — net.netfilter.nf_conntrack_max: максимальное число записей в таблице. Когда лимит достигнут, новые записи не создаются, и часть трафика начинает отваливаться (особенно там, где нужен NAT).
Проверка текущих значений:
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_countЕсли nf_conntrack_count регулярно подходит к nf_conntrack_max на пиках, это не «случайность», а нехватка ёмкости с предсказуемыми последствиями.
Почему IPVS не «отменяет» conntrack
Частая ошибка ожиданий: «перейдём на IPVS, и conntrack перестанет быть проблемой». На практике:
- при наличии NAT conntrack всё равно участвует в обработке;
- NodePort и masquerade остаются завязаны на netfilter;
- hairpin NAT часто добавляет нагрузки из-за переписывания адресов и возвратного пути.
IPVS обычно помогает в эффективности выбора backend’а и обработке больших списков endpoints, но лимит conntrack «магически» не лечит.
NodePort, externalTrafficPolicy и сохранение client IP
Для NodePort типичная боль — сохранение IP клиента и предсказуемость маршрута. Важный параметр Service — externalTrafficPolicy:
- Cluster: трафик может уйти на любой endpoint в кластере. Часто будет SNAT на ноде, и реальный IP клиента потеряется.
- Local: трафик отправляется только на endpoints, которые есть на этой ноде. IP клиента чаще сохраняется, но появляется риск «чёрной дыры», если внешний балансировщик шлёт трафик на ноды без endpoints.
В iptables и IPVS режимах логика концептуально одинаковая, но при больших таблицах endpoints IPVS обычно проще держит производительность.
Session affinity: что реально происходит
sessionAffinity: ClientIP — это запоминание соответствия «клиентский IP → выбранный endpoint» на ограниченное время.
Практические нюансы:
- если клиентские IP скрыты за SNAT (например, приходят от одного NAT-шлюза или прокси), affinity легко превращается в перекос нагрузки;
- тайминги affinity могут конфликтовать с keepalive/idle-timeout на ingress или L4-балансировщике;
- при быстрых пересозданиях Pod’ов старые привязки могут вести к ретраям до истечения таймера.
Hairpin NAT: почему запрос «в себя через Service» иногда ломается
Hairpin NAT возникает, когда Pod обращается к Service VIP, а выбранный endpoint оказывается локальным. Без корректного SNAT/маскарадинга ответ может уйти «в обход» ожидаемого пути, получится асимметрия и соединение развалится.
Как это проявляется:
- из Pod’а не открывается сервис по ClusterIP, но напрямую по Pod IP — работает;
- плавающие таймауты только для части запросов (когда балансировка выбрала локальный endpoint);
- в дампах пакетов видно SYN, но нет корректного SYN-ACK обратно.
В таких случаях важно смотреть не только kube-proxy, но и настройки CNI и режим hairpin на стороне kubelet (в зависимости от реализации сети). На уровне kube-proxy ключевой триггер — необходимость маскарадинга для hairpin-сценариев.
Практическая диагностика: что искать в логах kube-proxy
Логи kube-proxy полезны, когда нужно понять: какой режим включён, видит ли kube-proxy endpoints, не срывается ли синхронизация правил, нет ли циклических пересборок.
Чек-лист по смыслу:
- режим (iptables или IPVS) и используемые флаги;
- ошибки при применении правил и предупреждения по модулям/таблицам;
- частота resync: если она слишком высокая, это может быть симптомом churn Endpoints;
- признаки постоянной пересборки больших наборов правил на ноде.
Если параллельно вы отлаживаете сетевые фильтры на самой ноде, может пригодиться разбор различий iptables/nftables и практик фильтрации: iptables vs nftables на хосте с контейнерами.
iptables-save и ipvsadm: как собрать «снимок» для разбора
Когда проблема плавающая, самое ценное — снимок состояния в момент инцидента. Минимальный набор команд, который обычно помогает:
date
iptables-save
ipvsadm -Ln
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_countЕсли есть подозрение на переполнение conntrack, дополнительно посмотрите сообщения ядра (journald или dmesg) в вашем окружении. Конкретные команды зависят от дистрибутива и конфигурации логирования.
Что выбрать на практике: быстрые ориентиры
Выбор режима — не религия, а набор компромиссов.
Когда iptables mode обычно достаточно
- небольшой кластер, немного сервисов и endpoints;
- умеренный трафик и мало коротких соединений;
- нужна максимально прозрачная диагностика через
iptables-save; - ограничения по ядру/модулям (минимальные образы нод).
Когда IPVS mode чаще даёт профит
- много Services/Endpoints и частые изменения (autoscaling, частые deploy);
- высокий RPS и заметная стоимость обработки пакета;
- нужна более «ровная» балансировка и статистика по backend’ам;
- вы готовы поддерживать нужные модули IPVS и инструменты диагностики.
Самые частые грабли и как их заранее проверить
Уперлись в conntrack и начались таймауты
Сведите в одну картину: nf_conntrack_max, пики nf_conntrack_count, профиль трафика (короткие соединения/UDP) и объём NAT. Если count регулярно упирается в max, лечить нужно ёмкость и первопричину генерации новых коннектов (keepalive, timeouts, health-check), а не «крутить» только kube-proxy.
NodePort «иногда работает»
Чаще всего это сочетание маршрутизации (куда реально приходит трафик), externalTrafficPolicy и наличия endpoints на конкретных нодах. Для режима Local убедитесь, что внешний балансировщик не отправляет трафик на ноды без Pod’ов сервиса.
Session affinity дала перекос
Если клиенты приходят через общий NAT или L7-прокси с одним IP, «прилипание» превращается в раздачу трафика на один endpoint. Особенно заметно при малом числе Pod’ов.
Hairpin ломает часть запросов
Если сбой воспроизводится «только когда сервис выбирает локальный endpoint», подозревайте hairpin NAT. Дальше проверяйте связку: маскарадинг kube-proxy, настройки CNI и поведение kubelet для hairpin.
Итог
iptables-режим — простой и прозрачный вариант, который хорошо живёт на малых и средних кластерах. ipvs-режим чаще выигрывает на масштабе и даёт удобную статистику, но не отменяет netfilter-реальность и не выключает conntrack.
В проде решает дисциплина диагностики: иметь команды для быстрого снимка (iptables-save, ipvsadm, nf_conntrack_max/nf_conntrack_count), понимать поведение NodePort/ClusterIP и помнить про hairpin NAT как источник самых «мистических» сетевых багов.
