В среде Kubernetes производительность и стабильность сети имеют решающее значение для обеспечения нормальной работы сервисов. Однако проблемы conntrack часто игнорируются, что приводит к ненормальным сетевым соединениям и, таким образом, влияет на нормальную работу приложений. В этой статье на практическом примере подробно описано, как обнаружить и решить проблему conntrack в среде Kubernetes, чтобы привлечь всеобщее внимание к этой проблеме.

01. Фон

Это более ранний случай. В то время, с увеличением количества микросервисов и увеличением объема запросов, в ходе мониторинга мы заметили, что в часы пиковой нагрузки на онлайн-интерфейсы поступает все больше и больше медленных запросов. иногда миллисекунды. Может возникнуть явление, когда задержка запроса превышает 1 секунду, что серьезно влияет на взаимодействие с пользователем. Чтобы решить эту проблему, мы использовали инструменты стресс-тестирования, чтобы воспроизвести ее в непроизводственной среде. Ниже приводится конкретный процесс устранения неполадок и оптимизации.

02. Запросить ссылку

В то время nginx использовался в качестве шлюза трафика для обратного прокси-сервера микросервиса. Микросервис и его шлюз работали в кластере k8s. Шлюз микросервиса был представлен в виде NodePort. Чтобы облегчить воспроизведение и устранение неполадок. поместите Pod в среду воспроизведения. Установите одну копию, ссылка доступа примерно следующая.

03. Процесс расследования и анализа

1. Сначала мы подозревали, что полоса пропускания узла заполнена. После проверки и мониторинга мы обнаружили, что трафик в норме, поэтому исключили это на время;

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

3. Я посмотрел на все показатели мониторинга nginx, и они все в норме. Они далеки от узкого места в производительности. Так почему бы нам не посмотреть? Ничего страшного, если вы его не поймаете. Как только вы его поймаете, будет много TCP Retransmission (Точек знаний):

Когда TCP отправителя не получает ответ подтверждения (ACK) в течение определенного периода времени, он считает, что пакет данных мог быть потерян или передан неудачно, и поэтому тот же пакет данных будет отправлен повторно. Этот процесс называется TCP. ретрансляция. Проще говоря, повторная передача TCP — это механизм, обеспечивающий надежную передачу данных. В Wireshark вы можете увидеть событие с надписью «Повторная передача TCP». Это означает, что отправитель отправил пакет с одним и тем же порядковым номером несколько раз, поскольку предыдущая передача не была подтверждена. Для каждой повторной передачи отправитель будет ждать в течение периода времени, называемого тайм-аутом повторной передачи (RTO), и если ACK не был получен, пакет данных будет отправлен снова. Благодаря этому механизму TCP может гарантировать, что данные в конечном итоге дойдут до места назначения даже при плохих условиях сети, обеспечивая надежность передачи данных.

4. Посмотрите на поток отслеживания (TCP Stream). Вы можете видеть, что запрос был повторно передан в вышестоящую службу примерно за 1 секунду до того, как соединение было установлено. Неудивительно, что nginx upstream занял так много времени. Причина: нам нужно продолжить изучение того, почему для этих запросов происходят повторные передачи TCP? Давайте двигаться дальше.

5. Чтобы понять причину повторной передачи TCP, нам нужно перехватить пакеты на nginx, поде и узле, где находится под. Как показано на рисунке ниже, в результатах захвата пакетов пода мы обнаружили, что под. сторона не получила первое сообщение синхронизации пакета, поэтому предполагается, что пакет может быть потерян между узлом и модулем.

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

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

7. Таблица conntrack заполнена? Причина, по которой я думаю о conntrack, заключается в том, что в процессе пересылки пакетов в Pod в режиме NodePort пакеты подвергаются преобразованию из пяти кортежей (IP-адрес источника, порт источника, IP-адрес назначения, порт назначения, протокол). Из-за большого количества запросов таблица conntrack может быть перегружена. Конечно же, как показано на рисунке ниже, мы собрали информацию о потере пакета conntrack и ошибке вставки, и виновник наконец был найден.

# Распечатать статистику contrack
conntrack -S
# Фактически, вы также можете использовать `dmesg|grep conntrack`Просмотр журнала исключений,Но указанная выше команда использовалась непосредственно в то время,Так что никаких скриншотов

04. Оптимизация задачи

Что ж, после выявления основной проблемы крайне важно оптимизировать и избежать повторения проблемы. Ниже приведены несколько идей по оптимизации:

1. Добавить узел NodePort：существоватьnginxизupstreamПовесьте еще несколькоNodePortУзлы распределяют нагрузку,Этот метод требует минимальных изменений.
2. Изменить службу на LoadBalancer：Воляserviceиз Метод доступа изменен наLoadBalancerможет быть напрямую Воля Трафик направлен наPod,Избегает пересылки через NodePort и Node,Уменьшает узкие места, вызванные пятикратным преобразованием.
3. Использование Ingress для балансировки нагрузки：удалятьnginx,Используйте Ingress для балансировки нагрузки служб.

05、Q&A

Q1：conntrackиз Каково максимальное значение？

A1：conntrackизмаксимальное значение（Параметры ядра net.netfilter.nf_conntrack_max ) — параметр, настроенный в соответствии с kube-proxy --conntrack-max-per-core * Количество ядер процессора узла рассчитывается, предполагая Значение --conntrack-max-per-core установлено равным 65536. Если узел имеет 32-ядерный процессор, максимальное значение conntrack равно 65536. * 32 = 2097152, следующий рисунок является официальным объяснением параметров kube-proxy.

Q2：conntrackизмаксимальное значениесуществоватьгде искать？

A2：Можно просмотретьnf_conntrack_maxдокумент,Инструкции следующие:

cat /proc/sys/net/netfilter/nf_conntrack_max

Q3：conntrackизмаксимальное значение如何修改？

A3：Может быть измененkube-proxyиз Параметры запуска,Или измените параметры ядра узла,Последнее обычно рекомендуется,Вот как это изменить

# Временно действует
sudo sysctl -w net.netfilter.nf_conntrack_max=2097152
# Действует постоянно
echo 'net.netfilter.nf_conntrack_max=2097152' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

06. Резюме

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

Справочные ссылки:

https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/