Может ли входящий трафик Kubernetes L7 использоваться для трафика, отличного от HTTP-порта?

У меня работают два разных серверных контейнера Minecraft, оба настроены на использование TCP-порта 25565 по умолчанию. Чтобы непрофессионалы могли легко подключаться, я хотел бы иметь поддомен, выделенный для каждого сервера, скажем mc1.example.com и mc2.example .com, так что они только вводят адрес, и клиент подключается.

Для службы HTTP (s) вход NGINX L7 работает нормально, но, похоже, не работает для Minecraft. NodePort работает хорошо, но тогда для каждого сервера потребуется другой порт.

Он также установлен на голом железе - нет доступного облачного балансировщика нагрузки L4 и очень ограниченного пула IP-адресов (предположим, что их недостаточно для покрытия всех различных серверов Minecraft).

Можно ли изменить вход L7 для перенаправления mc1.example.com на правильный порт 25565 контейнера? Нужно ли мне использовать что-то вроде MetalLB?


kubernetes kubernetes-ingress nginx-ingress
person user1943640    schedule 11.02.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Он также установлен на голом железе - нет доступного облачного балансировщика нагрузки L4 и очень ограниченного пула IP-адресов (предположим, что их недостаточно для покрытия всех различных серверов Minecraft).

Если у вас недостаточно IP-адресов, то MetalLB вам не поможет, поскольку он просто использует для вас BGP для v-host, а вам придется раздавать виртуальные адреса. Основываясь на вашем описании ситуации и вашей проблемы, я рискну сказать, что вы пытаетесь сделать это дешево, и, как и следовало ожидать, сложно работать без ресурсов.

При этом сказано:

Насколько я могу судить, в современном протоколе Minecraft нет перенаправления, но, что интересно, во время рукопожатие клиент действительно отправляет имя хоста, к которому он пытается подключиться. Это может быть или не быть тем, чем пользуется BungeeCord, я не изучал его источник код.

Таким образом, теоретически возможно создать прокси виртуального хостинга для Minecraft, поскольку уже существует довольно много реализаций протокола. Но можно было бы изучить все сообщения в протоколе, чтобы убедиться, что они содержат ссылку на фактический идентификатор соединения, иначе вам пришлось бы прибегать только к (client-ip, client-port) идентификационным кортежам, эффективно превращая ваш сервер в реализацию обратного NAT / PAT. Это может быть хорошо, просто будь осторожен.

person mdaniel    schedule 11.02.2019
comment
Я ценю это - это именно то, что я искал. Я подозреваю, что пока буду использовать только NodePort, а для шуток и хихиканья постараюсь сделать более аккуратную настройку перенаправления. Спасибо! - person user1943640; 12.02.2019