iptables постепенно растет на узлах Kubernetes - PullRequest
0 голосов
/ 11 марта 2020

У нас есть собственный кластер Kubernetes 1.15, который работает на голом железе (Ubuntu 18.04) и состоит из 7 рабочих и 1 главного узла. У нас есть много пространств имен, и каждое пространство имен содержит более 25 различных компонентов, и некоторые из этих компонентов должны быть доступны извне через NodePort (обратный прокси-сервер для этих компонентов не подходит).

Проблема заключается в том, что Я заметил постепенное увеличение размера iptables. За 2 недели в iptables было добавлено около 400 строк без изменения компонентов, работающих в кластере, и на этих машинах больше ничего не работает. Так как это произошло до того, как я сохранил iptables, и когда я проверяю, я не вижу ничего странного внутри iptables, это просто нормальные правила, необходимые для кластера. Большой iptable может вызвать много проблем, включая сброс сетевых пакетов, и я ищу решение для этого.

Я заметил этот пост в блоге Kubernetes, но это всего лишь инструмент отслеживания, а не инструмент, который решает проблему : https://kubernetes.io/blog/2019/04/19/introducing-kube-iptables-tailer/

1 Ответ

0 голосов
/ 11 марта 2020

Что именно вас беспокоит?

  • Это размер iptables?
  • Есть ли у вас проблемы с производительностью при планировании новой службы (т. Е. Это занимает много времени для вашей службы для получения IP)?

Если это просто размер, то этого следует ожидать, когда вы начнете иметь сотни пакетов / сервисов. Именно так работает iptable.

Если это проблема с производительностью, то это означает, что у вас, вероятно, тысячи компонентов. Если это так, Kubernetes 1.11 представил IPVS для решения этой проблемы.

В любом случае, я предлагаю вам взглянуть на эти две статьи:

  1. https://kubernetes.io/blog/2018/07/09/ipvs-based-in-cluster-load-balancing-deep-dive/
  2. https://www.projectcalico.org/comparing-kube-proxy-modes-iptables-or-ipvs/

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

...