NodePort, LoadBalancer и Ingress: Выбор оптимального способа публикации сервиса

Изучите важнейший выбор внешнего доступа к сервисам Kubernetes, сравнивая NodePort, LoadBalancer и Ingress. В этом руководстве подробно описаны архитектура, рабочий уровень (L4 по сравнению с L7), варианты использования, а также ключевые различия в стоимости и сложности для каждого из этих методов. Узнайте, когда использовать простой NodePort для тестирования, выделенный LoadBalancer для отдельных сервисов или мощный Ingress для централизованной, экономичной маршрутизации уровня 7 и сложных сред с несколькими сервисами.

25 просмотров

NodePort против LoadBalancer против Ingress: Выбор лучшего способа предоставления доступа к сервису

Сервисы Kubernetes — это основополагающие объекты, которые обеспечивают стабильную сетевую связь для динамического набора Подов. В то время как сервисы управляют внутренней связью кластера, предоставление этим сервисам внешнего доступа — то есть разрешение взаимодействия с ними пользователям или внешним приложениям — требует специальной настройки. Выбор правильного метода экспозиции критичен, поскольку он влияет на безопасность, стоимость и сложность.

В этой статье представлено экспертное сравнение трех основных методов предоставления доступа к Сервисам Kubernetes: NodePort, LoadBalancer и Ingress. Мы проанализируем механизмы работы, подходящие сценарии использования и практические факторы, чтобы помочь вам выбрать оптимальное решение для ваших контейнеризированных приложений.


1. Тип предоставления доступа к сервису: NodePort

Тип сервиса NodePort — это самый простой и базовый способ предоставления сервиса внешнему доступу. Когда вы определяете сервис как NodePort, Kubernetes открывает определенный статический порт на каждом Узле (Node) в кластере. Любой трафик, направленный на этот порт на любом узле, перенаправляется напрямую к сервису.

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

  1. Автоматически выбирается случайный порт из выделенного диапазона (по умолчанию: 30000-32767).
  2. Этот порт открывается на всех узлах кластера.
  3. Сервис прослушивает этот NodePort, перенаправляя трафик соответствующим Подам.

Для доступа к приложению используется адрес http://<IP_Узла>:<NodePort>.

Сценарии использования и ограничения

Характеристика Описание
Сценарий Разработка, тестовые среды или случаи, когда внешняя балансировка нагрузки обрабатывается внешней не облачной аппаратурой.
Сложность Очень низкая.
Стоимость Нулевая (если не учитывать стоимость базовых ВМ).
Ограничение Требует ручного управления правилами внешнего файрвола. IP-адреса узлов часто динамичны. Ограничение диапазона портов (30000-32767).

Пример NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-web-app
  ports:
    - port: 80
      targetPort: 8080
      # Необязательно: указать NodePort, иначе он будет выбран автоматически
      # nodePort: 30001 

⚠️ Предупреждение: NodePort предоставляет доступ к сервису через все узлы. Если узел удаляется или его IP-адрес изменяется, внешний доступ прерывается. Обычно это не рекомендуется для производственных сред, требующих стабильности.


2. Тип предоставления доступа к сервису: LoadBalancer

Тип сервиса LoadBalancer — это стандартный метод предоставления приложений общедоступному интернету в облачных средах (AWS EKS, GCP GKE, Azure AKS).

Когда сервис определяется как LoadBalancer, Kubernetes автоматически выделяет выделенный облачный балансировщик нагрузки 4-го уровня (L4) (например, AWS Classic ELB/NLB, Azure Load Balancer, GCP Network Load Balancer). Это обеспечивает стабильный, высокодоступный внешний IP-адрес, который направляет трафик непосредственно к Подам сервиса.

Интеграция с облачным провайдером

Ключевым отличием LoadBalancer является глубокая интеграция с базовой облачной инфраструктурой. Облачный провайдер управляет жизненным циклом балансировщика нагрузки, проверками работоспособности и маршрутизацией.

Сценарии использования и влияние на стоимость

Характеристика Описание
Сценарий Простые, публично доступные приложения, требующие выделенного, стабильного IP-адреса. Подходит для протоколов, отличных от HTTP/S (TCP/UDP).
Сложность Низкая (с точки зрения конфигурации).
Стоимость Высокая. Каждый сервис LoadBalancer выделяет отдельный облачный ресурс, что часто влечет за собой почасовые расходы.
Преимущество Обеспечивает немедленную высокую доступность и автоматические проверки работоспособности.

Пример LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-app-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: my-api-service
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

