kubernetes на gke / почему принудительно используется балансировщик нагрузки?

Я попал в кубернеты через GKE, сейчас пробую через kubeadm на голом металле.

В более поздних версиях нет необходимости в каком-либо конкретном балансировщике нагрузки; использование nginx-ingress и ingress позволяет обслуживать www.

Напротив, в gke, используя тот же nginx-ingress или используя предоставленный gke l7, вы всегда получаете платный балансировщик нагрузки.

В чем причина того, что в конечном итоге это оказалось не нужно?


kubernetes google-cloud-platform kubernetes-ingress google-kubernetes-engine
person Ben    schedule 14.02.2018    source источник
comment
Привет! Кажется, вы запутались при балансировке нагрузки на уровнях 3, 4 и 7. Следующая статья может дать вам представление о современная балансировка нагрузки и проксирование   -  person Suresh Vishnoi    schedule 14.02.2018
comment
Хм ... Я достаточно квалифицирован, чтобы использовать все, но, откровенно говоря, мои мозговые клетки не организованы, чтобы понимать, что лежит в основе этих сетевых тем. Я прочитал статью; Я могу понять преимущества использования L7, но не могу понять причину, по которой такое дополнение применяется в gke.   -  person Ben    schedule 14.02.2018
comment
Как правило, при получении трафика из внешнего мира этот трафик будет отправлен на один или несколько общедоступных IP-адресов, не относящихся к ACLd. Если вы запускаете k8s на «голом металле», эти BM могут иметь общедоступные IP-адреса, и вы можете просто запустить ingress на одном или нескольких из них. Однако управляемая среда k8s из соображений безопасности не позволяет узлам иметь общедоступные IP-адреса. Вместо этого управляемые балансировщики нагрузки могут иметь общедоступные IP-адреса. Они настроены так, чтобы знать IP-адреса частных узлов, принимающих входящие данные для вашего кластера, и соответственно направлять трафик.   -  person Jonah Benton    schedule 14.02.2018
comment
Привет, @Jonah B, ваш комментарий кажется прекрасным, если он опубликован как полный ответ. Пожалуйста, сделай.   -  person Fady    schedule 14.02.2018
comment
Есть способ полностью пропустить балансировщик нагрузки, см. serverfault.com/questions/863569/ Не рекомендуется для серьезного производственного использования. Штраф за бедные решения.   -  person Jonathan Lin    schedule 28.12.2018

Ответы (2)


arrow_upward
0
arrow_downward

Сервисы Kubernetes имеют несколько типов, каждый из которых основан на предыдущем: ClusterIP, NodePort и LoadBalancer. Только последний будет инициализировать LoadBalancer в облачной среде, поэтому вы можете избежать его использования в GKE без фаззинга. Вопрос в том, что тогда? Потому что в лучшем случае вы получите Ingress (я предполагаю, что мы предоставляем вход, как в вашем вопросе), который доступен на изменчивых IP-адресах (узлы можно свернуть в любое время, а новые получат новые IP-адреса) и высоких портах, предоставленных Сервис NodePort. Это означает, что у вас не только нет фиксированного IP-адреса, но вам также нужно открыть что-то вроде http: //: 31978, что явно чушь. Следовательно, в облаке у вас есть простое решение - поставить перед ним облачный балансировщик нагрузки с типом службы LoadBalancer. Этот LB будет принимать трафик на порт 80/443 и перенаправлять его в исправную службу поддержки / поды.

person Radek 'Goblin' Pieczonka    schedule 15.02.2018
comment
спасибо, что многое проясняет. @Suresh Vishnoi комментировал выше по этой ссылке блог .envoyproxy.io /; звучит так, как будто L7 улучшает производительность (по сравнению с «голым железом»), но все же я в этом не уверен; Есть ли какие-то недостатки, не использующие облачные провайдеры? - person Ben; 15.02.2018
comment
зависит от того, что вы имеете в виду, говоря об использовании облачных провайдеров. Если вы имеете в виду те, которые находятся внутри кубернетов, то у вас всегда должен быть включен облачный провайдер для вашего облака, которое вы используете. В большинстве случаев система инициализации сделает это за вас. Это дает вам не только такие вещи, как автоматическая поддержка LB-сервисов, но и, например, предоставление томов. На baremetal вам обычно нужно предоставить какое-то решение самостоятельно или имитировать обычный набор функций kube (то есть, не поддерживая сервисы LB вообще, а просто открывая все с помощью предопределенного контроллера Ingress) - person Radek 'Goblin' Pieczonka; 15.02.2018
comment
Нет, я имею в виду при обслуживании сайтов / услуг для внешнего мира. Например, когда на gke; предлагает ли их балансировщик нагрузки верхнего уровня (а не kube) улучшения сети и тому подобное ... или такие соображения все еще присутствуют в nginx (хотя вы используете проект nginx ingress)? - person Ben; 15.02.2018
comment
Проще говоря; на голом металле, как вы говорите, я имитирую, открывая через заранее определенный вход. Тем не менее, мои сайты / услуги по-прежнему обслуживаются. Но похоже, что есть разница, и это то, что я не совсем понимаю; так как конечный результат такой же. Я получаю часть безопасности; но есть ли какая-то другая добавленная стоимость? - person Ben; 15.02.2018

arrow_upward
3
arrow_downward

(Повторная публикация моего комментария выше)

В общем, когда кто-то получает трафик из внешнего мира, этот трафик отправляется на один или несколько общедоступных IP-адресов, не относящихся к ACLd.

Если вы запускаете k8s на «голом металле», эти BM могут иметь общедоступные IP-адреса, и вы можете просто запустить ingress на одном или нескольких из них.

Однако управляемая среда k8s из соображений безопасности не позволяет узлам иметь общедоступные IP-адреса.

Вместо этого управляемые балансировщики нагрузки могут иметь общедоступные IP-адреса. Они настроены так, чтобы знать IP-адреса частных узлов, принимающих входящие данные для вашего кластера, и соответственно направлять трафик.

person Jonah Benton    schedule 14.02.2018