Альтернативное решение для сети хост-портов, позволяющее запускать несколько модулей в Kubernetes

Question

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

Мне понятны две вещи: 1. Мне нужно добавить больше реплик pod & 2. Я не могу использовать входной контроллер (необходимо иметь отдельный внешний IP).

Другие сведения:

• Я использую внешний IP-адрес (быстрое решение - это сервис LB)
• Когда я включаю хост-порт в Kubernetes, все работаеткак талисман
• Я использую один сертификат tls, который хранится в PVC, который будет разделен между моими модулями.
• Когда я отключаю порт хоста, увеличиваю количество реплик и притворяюсь, что он долженработают, модули запускаются успешно, но приложение не может быть достигнуто так, как я обычно его достигаю, как будто оно никогда не слышит, что исходит от пользователя через loadbalancer (поэтому я подумал, что настройка NAT может иметь какое-то отношение крешение ??)

Вещи, которые я пробовал:

• Используйте NodePort, чтобы представить containerPort и добавить реплики (и, возможно, затем настроитьвход для loadbalancлуг).Проблемы с этим: порт, который я пытаюсь сопоставить с хостом, - 80, и это вне диапазона.Мне нужно разрешить TCP и UDP через, что потребует создания 2 отдельных сервисов, каждый с различным nodePort.
• Укажите любой возможный порт, о котором я могу подумать, который мог бы использоваться через службу Loadbalancer.Проблема в том, что пользователь по какой-то причине не может получить доступ к приложению.

Мои файлы yaml выглядят примерно так:

deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: x
  name: x
  labels:
    app: x
spec:
  replicas: 1
  selector:
    matchLabels:
      app: x
  template:
    metadata:
      labels:
        app: x
    spec:
      # hostNetwork: true
      containers:
      - name: x
        image: x
        env:
        ...
        volumeMounts:
        ...
        ports:
        - containerPort: 80
      volumes:
      ...
      imagePullSecrets:
      - name: x

service.yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: x
  namespace: x
  name: x
spec:
  type: LoadBalancer
  loadBalancerIP: x
  ports:
  - name: out
    port: 8081
    targetPort: 8081
    protocol: TCP
  - name: node
    port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: x
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: x
  namespace: x
  name: x
spec:
  type: LoadBalancer
  loadBalancerIP: x
  ports:
  - name: out
    port: 8081
    targetPort: 8081
    protocol: UDP
  - name: node
    port: 80
    targetPort: 80
    protocol: UDP
  selector:
    app: x

Проблема Что такое наилучшая практика / решение для безопасной замены сетевого соединения хост-порта?

Answer 1

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

1.Сопоставить containerPort с hostPort

Этот метод немного лучше, чем сетевое соединение с хостом, поскольку он требует только очень специфических портов на хосте.

Преимущества: несколько модулейтеперь могут использовать хост-порты ДОЛГО КАК они используют разные хост-порты.Другое преимущество состоит в том, что вы можете использовать порты практически в любом диапазоне, например, ниже 1000 и т. Д.

Недостатки: несколько модулей в одном развертывании или Statefulset все еще не могут сосуществовать с этимконфигурации, поскольку они будут использовать один и тот же порт хоста.Таким образом, ошибка «порт узла недоступен» будет сохраняться.

deploy.yaml

   ...
    - containerPort": 9000
      hostPort": 9000
   ...

2.Используйте nodePort в вашем сервисе, сопоставьте с containerPort

Это было то, что по существу сделало это для меня.Разрешено использовать NodePorts в диапазоне настроек вашего сервиса от 30000 до 32767. Поэтому у меня не было возможности сопоставить 8081 и 443 с их соответствующими nodePort.Таким образом, я сопоставил свой 443 containerPort с портом узла 30443 в моей службе LoadBalancer, а 8081 containerPort с портом узла 30881.Затем я сделал несколько изменений в своем коде (передал эти новые порты узла как env var), когда моему приложению нужно знать, какой порт хоста используется.

Преимущества: Вы можете масштабировать свое развертывание столько, сколько захотите!Вы также не будете занимать известные порты, если они понадобятся позже.

Недостатки: диапазон (30000 - 32767) ограничен.Также никакие две службы не могут совместно использовать эти nodePorts, поэтому вы сможете использовать только службу TCP или UDP.Также вам придется внести некоторые изменения в ваше приложение для работы с портами с большим числом.

service.yaml

  ...
  - name: out
    targetPort: 8081
    port: 30881
    nodePort: 30881
    protocol: TCP
  - name: https
    nodePort: 443
    port: 30443
    targetPort: 30443
    protocol: TCP
  ...

Так что в основном любой ресурс, который использует nodePortбудет тот, из которых вы можете иметь только один, если вы используете определенный порт хоста.Поэтому, если вы решите использовать pod hostPort, у вас может быть только один pod с этим портом, а если вы решите использовать service nodePort, у вас может быть только одна служба с этим портом на вашем узле.