Три основных типа сервисов для предоставления сетевого доступа в Kubernetes

Отличный вопрос, затрагивающий фундаментальный аспект сетевой модели Kubernetes. Три основных типа Service объектов для предоставления сетевого доступа — это ClusterIP, NodePort и LoadBalancer. Это не просто разные порты, это концептуально разные уровни абстракции, которые решают задачи доступа на разных уровнях: внутри кластера, снаружи через статические порты узлов и через внешние балансировщики облачного провайдера.

Вот их подробный разбор, основанный на реальной практике развертывания и поддержки продакшен-кластеров.

1. ClusterIP

Это сервис по умолчанию и краеугольный камень внутренней сети Kubernetes. Его основная цель — обеспечить стабильную конечную точку для связи между компонентами (Pod'ами) внутри кластера.

• Принцип работы: Kubernetes присваивает Service'у виртуальный, стабильный IP-адрес из диапазона, указанного в --service-cluster-ip-range для kube-apiserver. Этот IP-адрес существует только в пространстве виртуальной сети кластера (например, реализуемой плагинами CNI вроде Calico или Cilium) и не маршрутизируется за его пределами.
• Доступ: Только внутри кластера. Попытка доступа снаружи (например, с локальной машины разработчика) по этому IP будет неудачной.
• Основные сценарии использования:

    *   Связь между микросервисами (backend -> база данных, frontend -> backend API).
    *   Доступ к внутренним административным интерфейсам (например, дашбордам мониторинга, которые не должны быть публичными).
    *   Предоставление единой точки доступа к группе реплицированных Pod'ов. Kube-proxy на каждой ноде (или механизмы IPVS/ebpf в зависимости от режима) отвечают за балансировку трафика между этими Pod'ами.

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

apiVersion: v1
kind: Service
metadata:
  name: my-backend-service
spec:
  type: ClusterIP # Можно опустить, так как это значение по умолчанию
  selector:
    app: my-backend
  ports:
    - protocol: TCP
      port: 80       # Порт, на котором Service доступен внутри кластера
      targetPort: 8080 # Порт контейнера в Pod'ах

2. NodePort

Это надстройка над ClusterIP. NodePort делает внутренний сервис доступным снаружи кластера, открывая статический порт (NodePort) на каждой Node (виртуальной машине/сервере) в кластере. Трафик на этот порт любой ноды перенаправляется в сервис, а затем, через механизмы ClusterIP, — в один из Pod'ов.

• Принцип работы:

    1.  Kubernetes создает `ClusterIP` (как описано выше).
    2.  На каждой ноде `kube-proxy` открывает порт в диапазоне `--service-node-port-range` (по умолчанию 30000-32767) и начинает слушать его.
    3.  Любой трафик, пришедший на `<IP_ЛЮБОЙ_NODE>:<NodePort>`, перехватывается и, следуя правилам iptables/IPVS, направляется в `ClusterIP`, а оттуда — в конечный Pod.

• Доступ: Снаружи кластера по любому IP-адресу любой ноды и указанному высокому порту (напр., http://<node1-ip>:31684).
• Сценарии использования:

    *   Разработка и отладка, когда нужно быстро "достучаться" до сервиса с локальной машины.
    *   Среда, где нет облачного балансировщика нагрузки (bare-metal, on-premise инфраструктура). Часто используется в паре с внешним, "классическим" балансировщиком (например, HAProxy или hardware LB), который направляет трафик на NodePort'ы нод.
    *   Не подходит для прямого публичного доступа в продакшене из-за необходимости помнить высокие порты и IP-адреса нод, которые могут меняться.

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

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

3. LoadBalancer

Это эволюция NodePort для облачных сред. Тип LoadBalancer автоматически запрашивает у облачного провайдера (AWS, GCP, Azure, Яндекс.Облако и т.д.) выделение внешнего балансировщика нагрузки и настраивает его.

• Принцип работы:

    1.  Kubernetes создает `ClusterIP`.
    2.  Kubernetes создает `NodePort` (как промежуточный шаг).
    3.  Контроллер облачного провайдера (cloud-controller-manager), работающий в кластере, отправляет API-запрос провайдеру: "Создай балансировщик нагрузки, который бы направлял трафик на NodePort всех моих нод".
    4.  Провайдер создает LB (например, AWS Network/Application Load Balancer, Yandex Cloud Network Load Balancer) и выдает ему внешний IP-адрес или DNS-имя.

• Доступ: Снаружи кластера по стабильному внешнему IP/DNS, предоставленному облачным балансировщиком.
• Сценарии использования:

    *   Продакшен-доступ к публичным веб-сервисам в облачных средах.
    *   Автоматическое масштабирование и отказоустойчивость на уровне инфраструктуры провайдера.
    *   Часто "базовый" `LoadBalancer` провайдера работает на 4-м уровне (L4, TCP/UDP). Для продвинутой маршрутизации на 7-м уровне (HTTP/HTTPS, хосты, пути) поверх `LoadBalancer` используют **Ingress-контроллер**.

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

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  type: LoadBalancer
  selector:
    app: my-production-app
  ports:
    - protocol: TCP
      port: 443
      targetPort: 8443
  # Провайдер-специфичные настройки часто добавляются в аннотации
  # metadata:
  #   annotations:
  #     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

Важное дополнение: Ingress — это не Service

Часто возникает путаница. Ingress — это отдельный объект API, который управляет внешним доступом на уровне HTTP/HTTPS (L7). Он не является типом Service. Ingress определяет правила маршрутизации (например, трафик на app.example.com -> Service app-service). Для работы Ingress'у требуется развернутый в кластере Ingress-контроллер (например, nginx-ingress, traefik), который сам по себе обычно暴露 (экспонируется) через Service типа LoadBalancer или NodePort. Таким образом, LoadBalancer предоставляет точку входа, а Ingress — "умную" маршрутизацию внутри.

Итог: Выбор типа зависит от контекста. ClusterIP для внутренней коммуникации, NodePort для простого внешнего доступа или bare-metal, LoadBalancer для облачного продакшена. В современных облачных стеках типичная цепочка для веб-приложения: Pod -> ClusterIP Service -> Ingress Resource -> Ingress Controller Pod -> LoadBalancer Service -> Облачный Load Balancer -> Пользователь.