Как происходит разделение подов Kubernetes по доменам в Nginx

Разделение подов Kubernetes по доменам в Nginx Ingress

В Kubernetes, разделение подов (Pods) по доменам с использованием Nginx Ingress Controller является стандартным подходом для маршрутизации входящего HTTP/HTTPS трафика к различным сервисам внутри кластера. Это достигается через конфигурацию Ingress-ресурсов, которые определяют правила маршрутизации на основе хостов (доменов) и путей. Nginx Ingress Controller действует как обратный прокси и балансировщик нагрузки, транслируя эти правила в конфигурацию Nginx.

Ключевые компоненты для разделения по доменам

1. Ingress Controller (в данном случае Nginx): Развёртывается как набор подов в кластере (обычно в namespace ingress-nginx). Он отслеживает создание/изменение Ingress-ресурсов и обновляет конфигурацию Nginx.
2. Ingress Resource: YAML-манифест, определяющий правила маршрутизации для одного или нескольких доменов.
3. Service: Kubernetes Service, который предоставляет стабильную конечную точку для набора подов (обычно через селекторы меток). Ingress направляет трафик на Service.
4. Pods: Контейнеры приложений, сгруппированные по меткам, которые селектирует Service.

Пример конфигурации Ingress для разделения по доменам

Предположим, у нас есть два приложения: app1 и app2, каждое развёрнутое в виде отдельного Deployment с Pod'ами, и мы хотим направить трафик с доменов app1.example.com и app2.example.com к соответствующим подам.

Шаг 1: Создание Services для приложений

Каждое приложение должно иметь Service, который указывает на его поды. Например, для app1:

apiVersion: v1
kind: Service
metadata:
  name: app1-service
spec:
  selector:
    app: app1  # Селектор меток для Pod'ов app1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080  # Порт контейнера в Pod

Аналогичный Service создаётся для app2 (например, app2-service).

Шаг 2: Создание Ingress Resource с правилами для доменов

Ingress-ресурс определяет, как трафик с разных доменов распределяется по Services:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: domain-based-ingress
spec:
  rules:
  - host: app1.example.com  # Первый домен
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: app1-service  # Направляем трафик на Service app1
            port:
              number: 80
  - host: app2.example.com  # Второй домен
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: app2-service  # Направляем трафик на Service app2
            port:
              number: 80

В этом примере:

• Трафик на app1.example.com будет направлен на app1-service, который балансирует нагрузку между подами с меткой app: app1.
• Трафик на app2.example.com будет направлен на app2-service, балансируясь между подами app: app2.

Как это работает внутри Nginx Ingress Controller

1. Отслеживание изменений: Nginx Ingress Controller наблюдает за Ingress-ресурсами во всех namespace (или в определённых, в зависимости от конфигурации).
2. Генерация конфигурации: При создании или изменении Ingress, Controller генерирует конфигурационный файл Nginx, основываясь на правилах. Для приведённого примера будут созданы два серверных блока (виртуальных хоста) в Nginx:

   server {
       server_name app1.example.com;
       listen 80;
       location / {
           proxy_pass http://app1-service.default.svc.cluster.local:80;
       }
   }
   server {
       server_name app2.example.com;
       listen 80;
       location / {
           proxy_pass http://app2-service.default.svc.cluster.local:80;
       }
   }
   

3. Балансировка нагрузки: Nginx распределяет запросы между подами, используя механизмы балансировки (по умолчанию — round-robin). Он взаимодействует с Kubernetes API для получения актуального списка IP-адресов подов, связанных с каждым Service (через Endpoints).
4. Динамическое обновление: При масштабировании подов (например, увеличение реплик) Endpoints обновляются, и Nginx автоматически получает новые цели для балансировки.

Дополнительные возможности

• TLS-терминация: Для HTTPS можно добавить секрет с TLS-сертификатом в Ingress:

  spec:
    tls:
    - hosts:
      - app1.example.com
      secretName: app1-tls-secret
  

• Path-based routing: Внутри одного домена можно разделять трафик по путям (например, app1.example.com/api и app1.example.com/web).
• Аннотации: Nginx Ingress поддерживает аннотации для тонкой настройки (например, nginx.ingress.kubernetes.io/rewrite-target, nginx.ingress.kubernetes.io/proxy-body-size).

Практические аспекты

• DNS-настройка: Домены (например, app1.example.com) должны быть настроены на IP-адрес Nginx Ingress Controller (это может быть LoadBalancer, NodePort или внешний IP).
• Namespace: Ingress-ресурсы могут быть ограничены namespace, но обычно Controller обрабатывает правила из всех namespace, если не настроена иначе.
• Health checks: Nginx автоматически проверяет доступность подов через механизмы Kubernetes.

Таким образом, разделение подов по доменам в Nginx Ingress сводится к декларативному описанию правил в Ingress-ресурсах, где каждому домену сопоставляется соответствующий Service, который, в свою очередь, направляет трафик на целевые поды. Это обеспечивает гибкую, масштабируемую и удобную в управлении маршрутизацию в Kubernetes-кластере.