Kubernetes, как сбалансировать нагрузку ВНЕШНИЕ постоянные соединения TCP? - PullRequest
Новая
       128

Kubernetes, как сбалансировать нагрузку ВНЕШНИЕ постоянные соединения TCP?

0 голосов
/ 01 марта 2020

У меня проблема с балансировкой нагрузки постоянных tcp-соединений с моими репликами kubernetes.

У меня есть клиенты Unity3D за пределами кластера kubernetes.

Мой кластер представляет собой кластер baremetal с MetallB установленный состоит из 3 узлов: 1 мастер и 2 рабочих.

Как я прочитал, есть два подхода:

1) клиент подключается ко всем репликам и каждый раз, когда ему нужно отправить запрос он будет делать это по случайному соединению из тех, которые он установил ранее. Периодически он обновляет соединения (в случае, если произошло автоматическое масштабирование или умерли некоторые из постоянных соединений).

Проблема здесь в том, что я не уверен, как получить доступ ко всем репликам извне, внешние службы не могут быть доступны извне.

2) обслуживать меня sh? Я смутно прочитал / понял, что они могут установить sh постоянный протокол TCP от вашего имени. Так что-то вроде этого:

Unity3D клиент <---- постоянное соединение ---> контроллер <--- постоянное соединение ----> реплики

Однако я не уверен как это сделать sh, и я не уверен, что произойдет, если сам контроллер выйдет из строя, все клиенты потеряют свои соединения? На мой взгляд, это приведет к той же проблеме, что и проблема из пункта 1), которая позволяет клиенту подключаться к нескольким различным репликам одновременно с постоянным соединением TCP.

Часть вопроса в дополнение к этому: https://learnk8s.io/kubernetes-long-lived-connections

1 Ответ

2 голосов
/ 02 марта 2020

Чтобы включить внешний трафик c для вашего кластера, вам нужен Ingress Gateway. Ваш входной шлюз может быть стандартным nginx Ingress , шлюзом, предоставленным me sh, таким как Istio Gateway , или более специализированным пограничным шлюзом, таким как ambassador , traefik , kong, gloo, et c.

В K8s можно выполнить балансировку нагрузки как минимум двумя способами:

  1. Использование Service ресурса, который является просто набором правил iptables, управляемых процессом kube-proxy. Это только балансировка нагрузки L4. Протоколы приложений L7, такие как HTTP2 или gRP C, не поддерживаются. В зависимости от вашего случая этот тип LB может быть не идеален для долгоживущих соединений, так как соединения редко закрываются.

  2. Использование балансировки нагрузки L7, предлагаемой любым из входов контроллеры , которые будут пропускать маршрутизацию iptables (используя безголовую службу) и позволят использовать более продвинутые алгоритмы балансировки нагрузки.

Чтобы воспользоваться последним случаем, вам все равно необходимо убедиться, что что соединения в конечном итоге разрываются, что часто делается от клиента к прокси (при повторном использовании соединений от прокси до восходящего потока). Я не знаком с соединениями Unity3D, но если их отключение не подходит, вы не сможете выполнить большую нагрузку в конце концов.

Когда контроллер выйдет из строя, соединения будут сброшены, и ваш клиент может либо любезно повторите попытку подключения или pani c. Это зависит от того, как вы его кодируете.

...