Как сделать Dynami c Proxying в стручки Kubernetes?

Question

Я хочу создать сервис, который может делать какие-то динамические c прокси обратно к бобам Kubernetes. В основном у меня будут сотни модулей K8s, на которых запущено одно и то же приложение, которое сопоставляется со случайным портом на хосте (например, 10456). Тем не менее, каждый Pod уникален, и я хочу, чтобы traffi c был направлен на указанный модуль c, основанный на имени хоста. Поэтому, когда приходит запрос на abc123.app.com, у меня будет прокси-слой, который выполняет поиск в базе данных, чтобы найти хост и порт, на котором работает домен (например, 10.0.0.5:10456), а затем перенаправляет запрос туда. Есть ли сервис, который поддерживает это? Я работал с Nginx много раньше, но мне не ясно, может ли он поддерживать эту функциональность поиска.

Кто-нибудь создавал что-то подобное раньше? Каков наилучший способ создать прокси-слой, который может выполнять такие поиски? Как мне обновить базу данных, когда модуль перемещается с одного хоста на другой?

Заранее спасибо!

РЕДАКТИРОВАТЬ:

Я должен был вставить это туда в первый раз , но типы трафиков c, идущих к этим контейнерам: RP C traffi c и трафик Peer to Peer c

Answer 1

Вы описываете нечто очень похожее на то, что определения kubernetes ingress делают для http traffi c.

Определение входа настраивает входной контроллер для направления запросов имени хоста на службу . Сервис выбирает конечные точки (модули) с помощью селекторов меток . Когда модули перемещаются, kubernetes обновляет сервис автоматически.

Работа на вашем конце просто сводится к передаче изменений конфигурации из вашей базы данных через один из клиентов API в kubernetes, а не через прокси-сервер. Если ваша среда была чрезвычайно динамичной c, требующей постоянной реконфигурации, или вам необходимо принимать динамические c решения о том, где трафик c должен go, вы можете продолжить поиск собственного прокси или istio , openresty .

Звучит так, как будто у вас уже есть уникальные развертывания, отправляющиеся в kubernetes, так что помимо этого есть определение сервиса и входного определения.

Простой пример, включающий метку на модуле, службу, использующую метку. Затем определение входа с помощью сервиса.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: host-abc123
spec:
  containers:
  - name: host-abc123
    image: me/my-app:1.2.1
    ports:
    - containerPort: 10456

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: host-abc123
spec:
  rules:
  - host: abc123.bar.com
    http:
      paths:
      - backend:
          serviceName: host-abc123
          servicePort: 80

apiVersion: v1
kind: Service
metadata:
  name: host-abc123
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 10456

Одно входное определение может включать все хосты, но я не уверен, как kubernetes и входные контроллеры go будут регулярно его заменять.

Там nginx контроллеры входа на основе тоже. В итоге вы получите конфигурацию nginx server для каждого входа / определения хоста.