В чем разница между ingress и nodeport?

Разница между Ingress и NodePort в Kubernetes

Ingress и NodePort — это два разных механизма в Kubernetes для предоставления доступа к сервисам извне кластера. Они решают одну задачу, но на разных уровнях абстракции и с принципиально разными подходами. Разберём их детально.

1. NodePort: Прямое проброс портов на нодах

NodePort — это тип сервиса Kubernetes, который открывает статический порт (в диапазоне 30000-32767) на каждой Node кластера. Любой трафик, пришедший на этот порт любой ноды, перенаправляется в соответствующий Pod сервиса.

Как работает NodePort:

• При создании сервиса типа NodePort контроллер сервисов в Kubernetes назначает ему порт из стандартного диапазона (или вы указываете его явно).
• Этот порт открывается на каждой ноде кластера (kube-proxy настраивает правила iptables или IPVS).
• Для доступа к приложению вы обращаетесь по IP-адресу_любой_ноды:NodePort.

Пример манифеста NodePort:

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - port: 80        # Порт внутри кластера, на который сервис принимает запросы
      targetPort: 8080 # Порт контейнера в Pod
      nodePort: 31000  # (Опционально) Фиксированный порт на нодах. Если не указать, будет выбран случайный.

Ключевые характеристики NodePort:

• Уровень: Работает на транспортном уровне (L4) модели OSI (TCP/UDP).
• Гибкость маршрутизации: Отсутствует. Весь трафик на NodePort перенаправляется на сервис, без учёта пути домена.
• Управление трафиком: Нет возможности для SSL/TLS Termination, rewrite правил, load balancing на основе пути и т.д.
• Порты: Использует высокоуровневые порты (30000-32767), что часто требует дополнительной настройки корпоративных фаерволов.
• Использование: Чаще используется для отладки, тестирования или в простых dev-средах. Иногда как компонент для более сложных решений (например, за LoadBalancer'ом в bare-metal кластерах).

2. Ingress: Интеллектуальный маршрутизатор HTTP/HTTPS

Ingress — это не тип сервиса, а API-объект Kubernetes, который управляет внешним доступом к сервисам, обычно HTTP/HTTPS. Он предоставляет правила маршрутизации. Для работы Ingress обязательно нужен Ingress Controller (например, NGINX, Traefik, HAProxy), который реализует эти правила.

Как работает Ingress:

• Администратор создает ресурс Ingress, где описывает правила (например, домен app.example.com → сервис frontend-svc на порту 80).
• Ingress Controller отслеживает создание/изменение ресурсов Ingress и динамически переконфигурирует балансировщик нагрузки (которым он является).
• Пользователь обращается к одному IP-адресу/имени Ingress Controller'а, который, анализируя заголовки HTTP (Host, Path), направляет запрос в нужный backend-сервис.

Пример манифеста Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: "app.mycompany.com"
    http:
      paths:
      - pathType: Prefix
        path: "/api"
        backend:
          service:
            name: api-service
            port:
              number: 80
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: frontend-service
            port:
              number: 8080

Ключевые характеристики Ingress:

• Уровень: Работает на прикладном уровне (L7) модели OSI (HTTP/HTTPS, иногда gRPC, WebSocket).
• Гибкость маршрутизации: Высокая. Маршрутизация на основе хоста, URL-пути, заголовков.
• Управление трафиком: Поддерживает SSL/TLS Termination (вы можете указать секрет с сертификатом прямо в Ingress), rewrites, redirects, аутентификацию, внедрение snipped-кодов и многое другое (зависит от контроллера).
• Порты: Ingress Controller сам публикуется как сервис (обычно типа NodePort или LoadBalancer) на стандартных портах 80 и 443.
• Использование: Стандартный способ публикации веб-приложений в продакшене.

Сравнительная таблица

Типичный продакшен-сценарий и их взаимодействие

В реальном кластере эти технологии часто используются вместе, образуя цепочку доступа:

1. Ваши приложения (Pods) объединены в ClusterIP-сервисы (внутренние).
2. Ingress-ресурс описывает правила доступа к этим сервисам.
3. Ingress Controller (например, pod'ы с nginx) развёрнут как отдельное приложение. Он смотрит на Ingress-правила и конфигурируется под них.
4. Сам Ingress Controller публикуется наружу как сервис типа LoadBalancer (в облаке) или NodePort (если нет облачного LB, например, в bare-metal). Таким образом, NodePort может использоваться для публикации самого Ingress Controller'а.
5. Пользователь обращается к домену -> DNS направляет на внешний IP LoadBalancer'а или на IP ноды + NodePort -> Запрос попадает в Ingress Controller -> Ingress Controller анализирует хост и путь -> Запрос направляется в нужный внутренний ClusterIP-сервис -> Сервис направляет трафик в Pod.

Итог: NodePort — это простой, низкоуровневый механизм проброса порта. Ingress — это высокоуровневое решение для интеллектуальной маршрутизации HTTP(S)-трафика, требующее отдельного контроллера. Для веб-приложений в продакшене Ingress является стандартом де-факто, тогда как NodePort чаще служит вспомогательной или временной технологией.