Что такое Service?

Что такое Service в Kubernetes?

Service в Kubernetes — это абстракция, которая определяет логический набор Pod'ов и политику доступа к ним. Это ключевой объект для обеспечения сетевого взаимодействия в кластере. По своей сути, Service представляет собой стабильную конечную точку (endpoint) для доступа к приложению, в то время как поды, которые это приложение выполняют, могут быть нестабильными: они создаются, удаляются, перемещаются между нодами. Service решает проблему "обнаружения сервисов" (service discovery) и балансировки нагрузки.

Проще говоря, Service — это постоянный DNS-имя и IP-адрес, которые "живут" всё время жизни сервиса, в то время как поды под ним могут меняться.

Основные задачи Service

• Стабильная сетевая идентификация: Предоставляет постоянное DNS-имя (например, my-service.my-namespace.svc.cluster.local) и виртуальный IP (ClusterIP). Клиенты не должны знать, на каких конкретно нодах и с какими IP работают поды.
• Балансировка нагрузки: Равномерно распределяет входящий сетевой трафик между всеми здоровыми подами, которые соответствуют селектору (selector) сервиса.
• Сервис-дискавери: Позволяет микросервисам находить друг друга по имени через встроенный DNS кластера.
• Абстракция от реализации: Позволяет безболезненно обновлять, масштабировать или восстанавливать поды приложения — клиенты продолжают обращаться к одному и тому же адресу сервиса.

Типы Service в Kubernetes

Kubernetes поддерживает несколько типов Service, которые определяют область видимости и способ экспорта сервиса.

1. ClusterIP (тип по умолчанию):

    *   Присваивает сервису внутренний IP-адрес, видимый **только внутри кластера**.
    *   Идеален для внутренней коммуникации между микросервисами.
    *   Пример манифеста:

    ```yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: backend-service
    spec:
      selector:
        app: backend
      ports:
        - protocol: TCP
          port: 80        # Порт, на котором сервис принимает запросы внутри кластера
          targetPort: 8080 # Порт, на который трафик будет перенаправлен в под
      type: ClusterIP
    ```

2. NodePort:

    *   Расширяет `ClusterIP`. Открывает **статический порт (в диапазоне 30000-32767) на каждой Node** кластера.
    *   Доступ к сервису осуществляется по `<NodeIP>:<NodePort>`. Трафик с этого порта перенаправляется в сервис, а затем на поды.
    *   Используется для доступа извне кластера, когда нет Ingress-контроллера или LoadBalancer, или для отладки.

    ```yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: frontend-service
    spec:
      type: NodePort
      selector:
        app: frontend
      ports:
        - port: 80
          targetPort: 80
          nodePort: 30080 # (Опционально) Можно задать конкретный порт в разрешенном диапазоне
    ```

3. LoadBalancer:

    *   Расширяет `NodePort`. Автоматически создает внешний балансировщик нагрузки в облачном провайдере (AWS ELB, GCP Load Balancer, Azure LB).
    *   Провайдер назначает сервису внешний публичный IP-адрес, который перенаправляет трафик на поды.
    *   Стандартный способ выхода в интернет в управляемых облачных Kubernetes-сервисах (EKS, GKE, AKS).

    ```yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: public-api-service
    spec:
      type: LoadBalancer
      selector:
        app: api
      ports:
        - port: 443
          targetPort: 8443
    ```

4. ExternalName:

    *   Специальный тип сервиса, который не имеет селектора и не проксирует трафик. Вместо этого он возвращает **CNAME-запись** с внешним DNS-именем.
    *   Используется для предоставления внутренним клиентам кластера доступа к внешнему сервису по простому имени.

    ```yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: external-database
    spec:
      type: ExternalName
      externalName: production.database.example.com
    ```

Как это работает под капотом?

Когда вы создаете Service с селектором, Kubernetes непрерывно отслеживает поды, соответствующие меткам селектора. Для этих подов создается Endpoint (или EndpointSlice в современных версиях) — отдельный объект, хранящий список IP-адресов и портов этих подов. Kube-proxy, работающий на каждой ноде кластера, отслеживает изменения Service и Endpoint объектов и конфигурирует правила сетевой маршÿтизации (через iptables, ipvs или nftables) для перенаправления трафика, направленного на вир soтный IP сервиса (ClusterIP), на реальные адреса подов. Это обеспечивает прозрачную балансировку нагрузки.

Headless Service

Особый случай — это Headless Service. Он создается, когда в спецификации сервиса явно указывается clusterIP: None. Такой сервис не получает виртуального IP-адреса и не выполняет балансировку. Вместо этого DNS-запрос возвращает не один адрес (ClusterIP), а список всех IP-адресов подов, принадлежащих этому сервису. Это критически важно для stateful-приложений, таких как базы данных (например, Cassandra, MongoDB), где клиенту нужно знать адреса всех экземпляров для прямой связи с каждым из них.

apiVersion: v1
kind: Service
metadata:
  name: cassandra-headless
spec:
  clusterIP: None
  selector:
    app: cassandra
  ports:
    - port: 9042

Вывод

Service — это краеугольный камень сетевой модели Kubernetes, обеспечивающий декoupling (развязку) между фронтендом и бэкендом, стабильность подключений и отказоустойчивость. Понимание различий между ClusterIP, NodePort, LoadBalancer и умение применять Headless Service — обязательный навык для эффективного проектирования и эксплуатации приложений в Kubernetes. Он превращает динамический и эфемерный мир подов в стабильную, предсказуемую и доступную сетевую среду для микросервисов.