Kubernetes Service — разбираем типы сервисов k8s и их применение

Kubernetes — это мощная платформа для оркестрации контейнеров, которая позволяет эффективно управлять развертыванием, масштабированием и эксплуатацией контейнерных приложений. Одним из ключевых компонентов Kubernetes является сервис (service), который обеспечивает доступ к приложениям, запущенным в подах, и управляет сетевым взаимодействием. В данной статье мы подробно познакомимся с типами сервисов в Kubernetes, рассмотрим их особенности и отличия. Также мы рассмотрим практические примеры для наглядной работы.

Предварительные требования

Так как мы будем рассматривать практическую часть, нам понадобится кластер Kubernetes. Арендовать готовый кластер можно с помощью сервиса Kubernetes в облаке.

Заказ кластера Kubernetes

Для начала создадим кластер Kubernetes.

1) Авторизируемся в аккаунте при помощи логина или адреса электронной почты и пароля.

2) После успешной авторизации отобразится панель управления текущего проекта. Переходим в раздел «Kubernetes» в меню слева и нажимаем на кнопку «Создать».

3) Выбираем необходимый регион из списка доступных:

4) Далее необходимо выбрать тип кластера. На выбор доступно 3 типа — Dev, Base и Custom. В нашем случае нам будет достаточно Dev-конфигурации:

5) В качестве конфигурации для воркер-нод выберем минимальную, а именно одноядерный процессор, 2 ГБ оперативной памяти и 30 ГБ места на NVMe-диске:

6) Все остальные параметры можно оставить без изменений:

7) Для заказа кластера нажимаем на кнопку «Заказать»:

После заказа кластера он будет готов к использованию в течение пары минут. kubeconfig для подключения к кластеру будут сгенерирован и доступен в раздел «Дашборд».

Что такое сервис в Kubernetes?

Сервис в Kubernetes — это объект, который используется для определения логических групп подов и правил доступа к ним. Поды в Kubernetes имеют временный (эфирный) характер: их можно создавать, удалять, перезапускать или перемещать между узлами кластера. Это делает прямой доступ к подам по их IP-адресам ненадежным. Сервисы решают эту проблему, предоставляя стабильный сетевой интерфейс для взаимодействия с подами. Каждый сервис получает виртуальный IP-адрес (ClusterIP) или DNS-имя, через которые можно обращаться к группе подов, даже если сами поды меняются.

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

• ClusterIP
• NodePort
• LoadBalancer
• ExternalName
• Headless Service

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

ClusterIP

Тип сервиса, который используется в Kubernetes по умолчанию. Сервис создает виртуальный IP-адрес внутри кластера, который используется для доступа к подам, соответствующим селектору сервиса. ClusterIP обеспечивает внутреннюю маршрутизацию трафика, то есть доступ возможен только внутри кластера без доступа во внешнюю сеть. Данный тип сервиса подходит для приложений, которые взаимодействуют только с другими компонентами внутри кластера, например, СУБД PostgreSQL или брокер сообщений Apache Kafka.

Особенности

• Используется виртуальный IP-адрес для сетевого взаимодействия только внутри кластера.

• Балансировка трафика происходит между подами, которые соответствуют селектору сервиса.

• Подходит для работы со внутренними сервисами — СУБД, API, брокеры сообщений.

Пример использования

В качестве примера создадим файл типа Deployment, в котором будет указан сервис ClusterIP вместе с контейнером, где будет запущен веб-сервер Nginx. Конфигурация приведена ниже:

Для начала создадим новый namespace с именем service-clusterip:

Далее сохраняем конфигурацию выше в файл с именем nginx-test-deployment.yaml и применяем ее:

Проверяем, что все объекты были созданы:

В качестве теста выполним команду curl из ранее созданного пода (в нашем примере это под с именем nginx-clusterip-deployment-54ffdb7c4b-87dsl) на имя созданного ClusterIP сервиса — http://nginx-clusterip-service:

Как можно увидеть на скриншоте выше, был получен ответ от сервиса. В этом примере сервис nginx-service направляет трафик на поды с меткой app: nginx далее сервис перенаправляет запросы на порт 80 подов. Внешний доступ отсутствует, что обеспечивает изоляцию.

NodePort

Сервис типа NodePort открывает доступ к подам через порт на каждом узле кластера. Kubernetes выделяет порт из диапазона 30000–32767 (по умолчанию) и привязывает его к сервису. Это позволяет внешним клиентам обращаться к приложению через IP-адрес любого узла кластера и назначенный порт. NodePort часто используют для тестирования или в тех случаях, где требуется прямой доступ к сервису без использования внешнего балансировщика нагрузки.

