Вот в K8S обычно одна точка входа. Т.е. 1 точка входа для HTTP-трафика — это сервер с конкретным IP-адресом, который уже балансирует нагрузку и распределяет дальше.
Бывают ли схемы где точка входа не одна и как они работают? Только лишь на уровне DNS, когда DNS отдает несколько IP-адресов — разных точек входа? Или же есть и другие схемы?
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос.
S>Вот в K8S обычно одна точка входа. Т.е. 1 точка входа для HTTP-трафика — это сервер с конкретным IP-адресом, который уже балансирует нагрузку и распределяет дальше.
S>Бывают ли схемы где точка входа не одна и как они работают? Только лишь на уровне DNS, когда DNS отдает несколько IP-адресов — разных точек входа? Или же есть и другие схемы?
В k8s точка входа извне обеспечивается сервисом с типом LoadBalancer. За ним крутится объект k8s Ingress, который, по сути pod, в котором (если просто) реализуется логика Gateway. Сколько LoadBalancer-ов создашь, столько и будет точек входа. А в Ingress-ах реализуешь логику каждой из них так, как тебе нужно. Только имей в виду, чо обычо провайдер managed k8s тарифицирует каждый LoadBalancer.
Здравствуйте, Shmj, Вы писали:
S>Бывают ли схемы где точка входа не одна и как они работают? Только лишь на уровне DNS, когда DNS отдает несколько IP-адресов — разных точек входа? Или же есть и другие схемы?
У тебя вопрос слишком общий, не очевидно о чём спрашиваешь.
Бывает можно сразу несколько адресов указать, в качестве точки входа (допустим в elasticsearch) — сам клиент занимается выбором конкретного.
Может стоять железка (load balancer) или сервер (например nginx), переадресующий запросы на множество других адресов.
Один и тот же IP адрес может быть быть одновременно у нескольких железок, это протоколы типа VRRP, CARP.
Может быть DNS в виде round robin или несколько имен вроде a.dns.example, b.dns.example, c.dns.example со случайным выбор самим приложением.
Может быть многомаршрутная маршрутизация (manycast), когда из множества железок с одинаковым IP выбирается одна на уровне маршрутизации.
Может быть любое сочетание всего этого.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Doom100500, Вы писали:
S>LoadBalancer-ы в итоге как представлены для мира — в виде некого одного IP-адреса? Или для каждого LoadBalancer-а свой IP?
Каждый LoadBalancer — это свой белый IP Address, а дальше провайдер решает (или ты сам, если ты — провайдер (как минимум для себя)).
Попробую потелепатировать: нет, не получится создать LoadBalancer и не заплатить за это (если managed k8s)
Здравствуйте, m2l, Вы писали:
m2l>Бывает можно сразу несколько адресов указать, в качестве точки входа (допустим в elasticsearch) — сам клиент занимается выбором конкретного.
Каким образом "клиент занимается выбором", допустим если это сайт? Через DNS-сервер?
m2l>Может стоять железка (load balancer) или сервер (например nginx), переадресующий запросы на множество других адресов.
Но это одна железка — сколько запросов в секунда она способна обработать?
m2l>Один и тот же IP адрес может быть быть одновременно у нескольких железок, это протоколы типа VRRP, CARP.
А кто занимается ресолвингом/балансировкой и каковы его разрешающие способности? Т.е. опять же — сколько будет держать запросов?
m2l>Может быть многомаршрутная маршрутизация (manycast), когда из множества железок с одинаковым IP выбирается одна на уровне маршрутизации.
Занимается выбором 1 локальный маршрутизатор? Какова его пропускная способность?
Здравствуйте, Doom100500, Вы писали:
D>Каждый LoadBalancer — это свой белый IP Address, а дальше провайдер решает (или ты сам, если ты — провайдер (как минимум для себя)).
А провайдер как соединяет множество LoadBalancer в одну точку входа? И какова цена этого — т.е. если соединим, допустим, 100 разных LoadBalancer в одну точку входа — сколько соединялка сможет обработать и раскидать запросов в секунду?
Здравствуйте, Shmj, Вы писали:
S>Каким образом "клиент занимается выбором", допустим если это сайт? Через DNS-сервер?
Про dns round-robin я отдельной строкой написал. Клиент — значит клиент. Список адресов в коде, делаем запрос к случайному из них. Не получилось — делаем запрос к следующему случайно выбранному.
m2l>>Может стоять железка (load balancer) или сервер (например nginx), переадресующий запросы на множество других адресов. S>Но это одна железка — сколько запросов в секунда она способна обработать?
Смотря какая железка, если что-то более-менее разумное, то в пределах 40-120 Гбит/с. И там не важно сколько запросов внутри этих гбит.
m2l>>Один и тот же IP адрес может быть быть одновременно у нескольких железок, это протоколы типа VRRP, CARP. S>А кто занимается ресолвингом/балансировкой и каковы его разрешающие способности? Т.е. опять же — сколько будет держать запросов?
Зависит от протокола. Поскольку они должны быть внутри одного VLAN, то ограничено по сути скоростями интерфейсов сетевого оборудования. В среднем те-же 40-120 Гбит/с.
m2l>>Может быть многомаршрутная маршрутизация (manycast), когда из множества железок с одинаковым IP выбирается одна на уровне маршрутизации. S>Занимается выбором 1 локальный маршрутизатор? Какова его пропускная способность?
Этим занимаются все маршрутизаторы входящие в состав интернета. Пропускная способность не ограничена. Хоть весь трафик мира.
Но обычно используется, не когда очень хочется на один IP влить больше условных 100-200 Гбит/с (в виду большого числа доступных инструментов обычно это иррационально), а когда хочется отказоустойчивости и резервирования.
Здравствуйте, m2l, Вы писали:
m2l>Про dns round-robin я отдельной строкой написал. Клиент — значит клиент. Список адресов в коде, делаем запрос к случайному из них. Не получилось — делаем запрос к следующему случайно выбранному.
Про DNS — принимается.
m2l>>>Может стоять железка (load balancer) или сервер (например nginx), переадресующий запросы на множество других адресов. S>>Но это одна железка — сколько запросов в секунда она способна обработать? m2l>Смотря какая железка, если что-то более-менее разумное, то в пределах 40-120 Гбит/с. И там не важно сколько запросов внутри этих гбит.
Важно сколько запросов — ведь каждый запрос — это еще и служебные данные, помимо тела.
Давайте рассмотрим 120 Гбит/с. Если каждый запрос — 1 Мб (что не так много по нашим меркам), то получится 15 тыс. запросов в секунду. А что если нужно больше? Только балансировка на уровне DNS без вариантов?
Здравствуйте, Shmj, Вы писали:
S>>>Но это одна железка — сколько запросов в секунда она способна обработать? m2l>>Смотря какая железка, если что-то более-менее разумное, то в пределах 40-120 Гбит/с. И там не важно сколько запросов внутри этих гбит.
S>Важно сколько запросов — ведь каждый запрос — это еще и служебные данные, помимо тела. S>Давайте рассмотрим 120 Гбит/с. Если каждый запрос — 1 Мб (что не так много по нашим меркам), то получится 15 тыс. запросов в секунду.
На таких скоростях — сколько запросов уже не важно. Тем более, если брать твои умозрительные запрос в 1 Мб. Разница была бы на запросах/ответах измеримых десятками/сотней байт — тогда эта характеристика была бы важна.
S>А что если нужно больше? Только балансировка на уровне DNS без вариантов?
Отчего вариант anycast маршрутизации отбрасываешь?
Есть железки на 400 Гбит/с, если сильно хочется.
Но по нормальному, на один IP адрес такой трафик в здравом уме не заворачивают (за исключением anycast-та).
Здравствуйте, Shmj, Вы писали:
S>А провайдер как соединяет множество LoadBalancer в одну точку входа? И какова цена этого — т.е. если соединим, допустим, 100 разных LoadBalancer в одну точку входа — сколько соединялка сможет обработать и раскидать запросов в секунду?
Никто не объединяет 100 LoadBalancer-ов в одну точку входа. Каждый LoadBalancer — это отдельная точка входа со своим уникальным IP адресом. За LoadBalancer (который по сути объект Service) крутится Ingress (который по сути Pod). И как любой Pod, Ingress — это твой объект с твоей конфигурацией (если это, например nginx) или твоим кодом (если, например, ты хочешь его реализовать сам) он и занимается маршрутизацией трафика от LoadBalancer-a. У него может быть несколько реплик, может быть настроено автомасштабирование и всё такое.
А k8s — это не о железе, а о том, чтобы ты о железе не думал. Если автомасштабирование настроено, то при возростании нагрузки создаются новые реплики твоих Pod-ов, Deployment-ов, Ingress-ов и всего, что ты там наплодил. Реплики создаются на виртуальных машинах. Если виртуалки кончились, то создаётся новая виртуалка и т.д.
С этим ты можешь теоритически держать бесконечную нагрузку, только на бабло влетишь.
Ты настраивешь у провайдера какие виртуальные машины создавать, сколько ресурсов нужно твоим подам (память, процессор) и максимальное количество реплик.
Чтобы определиться с тем как настроить ресурсы для подов, у k8s есть режим, который собирает статистику и выдаёт рекомендации.
Ну и не надо забывать, что всё это виртуалки, а как проваидер их выделяет — это провайдерское.
На своём железе — это выглядит как одна или несколько мастер нода, и пул воркеров. — вот на воркерах всё и бежит. A k8s можешь считать операционной системой, которая запускает процессы на этом кластере. Т.е. нет никакой отдельной железки, отвечающей за LoadBalancer.
Здравствуйте, Shmj, Вы писали:
S>Вот в K8S обычно одна точка входа. Т.е. 1 точка входа для HTTP-трафика — это сервер с конкретным IP-адресом, который уже балансирует нагрузку и распределяет дальше.
Нет.
S>Бывают ли схемы где точка входа не одна
Бывают.
S> и как они работают?
В чем проблема?
S>Только лишь на уровне DNS, когда DNS отдает несколько IP-адресов — разных точек входа? Или же есть и другие схемы?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, m2l, Вы писали:
m2l>>Про dns round-robin я отдельной строкой написал. Клиент — значит клиент. Список адресов в коде, делаем запрос к случайному из них. Не получилось — делаем запрос к следующему случайно выбранному.
S>Про DNS — принимается.
Мультикасты — аналогично. Кричишь в сеть "эй, кто тут умеет делать <something>", и тебе ответы сыпятся с хостов "я, я, я...", только успевай адреса ответивших в блокнотик записывать (например, так работает service discovery в UPnP)
Здравствуйте, Mr.Delphist, Вы писали:
MD>Мультикасты — аналогично. Кричишь в сеть "эй, кто тут умеет делать <something>", и тебе ответы сыпятся с хостов "я, я, я...", только успевай адреса ответивших в блокнотик записывать (например, так работает service discovery в UPnP)
Только ограничено пропускной способностью маршрутизатора, который контролит эту сеть. Через него идет 100% весь трафик.
А вот через DNS можно разнести географически и к нему делается запросы редко (запросы/ответы короткие, происходят только в начале — далее кэшируются), трафик через него не идет.