Для чего нужен Ingress?

Для чего нужен Ingress в Kubernetes?

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

Основные задачи и преимущества Ingress

1. Маршрутизация на основе правил

Ingress Controller (например, Nginx, Traefik, HAProxy) читает правила из ресурсов Ingress и преобразует их в конфигурацию своего прокси-сервера. Это позволяет:

• Маршрутизировать трафик по пути URL (path): например, /api → Service backend, /web → Service frontend.
• Маршрутизировать по доменному имени (host): app.company.com → Service app, admin.company.com → Service admin.

# Пример манифеста Ingress для маршрутизации по хосту и пути
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: "myapp.example.com"
    http:
      paths:
      - path: "/api"
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: "/static"
        pathType: Prefix
        backend:
          service:
            name: static-service
            port:
              number: 80

2. TLS Termination (завершение SSL/TLS)

Ingress позволяет централизованно управлять SSL/TLS, избавляя внутренние сервисы от этой нагрузки. Вы указываете секрет с TLS-ключом и сертификатом в манифесте Ingress, и контроллер обеспечивает HTTPS для входящих соединений.

spec:
  tls:
  - hosts:
    - "secure.example.com"
    secretName: tls-secret-cert

3. Балансировка нагрузки и отказоустойчивость

Ingress Controller сам является приложением, работающим в кластере (обычно как Deployment), и может масштабироваться. Он распределяет трафик между Pods сервисов, на которые маршрутизирует, обеспечивая балансировку и устойчивость к отказам отдельных Pods.

4. Экономия внешних IP-адресов и портов

Без Ingress для каждого публичного сервиса вам потребовался бы отдельный Service типа LoadBalancer или NodePort, каждый со своим внешним IP или портом. Ingress позволяет всем вашим сервисам использовать один внешний IP-адрес (например, выделенный LoadBalancer для самого контроллера) и стандартные порты (80/443), что упрощает управление и снижает стоимость.

5. Централизованное управление сетевыми политиками

Можно реализовать правила на уровне Ingress для:

• Ограничения скорости (Rate Limiting).
• Аутентификации/авторизации (например, через аннотации для OAuth).
• Перезаписывания заголовков запросов и ответов.
• Web Application Firewall (WAF) функции в некоторых контроллерах.

Краткое сравнение: Ingress vs. другие методы доступа

• NodePort: Открывает статический порт на каждой Node. Неудобен для производства (нестандартные порты), нет маршрутизации по HTTP.
• LoadBalancer (облачный): Создает внешний LB для каждого сервиса. Просто, но дорого (много IP) и обычно без интеллектуальной HTTP-маршрутизации.
• Ingress + Ingress Controller: Оптимальный выбор для HTTP/HTTPS трафика. Один внешний LB, интеллектуальная маршрутизация, TLS, экономия ресурсов.

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