Маршрутизация на основе TCP-портов через nginx-вход

#nginx #kubernetes #tcp #nginx-ingress

Вопрос:

Я пытаюсь использовать свой nginx-вход, размещенный в Kubernetes, для маршрутизации TCP на основе портов.

Примечание: Я использую SSH здесь только для тестирования, но намерен использовать собственный протокол TCP позже, как только это будет решено.

Изменить: Добавлено развертывание:

 apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  labels:
    app: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
....
 

Мое определение сервиса:

 apiVersion: v1
kind: Service
metadata:
  name: test-ssh
  labels:
    app: test-ssh
spec:
  type: ClusterIP
  ports:
    - name: test-ssh
      port: 2222
      protocol: TCP
      targetPort: 22
  selector:
    app: test
 

Моя карта конфигурации tcp:

 apiVersion: v1
data:
  "2222": default/test-ssh:2222
kind: ConfigMap
metadata:
  name: nginx-ingress-nginx-tcp
  namespace: nginx-ingress
 

С узла в кластере я могу подключиться к службе:

  $ kubectl  get svc  | grep test-ssh
 test-ssh     ClusterIP   10.43.18.226    <none>        2222/TCP   16m

 $ ssh 10.43.18.226 -p2222
 The authenticity of host '[10.43.18.226]:2222 ([10.43.18.226]:2222)' can't be established.
 Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C
 

При применении сервиса я получаю нижеприведенный журнал в журналах контроллера nginx:

 controller.go:388] Service "default/test-ssh" does not have any active Endpoint for TCP port 2222
 

Это может быть состояние гонки, как если бы я описал EP после полного развертывания:

 Name:         test-ssh
Namespace:    default
Labels:       app=test-ssh
Subsets:
  Addresses:          10.42.2.24
  NotReadyAddresses:  <none>
  Ports:
    Name      Port  Protocol
    ----      ----  --------
    test-ssh  22    TCP

Events:  <none>
 

Если я попытаюсь подключиться по SSH через балансировщик нагрузки TCP, подключенный к nginx, я получу ошибку маршрутизации. Я бы ожидал, что это будет прозрачно перенаправлено на конечную точку службы:

 $ ssh x.x.x.x -p2222 -v
......
debug1: kex_exchange_identification: banner line 0: HTTP/1.1 400 Bad Request
debug1: kex_exchange_identification: banner line 1: Date: Sun, 04 Jul 2021 09:11:03 GMT
debug1: kex_exchange_identification: banner line 2: Content-Type: text/html
debug1: kex_exchange_identification: banner line 3: Content-Length: 150
debug1: kex_exchange_identification: banner line 4: Connection: close
debug1: kex_exchange_identification: banner line 5:
debug1: kex_exchange_identification: banner line 6: <html>
debug1: kex_exchange_identification: banner line 7: <head><title>400 Bad Request</title></head>
debug1: kex_exchange_identification: banner line 8: <body>
debug1: kex_exchange_identification: banner line 9: <center><h1>400 Bad Request</h1></center>
debug1: kex_exchange_identification: banner line 10: <hr><center>nginx</center>
debug1: kex_exchange_identification: banner line 11: </body>
debug1: kex_exchange_identification: banner line 12: </html>
kex_exchange_identification: Connection closed by remote host
 

В журналах контроллера nginx я получаю:

 10.42.1.0 - - [04/Jul/2021:08:47:59  0000] "SSH-2.0-OpenSSH_8.1" 400 150 "-" "-" 0 0.001 [] [] - - - - ab9dec024b834c83210af117fa95571b
 

Что я здесь упускаю?

Ответ №1:

Поделитесь развертыванием. вероятно, этикетка для pod не соответствует этикетке в сервисе.

Комментарии:

1. Я обновил и добавил развертывание в первоначальном сообщении для полноты. Я ожидал бы, что при несоответствии селектора я не смогу напрямую подключиться к службе в кластере через ClusterIP.

2. Настроен ли модуль для запуска на порту 22 в развертывании.yaml

3. Да, он работает на порту 22/tcp.

4. Находятся ли они все в одном пространстве имен nginx-ingress. Я вижу, что configmap находится в этом пространстве имен. Проверьте, находятся ли svc и pod в одном пространстве имен.

5. Да, модуль ssh и служба ssh находятся в пространстве имен по умолчанию.