После создания кластер назначит внешний IP-адрес (видимый в статусе сервиса), управляемый облачным провайдером.


3. Kubernetes Ingress: Маршрутизация на уровне 7

Ingress по своей сути отличается от NodePort и LoadBalancer. Ingress — это не тип Сервиса, а API-объект, который определяет правила внешнего доступа, обычно для HTTP и HTTPS (Уровень 7).

Ingress действует как центральная точка входа, позволяя сложную маршрутизацию на основе имен хостов и путей URL. Этот подход необходим для управления несколькими сервисами за одним IP-адресом.

Роль Ingress-контроллера

Чтобы правила Ingress работали, вы должны сначала развернуть Ingress Controller (например, Nginx, Traefik, Istio). Контроллер отслеживает определения ресурсов Ingress и настраивает базовый обратный прокси/балансировщик нагрузки L7 на основе этих правил.

Важно отметить, что сам Ingress Controller обычно предоставляется через один сервис LoadBalancer или NodePort.

Расширенные возможности Ingress

Ingress проявляет себя, когда вам нужны расширенные функции управления трафиком:

  1. Оптимизация затрат: Использование одного облачного LoadBalancer (для предоставления доступа к Контроллеру) вместо одного LoadBalancer на каждый сервисный модуль приложения.
  2. Виртуальный хостинг: Маршрутизация трафика на основе имен хостов (api.example.com ведет к Сервису A; www.example.com ведет к Сервису B).
  3. Маршрутизация по путям: Маршрутизация трафика на основе путей URL (/v1/users ведет к Сервису A; /v2/posts ведет к Сервису B).
  4. Терминация SSL/TLS: Централизованное управление сертификатами и дешифрование.

Пример ресурса Ingress

Этот пример маршрутизирует трафик для api.example.com/v1 к сервису my-api-v1.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: nginx # Укажите используемый контроллер
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api-v1
            port:
              number: 80
  # ... другие правила для разных сервисов/хостов

4. Сравнение и руководство по выбору

Выбор оптимального метода включает взвешивание таких факторов, как среда, сложность, набор функций и операционные затраты.

Сравнительная таблица функций

Характеристика NodePort LoadBalancer Ingress
Уровень L4 (TCP/UDP) L4 (TCP/UDP) L7 (HTTP/S)
Стабильность (IP) Нестабильный (использует IP узла) Стабильный (Выделенный облачный IP) Стабильный (Использует IP Контроллера)
Стоимость Низкая (Высокие операционные накладные расходы) Высокая (Затраты на ресурсы на сервис) Умеренная (Один LoadBalancer для Контроллера)
Логика маршрутизации Простое перенаправление портов Простое перенаправление портов Имя хоста, Путь, Терминация SSL
Зависимость от облака Нет Высокая Высокая (Требует, чтобы Контроллер был доступен через LoadBalancer)
Готовность к продакшену Нет Да (Простые приложения) Да (Сложные приложения)

Критерии принятия решений: Выбор метода предоставления доступа

  1. Только для внутреннего использования или тестирования: Если вам нужно просто протестировать подключение внутри кластера или вы самостоятельно управляете внешней сетью (например, в среде bare-metal), используйте NodePort.

  2. Для простого, выделенного доступа L4: Если ваше приложение использует протоколы, отличные от HTTP (например, пользовательские протоколы TCP или UDP), или если у вас есть только одно публичное приложение, которому требуется немедленный, выделенный доступ L4, используйте LoadBalancer.

  3. Для сложного предоставления L7-доступа к нескольким сервисам: Если вам нужно предоставить доступ к нескольким сервисам, требуется маршрутизация на основе пути или имени хоста, необходима централизованная терминация SSL или вы хотите минимизировать облачные затраты за счет использования одного внешнего IP-адреса, используйте Ingress.

Рекомендация: Для производственных развертываний в управляемых облачных средах Ingress обычно является предпочтительным выбором. Он предоставляет необходимую сложность, централизацию безопасности и экономическую эффективность для управления растущим числом микросервисов.

Заключение

Kubernetes предлагает целый спектр решений для предоставления доступа к сервисам, начиная от базового L4 NodePort, через интегрированный в облако L4 LoadBalancer, и заканчивая сложными возможностями маршрутизации L7 Ingress. Понимая операционный уровень, модель затрат и требуемую логику маршрутизации каждого метода, инженеры могут проектировать сетевые архитектуры, которые являются масштабируемыми, безопасными и экономически эффективными для их производственных рабочих нагрузок.