Сервис (Service) в Kubernetes: многопортовые сервисы, обнаружение сервисов
Многопортовые Сервисы
Для некоторых сервисов вам нужно предоставить более одного порта. Kubernetes позволяет настроить несколько определений портов для объекта Service. При использовании нескольких портов для Сервиса вы должны указать все имена портов, чтобы они были однозначными. Например:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377
Примечание: Как и в случае с именами Kubernetes, имена портов должны содержать только строчные буквенно-цифровые символы и - (дефисы). Имена портов также должны начинаться и заканчиваться буквенно-цифровым символом.
Например, имена 123-abc и web действительны, а 123_abc и -web - нет.
Выбирая свой собственный IP-адрес
Вы можете указать свой собственный IP-адрес кластера как часть запроса на создание Сервиса. Для этого установите поле .spec.clusterIP. Например, если у вас уже есть существующая запись DNS, которую вы хотите использовать повторно, или устаревшие системы, которые настроены для определенного IP-адреса и которые трудно переконфигурировать.
Выбранный IP-адрес должен быть действительным адресом IPv4 или IPv6 из диапазона CIDR service-cluster-ip-range, настроенного для сервера API. Если вы попытаетесь создать Сервис с недопустимым значением IP-адреса кластера, сервер API вернет код состояния 422 HTTP, чтобы указать, что существует проблема.
Обнаружение сервисов
Kubernetes поддерживает 2 основных режима поиска Сервиса - переменные среды и DNS.
Переменные среды
Когда Pod запускается на узле, kubelet добавляет набор переменных среды для каждого активного сервиса. Он поддерживает как переменные, совместимые с Docker-связями (Docker links), так и более простые переменные {SVCNAME}_SERVICE_HOST и {SVCNAME}_SERVICE_PORT, где имя Сервиса вводится в верхнем регистре, а дефисы преобразуются в подчеркивания.
Например, сервис "redis-master", которая предоставляет TCP-порт 6379 и которому был присвоен кластерный IP-адрес 10.0.0.11, создает следующие переменные среды:
REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
Примечание: Если у вас есть Pod, которому требуется доступ к Сервису, и вы используете метод переменной среды для публикации IP-адреса порта и кластера в клиентских Pod'ах, необходимо создать сервис, прежде чем появятся клиентские Pod'ы. В противном случае в этих клиентских Pod'ах не будут заполнены переменные среды.
Если вы используете DNS только для обнаружения IP-адреса кластера для какого-либо сервиса, вам не нужно беспокоиться об этой проблеме.
DNS
Вы можете (и почти всегда должны) настроить сервис DNS для своего кластера Kubernetes, используя дополнение (add-on).
DNS-сервер с поддержкой кластеров, такой как CoreDNS, отслеживает API-интерфейс Kubernetes для новых сервисов и создает набор записей DNS для каждой из них. Если DNS включен в вашем кластере, то все Pod'ы должны автоматически определять сервисы по их DNS-именам.
Например, если у вас есть сервис с именем "my-service" в пространстве имен Kubernetes "my-ns", плоскость управления и служба DNS, действующие вместе, создают запись DNS для "my-service.my-ns". Pod'ы в пространстве имен "my-ns" должны быть в состоянии найти его, просто выполнив поиск имени для my-service ("my-service.my-ns" также будет работать).
Pod'ы в других пространствах имен должны квалифицировать имя как my-service.my-ns. Эти имена будут преобразованы в IP-адрес кластера, назначенный для Сервиса.
Kubernetes также поддерживает записи DNS SRV (Service) для именованных портов. Если сервис "my-service.my-ns" имеет порт с именем "http" с протоколом, установленным на TCP, вы можете выполнить запрос DNS SRV для _http._tcp.my-service.my-ns, чтобы найти номер порта для "http", а также IP-адрес.
DNS-сервер Kubernetes является единственным способом доступа к Сервисам ExternalName.
Безглавые Сервисы (Headless Services)
Иногда вам не требуется балансировка нагрузки и один IP-адрес сервиса. В этом случае вы можете создать так называемые “headless” сервисы, явно указав "None" для IP-адреса кластера (.spec.clusterIP).
Вы можете использовать headless сервис для взаимодействия с другими механизмами обнаружения сервисов, не привязываясь к реализации Kubernetes.
Для headless сервисов IP-адрес кластера не выделяется, kube-proxy не обрабатывает эти сервисы, и платформа не выполняет для них балансировку нагрузки или прокси. Способ автоматической настройки DNS зависит от того, определены ли в сервисе селекторы:
С селекторами
Для headless Сервисов, которые определяют селекторы, контроллер конечных точек создает записи Конечных точек в API и изменяет конфигурацию DNS, чтобы возвращать записи (адреса), которые указывают непосредственно на Pod'ы, поддерживающие Сервис.
Без селекторов
Для headless Сервисов, которые не определяют селекторы, контроллер конечных точек не создает записи Конечных точек. Однако система DNS ищет и настраивает либо:
- Записи CNAME для сервиса типа ExternalName.
- Записи для любых конечных точек, которые совместно используют имя с сервисом, для всех других типов.
Читайте также:
- Сервис (Service) в Kubernetes
- Сервис (Service) в Kubernetes: виртуальные IP-адреса и сервисные прокси
- Контроллеры в Kubernetes: StatefulSet
Комментарии
Отправить комментарий