Что за сервис со значением None в Kubernetes

Понимание сервиса со значением None (ClusterIP: None) в Kubernetes

В Kubernetes сервис со значением None для поля clusterIP называется Headless Service (безголовый сервис). Это специальная конфигурация, которая фундаментально меняет поведение стандартного сервиса Kubernetes и решает определённые архитектурные задачи.

Как определяется Headless Service

Headless Service создаётся путём явного указания clusterIP: None в манифесте. Пример:

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None # Ключевой параметр!
  selector:
    app: my-stateful-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Отличие от обычного (ClusterIP) сервиса

Чтобы понять значение None, нужно сравнить с обычным сервисом:

адрес, на который kube-proxy или CNI-плагин направляют трафик. | Нет. Виртуальный IP-адрес (ClusterIP) не выделяется. | | DNS-запрос A (адрес) | Возвращает один IP-адрес — ClusterIP сервиса. | Возвращает список IP-адресов всех Pod'ов, отобранных селектором сервиса. | | DNS-запрос SRV (записи) | Не создаются. | Создаются SRV-записи для каждого порта, что позволяет обнаружить порты. | | Использование | Стандартное: абстракция доступа к группе Pod'ов через единую точку входа с балансировкой. | Прямое подключение к конкретным Pod'ам, минуя промежуточный балансировщик. |

Зачем нужен сервис с clusterIP: None? (Основные use-cases)

1. Для StatefulSet'ов и управления индивидуальными Pod'ами. Это основной и самый частый сценарий. StatefulSet создаёт Pod'ы с устойчивыми идентификаторами (именами my-app-0, my-app-1 и т.д.). Headless Service позволяет обращаться к каждому Pod напрямую по стабильному DNS-имени:

    *   `my-app-0.my-headless-service.my-namespace.svc.cluster.local`
    *   `my-app-1.my-headless-service.my-namespace.svc.cluster.local`
    *   Это критически важно для распределённых баз данных (Cassandra, MongoDB, etcd), кластеров RabbitMQ, где каждый узел должен быть адресуем напрямую для репликации или шардирования.

1. Для реализации собственных механизмов балансировки или обнаружения сервисов. Когда приложению (например, кастомному оператору или самому кластерному ПО) нужно знать все конечные точки сразу и решать, как с ними работать, без вмешательства kube-proxy. Приложение запрашивает DNS A -записи и получает полный список IP.

2. Для интеграции с внешними системами службы имен (DNS). Headless Service может быть использован для предоставления записей о Pod'ах внешним DNS---

серверам через ExternalName или специализированные контроллеры.

Как это работает на практике: DNS и сеть

При создании Headless Service:

• Контроллер Endpoints (или EndpointSlice) всё так же создаётся и отслеживает IP адреса подходящих Pod'ов.
• CoreDNS (DNS-сервер кластера) настраивается особым образом для этого сервиса.
• Когда выполняется DNS-запрос к имени сервиса (my-headless-service.my-namespace.svc.cluster.local), CoreDNS, видя clusterIP: None, возвращает не один IP, а набор A-записей для всех Pod'ов из Endpoints.

Пример просмотра конечных точек:

kubectl get endpoints my-headless-service

Вывод покажет список IP-адресов Pod'ов, а не один ClusterIP.

Важные технические нюансы

• Селектор (selector) не обязателен! Можно создать Headless Service без селектора, но тогда вам нужно вручную управлять его Endpoints или EndpointSlices, указывая на внешние службы или Pod'ы в других namespace. Это шаблон для подключения к внешним ресурсам.
• Типы сервиса. Поле type (ClusterIP, NodePort, LoadBalancer) для Headless Service обычно не имеет смысла, так как виртуального IP нет. Однако формально clusterIP: None совместим только с типом ClusterIP (явным или по умолчанию).
• Сетевые политики (NetworkPolicy). Они работают с Headless Service, так как применяются к реальным IP-адресам Pod'ов, на которые указывает сервис.

Итог: Сервис со значением clusterIP: None — это не "отсутствие сервиса", а мощный инструмент для продвинутых сценариев, где требуется прямое DNS-обнаружение отдельных экземпляров Pod'ов, обход встроенной балансировки кластера и поддержка Stateful-приложений. Он убирает абстракцию "виртуального IP", предоставляя приложению прозрачный доступ к сетевой топологии нижележащих Pod'ов.