использование Kube-прокси для балансировки нагрузки

Question

В официальных документах kubernetes четко указано, что kube-proxy "не будет масштабироваться до очень больших кластеров с тысячами служб" , однако при LoadBalancer Служба типа создается в GKE, externalTrafficPolicy по умолчанию имеет значение Cluster (это означает, что каждый запрос будет сбалансирован нагрузкой с помощью kube-proxy в дополнение к внешней балансировке нагрузки). Как объясняется, например, в этом видео из Next '17 , это позволяет избежать дисбаланса traffi c (поскольку внешние балансировщики нагрузки Google не способны запрашивать у кластера, сколько модулей данной службы на каждом узле).

Отсюда возникает вопрос: означает ли это, что:

a) по умолчанию GKE не может использоваться для «очень больших кластеров с тысячами сервисов», и для этого мне нужно рискнуть трафиком c дисбалансы путем установки externalTrafficPolicy в Local

b) ... или информация о плохой масштабируемости kube-proxy неверна или устарела

c) ... или что-то еще, что я не смог придумать

Спасибо!

Answer 1

Цитата

will not scale to very large clusters with thousands of services относится к прокси пользовательского пространства, который долгое время находился в режиме по умолчанию за go до полной реализации на основе iptables. Так что это утверждение в значительной степени устарело, но ...

В режиме iptables есть свои проблемы, связанные с масштабированием (очень большие цепочки правил iptables требуют много времени для обновления), что является одной из причин, почему IPVS работает сделал это в Kube-прокси. Чтобы столкнуться с проблемами с производительностью kube-proxy, вам понадобится действительно жесткая шкала.

Answer 2

Согласно официальной документации Kubernetes о externalTrafficPolicy ответом является a).

Поскольку параметр кластера скрывает IP-адрес источника клиента и может вызвать второй прыжок для другой узел, но должен иметь хорошее общее распределение нагрузки , а локальная опция сохраняет исходный IP-адрес клиента и избегает второго перехода для служб типа LoadBalancer и NodePort, но рискует потенциально несбалансированным трафиком c распространение.