Как создать внутреннюю/частную подсистему балансировки нагрузки в Google, вычисляют механизм
У меня есть два кластера. Кластеризируйтесь (на механизме контейнера Google), общедоступный кластер, и он должен соединиться с частным Кластером B (click-deploy кластер на GCE) для доступа к сервису. Я хотел бы иметь, Кластеризируют подключение для Кластеризации B через подсистему балансировки нагрузки, и это может работать даже при том, что кажется, как будто все подсистемы балансировки нагрузки GCE требуют общедоступного IP-адреса https://groups.google.com/d/topic/gce-discussion/Dv6289i4_rg/discussion (я предпочел бы, если бы это было все частным).
Общедоступный IP-адрес не так плох отдельно, если Вы могли бы просто установить простое правило брандмауэра и использовать стандартный Google Load Balancer. К сожалению, исходные теги, кажется, не пересекают порог WAN (или просто не передаются подсистемой балансировки нагрузки). Это - правило, что я хотел бы использовать:
gcloud compute firewall-rules create servicename-lb-from-gke-cluster --allow tcp:1234 --source-tags k8s-gke-cluster-node --target-tags servicename #DOES NOT WORK
После ввода вышеупомянутой команды Кластер A не может связаться с Кластером B (через подсистему балансировки нагрузки) через tcp порт 1234.
Это действительно работает, но это болезненно, потому что это требует, чтобы контроль автоматизировал установку общедоступных IP-адресов исходного кластера:
gcloud compute firewall-rules create servicename-lb-from-gke-cluster --allow tcp:1234 --source-ranges 100.2.3.4/32 100.3.5.9/32 100.9.1.2/32 --target-tags servicename #Does work, but is painful
Как предложено в потоке групп Google, прокси HA является другим предложением.
Другая идея состоит в том, чтобы открыть брандмауэр всей WAN и добавить безопасную аутентификацию между кластером A и B. Возможно, это - хорошая идея сделать из соображений безопасности так или иначе? Трудность может расположиться от легкого до трудно в зависимости от того, что выполняет кластер A и B, хотя - могло бы быть хорошо иметь более общее решение.
У кого-либо есть лучшая идея? У кого-либо еще есть та же проблема?
Теперь это возможно с официальным GCP Internal LB : https://cloud.google.com/compute/docs/load-balancing/internal/
В частности, вот документация kubernetes (GKE): https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing
Обратите внимание на аннотацию службы:
annotations:
cloud.google.com/load-balancer-type: "Internal"
Обратите внимание, что хотя этот LB уже доступен только для внутреннего использования, если вы хотите дополнительно ограничить, например, с модулями кластера можно сделать что-то вроде этого:
loadBalancerSourceRanges: 10.4.0.0/14
Чтобы получить диапазон IP-адресов модуля, вы можете запустить:
Кластеры контейнеров gcloud описывают $ CLUSTER_NAME | grep clusterIpv4Cidr
Прошу прощения за сложность! Я не эксперт по брандмауэрам Compute Engine, но полагаю, что вы правы насчет ограничений исходных тегов, которые работают только для внутреннего трафика.
Команда Kubernetes осознает, что координация нескольких кластеров затруднена, и мы мы начинаем работать над решениями, но, к сожалению, у нас пока нет ничего особенно надежного и полезного для вас.
Между тем, существует хитрый способ балансировки нагрузки трафика от одного кластера к другому без необходимости использования Google Cloud Load Balancer или что-то вроде haproxy. Вы можете указать внутренний IP-адрес одного из узлов в кластере B (или IP-адрес маршрута GCE, который направляет трафик на один из узлов в кластере B) в поле PublicIPs службы, которую вы хочу поговорить. Затем попросите кластер A отправить свои запросы на этот IP-адрес на порт службы, и они будут сбалансированы по всем модулям, поддерживающим службу.
Это должно работать, потому что на каждом узле сервера работает нечто, называемое прокси-сервером kube. кластер kubernetes, который автоматически проксирует трафик, предназначенный для IP-адреса службы, и переносит на поды, поддерживающие службу. Пока PublicIP находится в определении службы, kube-proxy будет балансировать трафик за вас.
Если вы остановитесь здесь, это будет настолько надежно, насколько надежен узел, IP-адрес которого вы отправляете (но с одним - надежность узла на самом деле довольно высока). Однако, если вы хотите по-настоящему фантазировать, мы можем сделать вещи немного более надежными, балансируя нагрузку с кластера A на все узлы в кластере B.
Чтобы это сработало, вы должны поместить все узлы кластера B ' внутренние IP-адреса (или маршруты ко всем внутренним IP-адресам узлов) в поле PublicIPs вашей службы. Затем в кластере A вы можете создать отдельную службу с пустым селектором меток и заполнить в нем поле конечных точек вручную, когда вы создаете его с парой (IP, порт) для каждого IP в кластере B. Селектор пустой метки предотвращает инфраструктура kubernetes от перезаписи ваших вручную введенных конечных точек, и kube-proxy в кластере A будут балансировать нагрузку трафика для службы через IP-адреса кластера B. Это стало возможным благодаря PR # 2450 , если вам нужен более подробный контекст.
Дайте мне знать, если вам понадобится дополнительная помощь в этом!