Создание сервиса для открытия доступа к приложению

Темы

• Узнать о сервисах в Kubernetes
• Разобраться с тем, как метки и объекты LabelSelector связаны с сервисом
• Открыть доступ к приложению вне кластера Kubernetes через сервис

Обзор сервисов Kubernetes

Под — это расходный материал в Kubernetes. У подов есть жизненный цикл. Когда рабочий узел завершается, запущенные поды в узле также уничтожаются. После этого ReplicaSet попытается автоматически вернуть кластер обратно в требуемое состояние, создавая новые поды, чтобы поддержать работоспособность приложения. Другой пример — бэкенд для обработки изображений с 3 репликами. Поскольку это взаимозаменяемые реплики, то они не влияют на фронтенд-часть, даже если под был уничтожен и пересоздан. Тем не менее, каждый под в кластере Kubernetes имеет уникальный IP-адрес, даже под на одном и том же узле, поэтому должен быть способ автоматической координации изменений между подами, чтобы приложения продолжали функционировать.

Сервис в Kubernetes — это абстрактный объект, который определяет логический набор подов и политику доступа к ним. Сервисы создают слабую связь между подами, которые от них зависят. Сервис создаётся в формате YAML (рекомендуемый формат) или JSON, как и все остальные объекты в Kubernetes. Как правило, набор подов для сервиса определяется LabelSelector (ниже описано, в каких случаях понадобится сервис без указания selector в спецификации).

Хотя у каждого пода есть уникальный IP-адрес, эти IP-адреса не доступны за пределами кластера без использования сервиса. Сервисы позволяют приложениям принимать трафик. Сервисы могут быть по-разному открыты, в зависимости от указанного поля type в ServiceSpec:

• ClusterIP (по умолчанию) - открывает доступ к сервису по внутреннему IP-адресу в кластере. Этот тип делает сервис доступным только внутри кластера.
• NodePort - открывает сервис на одном и том же порту каждого выбранного узла в кластере с помощью NAT. Делает сервис доступным вне кластера, используя <NodeIP>:<NodePort>. Является надмножеством ClusterIP.
• LoadBalancer - создает внешний балансировщик нагрузки в текущем облаке (если это поддерживается) и назначает фиксированный внешний IP-адрес для сервиса. Является надмножеством NodePort.
• ExternalName - открывает доступ к сервису с указанным именем (определённое в поле externalName в спецификации) и возвращает запись CNAME. Прокси не используется. Для этого типа требуется версия kube-dns 1.7 или выше.

Более подробно узнать о различных типах сервисах можно в руководстве Использование IP-порта источника. Также изучите Подключение приложений к сервисам.

Кроме этого, обратите внимание, что в некоторых случаях в сервисах не определяется selector в спецификации. Сервис без selector не будет создавать соответствующий объект конечной точки (Endpoint). Таким образом, пользователь может вручную назначить сервис определённым конечным точкам. Использование type: ExternalName — это другой вариант использования, когда не нужно определять селектор в сервисе.

Сервисы и метки

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

Сервисы для выбора набора подов используют метки и селекторы. Метки — пары ключ-значение, добавленные к объектам; например, они могут использоваться чтобы:

• Идентифицировать объекты для окружений разработки, тестирования и продакшена
• Добавить теги версии
• Классифицировать объекты через теги

Метки могут добавляться во время создания объектов или после этого. Они также могут быть изменены в любое время. Теперь давайте откроем доступ к приложению путём создания сервиса и добавление меток.