В нашей облачной конфигурации Google (с поддержкой Kubernetes) для нескольких проектов, рабочих нагрузок и сервисов (балансировщиков нагрузки) мы специально настраиваем балансировщики нагрузки, но конфигурация, похоже, меняется.
Мы специально добавляем узлы в наши балансировщики нагрузки, через некоторое время все наши узлы (из разных пулов) в конечном итоге присоединяются к все наши балансировщики нагрузки. После того, как они были волшебным образом добавлены обратно в балансировщик нагрузки, мы удаляем их (снова), а затем, через некоторое время, все они возвращаются.
Я понимаю, что во многих случаях отсутствует информация о реализации, но я надеялся, что есть какие-то хорошо известные шаблоны, которым, по мнению некоторых, мы могли не следовать. Я постараюсь опубликовать детали конфигурации.
Когда вы используете вручную созданные балансировщики нагрузки в Google Cloud с Kubernetes Services и type: NodePort, это почти то же самое, что вы используете type: Load Balancer для ваших сервисов, но во втором случае LB создается и управляется Kubernetes, и вам не нужно об этом заботиться.
Так как Service с типом NodePort является адресом привязки на всех ваших узлах, они должны быть добавлены в LB как бэкэнд. Проверить документация, путь «Прокси-режим: iptables». Возможно, в вашей ситуации Kubernetes пытался управлять им и добавил все ваши узлы в LoadBalancers, потому что они обрабатывают запросы к его сервисам. На самом деле я не встречал установок, где LoadBalancers создавались вручную и указывали на Kubernetes.
В Google Cloud я настоятельно рекомендую вам использовать Ingress (на основе Google Load Balancer или Nginx) или Сервисов с type: Load Balancer, если вам не нужна специальная маршрутизация.
Вы можете реализовать это так (для Nginx Ingress):
Nginx Ingress Controller с сервисом type: LoadBalancer. Он создаст для вас LoadBalancer в качестве точки входа для всего вашего трафика.Service с участием type: ClusterIP.Service и напишите туда все свои правила маршрутизации.