Pull to refresh

Comments 4

Спасибо за обзор. В своих кластерах Вы использовали или тестировали работу IPVS, CoreDns или containerd?

Нет. Ни IPVS, ни CoreDNS, ни containerd не принесут какой-то конкретной пользы в наших кейсах.


Более того, мы несколько застряли на 1.8, но сделали это вполне осознанно — на практике, в 1.8 нас все более-менее устраивает, и мы сейчас уделяем большую часть внимания другим вопросам. Однако, так-как в 1.11 наконец-то появился online PV resizing, мы скорей всего обновимся до конца лета.


Из связанного с 1.11, мы считаем, что не так важно какой DNS, как важно его правильно поставить — если на каждое подключение к redis у нас добавляется дополнительный латенси на DNS resolve, то это прямо беда (понятно, что надо делать постоянные соединения, но замените пример с redis на что-то другое). Мы думаем над схемой, когда основной DNS стоит на каждом узле (DaemonSet) плюс запасной стоит в Deployment'е — такая схема убирает сетевой латенси, сохраняя при этом отказоустойчивость. Сделать такой вариант в отдельно взятом кластере, особенно развернутом вручную, не составляет никакого труда, а вот чтобы сделать универсальное решение, работающее в динамически масштабируемых кластерах на любом клауде и на железе, нужна возможность централизованного управления конфигами kubelet, которая в 1.11 значительно продвинулась.

А вынос redis в StatefulSet частично не решит проблему с DNS?
Интересно узнать какой cidr Вы используете в своих кластерах? В идеале бы хотелось бы в Вашем блоге почитать статью про сетевое взаимодействие в кластерах исходя из «боевого» опыта )))
отличная штука IPVS, мы её еще в 1.9 тестировали, а в1.10 даже на продакшен поставили,
но оказалось что есть небольшой нюанс: graceful termination не работает
Когда pod умирает/убивают он обрубает все connections
github.com/kubernetes/kubernetes/issues/57841#issuecomment-402007534
Sign up to leave a comment.