Особенности

• Доступ к приложениям возможен через комбинацию IP-адреса узла кластера и номера порта.

• Сервис также обладает внутренним адресом ClusterIP, что позволяет использовать его внутри кластера.

• Подходит для временного доступа или для использования в кластерах без внешнего балансировщика нагрузки.

Пример использования

Предположим, у нас в кластере запущен под с веб-сервером Nginx. Для доступа к Nginx с локального компьютера создадим сервис типа NodePort. Используем конфигурацию ниже:

Для начала создадим новый namespace с именем service-nodeport:

Далее сохраняем конфигурацию выше в файл с именем nginx-nodeport-deployment.yaml и применяем ее:

Проверяем, что все объекты были созданы:

В данном примере сервис открывает порт 30080 на всех узлах кластера на внешнем IP-адресе. Чтобы узнать внешний IP-адрес кластера, необходимо выполнить команду ниже:

Если внешний IP-адрес узла — 5.129.210.247 (столбец EXTERNAL-IP), то приложение будет доступно по адресу 5.129.210.247:30080. Выполним команду curl на внешний IP-адрес и порт 30080:

Трафик перенаправляется на порт 8080 подов. Этот подход удобен для быстрого тестирования, но не рекомендуется для использования в production-системах из-за ограничений безопасности и масштабируемости.

LoadBalancer

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

Особенности

• Создает внешний IP-адрес, доступный из внешней сети.

• Интегрируется с облачными балансировщиками нагрузки.

• Включает функциональность ClusterIP и NodePort.

Пример использования

В качестве примера создадим конфигурацию? в которой будет использоваться под с Nginx. Доступ будет осуществляться через внешний IP-адрес балансировщика:

Для начала создадим новый namespace с именем service-loadbalancer:

Далее сохраняем конфигурацию выше в файл с именем nginx-loadbalancer-deployment.yaml и применяем ее:

Время создания внешнего балансировщика может занять 5-10 минут. Только после этого можно будет проверить, что все объекты были созданы:

На скриншоте выше в разделе EXTERNAL-IP появился внешний IP-адрес. Если выполнить curl на данный IP-адрес, то вернется ответ от Nginx:

ExternalName

ExternalName — тип сервиса, который используется для создания ссылки на внешний ресурс, находящийся за пределами кластера Kubernetes, без необходимости создания локального прокси. Это позволяет направлять трафик к внешнему сервису, используя DNS-имя, без выделения ClusterIP или создания подов в кластере.

Особенности

• Работает как DNS-алиас для внешнего ресурса.

• Не создает виртуальный IP-адрес.

Headless Service

Headless Service — это тип сервиса, который не привязан к ClusterIP. Он обеспечивает DNS-записи для всех подов, соответствующих указанному селектору. Такой сервис применяется для прямого взаимодействия с каждым подом, например, в распределенных системах, таких как базы данных или системы обработки сообщений.

Особенности

• Не создает виртуальный IP-адрес.

• DNS-запрос возвращает IP-адреса всех подов.

• Подходит для приложений, где требуется прямое взаимодействие с каждым подом.

Пример использования

В качестве примера создадим конфигурацию? в которой будет запущено два пода с Nginx. Ключевая особенность — установка clusterIP со значением None, при котором Kubernetes не будет выделять виртуальный IP-адрес. Вместо этого DNS будет возвращать IP-адреса всех подов, соответствующих селектору:

Для начала создадим новый namespace с именем service-headless:

Далее сохраняем конфигурацию выше в файл с именем nginx-headless-deployment.yaml и применяем ее:

Проверяем, что все объекты были созданы:

Далее проверяем, что все поды запущены. Также получим IP-адрес узлов кластера, на которых были запущены поды:

Запустим временный под на основе образа curl для выполнения запросов внутри кластера:

Отправим запрос при помощи curl на адрес ранее созданного сервиса (nginx-headless.service). Имя сервиса записывается в формате <имя-сервиса>.<пространство-имен>.svc.cluster.local. Имя сервиса можно узнать при помощи команды:

В нашем примере имя сервиса выглядит как nginx-headless.service-headless.svc.cluster.local.

Так как поды запущены на разных нодах, при выполнении команды IP-адреса всегда будет разными:

Сравнение типов сервисов

Для наглядности воспользуемся таблицей ниже чтобы детально сравнить все четыре типа сервисов:

Заключение

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