Общая информация
I маршрутизация трафика c по разным номерам портов
Вы правы, причина в том, что соединение Mysql делается через TCP. Вот почему определенно невозможно иметь два одновременных подключения к двум серверам на одном и том же IP:port.
В отличие от HTTP, TCP не имеет заголовков, которые позволяют различать хост, который должен передавать трафик c быть направленным к. Тем не менее, есть по крайней мере два способа достижения функциональности, которую вы хотели бы достичь :) Я опишу это позже.
Я хочу знать, возможна ли маршрутизация на основе имени хоста или нет не требуется отдельный балансировщик нагрузки для каждой mysql службы.
K8s позволяет нескольким методам для обслуживания быть доступным вне кластера (а именно hostNetwork, hostPort, NodePort, LoadBalancer, Ingress)
LoadBalancer - это самый простой способ обслуживать трафик c на LoadBalancerIP: порт; однако из-за TCP-характера соединения вам придется использовать один LoadBalancer на один mysql экземпляр.
kind: Service
apiVersion: v1
metadata:
name: mysql
spec:
type: LoadBalancer
ports:
- port: 3306
selector:
name: my-mysql
NodePort выглядит хорошо, но позволяет подключаться только тогда, когда вы знаете порт (который может быть утомительной работой для клиентов)
Предлагаемые решения
Если существуют внешние IP-адреса, которые маршрутизируют к одному или нескольким узлам кластера, службы Kubernetes могут быть доступны на этих externalIPs. Трафик c, который входит в кластер с внешним IP-адресом (в качестве IP-адреса назначения) через порт службы, будет направлен на одну из конечных точек службы. externalIPs не управляются Kubernetes и находятся в ведении администратора кластера.
В служебной спецификации c можно указать externalIPs вместе с любым из ServiceTypes. В приведенном ниже примере клиенты могут получать доступ к mysql-1 на 1.2.3.4:3306 (externalIP:port), а клиенты mysql-2 могут получать доступ на 4.3.2.1:3306
$ cat stereo-mysql-3306.yaml
apiVersion: v1
kind: Service
metadata:
name: mysql-1234-inst-1
spec:
selector:
app: mysql-prod
ports:
- name: mysql
protocol: TCP
port: 3306
targetPort: 3306
externalIPs:
- 1.2.3.4
---
apiVersion: v1
kind: Service
metadata:
name: mysql-4321-inst-1
spec:
selector:
app: mysql-repl
ports:
- name: mysql
protocol: TCP
port: 3306
targetPort: 3306
externalIPs:
- 4.3.2.1
Примечание: необходимо иметь 1.2.3.4 и 4.3.2.1, назначенные для ваших узлов (и также разрешите mysqlServerA / mysqlserverB на mydomain.com для этих IP-адресов). Я протестировал это решение на своем кластере GKE, и оно работает :).
При такой конфигурации все запросы на mysqlServerA.mydomain.com:3306, которые разрешаются на 1.2.3.4, будут направлены на Endpoints для службы mysql-1234-inst-1 с селектором app: mysql-prod, и mysqlServerA.mydomain.com:3306 будет обслуживается app: mysql-repl.
Конечно, можно разделить эту конфигурацию на 2 пространства имен (одно пространство имен - одно mysql - одна служба на одно пространство имен).
Учитывая, что ваши mysql модули имеют ClusterIP, можно создавать дополнительные VPN-модули в кластере и подключаться к MySQL через Это.
В результате вы можете установить sh VPN-соединение и получить доступ ко всем ресурсам кластера. Это очень ограниченное решение, которое требует установки VPN-подключения для всех, кому необходим доступ к mysql.
Хорошей практикой является добавление бастионного сервера поверх этого решения. Этот сервер будет отвечать за предоставление доступа к службам кластера через VPN.
Надеюсь, это поможет.