Ответ
Для создания единой точки входа (API Gateway / Reverse Proxy) я предпочитаю использовать Ingress Controller в Kubernetes (чаще всего на основе Nginx или Traefik) в сочетании с Service Mesh (например, Istio) для сложных сценариев.
Пример реализации на Kubernetes с Nginx Ingress:
-
Деплой Ingress Controller:
# Пример манифеста для создания Ingress ресурса apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: unified-api-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: api.mycompany.com http: paths: - path: /users pathType: Prefix backend: service: name: user-service port: number: 8080 - path: /orders pathType: Prefix backend: service: name: order-service port: number: 3000 - path: / pathType: Prefix backend: service: name: frontend-service port: number: 80Все внешние запросы к
api.mycompany.comбудут приходить на один IP-адрес и порт (80/443) Ingress Controller'а, который затем маршрутизирует трафик на соответствующие внутренние сервисы на основе пути (path). -
Преимущества такого подхода:
- Centralized TLS Termination: SSL-сертификаты управляются в одном месте (например, через Cert-Manager для автоматического получения Let's Encrypt).
- Load Balancing: Встроенная балансировка нагрузки между подами сервиса.
- Динамическая конфигурация: Traefik или современные Ingress-контроллеры автоматически обновляют конфигурацию при создании/удалении сервисов в кластере.
- Единое место для cross-cutting concerns: В Ingress можно централизованно настроить аутентификацию (OAuth прокси), ограничение скорости (rate limiting), CORS, логирование запросов.
Для среды без Kubernetes я разворачиваю Traefik или HAProxy в Docker-композе, используя их возможности автоматического обнаружения сервисов (service discovery) через Docker-сокет или Consul, что также избавляет от необходимости вручную редактировать конфиги прокси при каждом обновлении сервиса.