Services

В этой главе мы узнаем о сервисах, с помощью которых мы можем группировать Pods для предоставления общих точек доступа из внешнего мира. Мы узнаем о демонах kube-proxy, который запускается на каждом рабочем узле для обеспечения доступа к службам. Мы также поговорим об service discovery и service type, которые определяют сферу доступа службы.

Подключение пользователей к Pods

Для доступа к приложению пользователю необходимо подключиться к Pods. Поскольку Pods являются эфемерными по своей природе, ресурсы, такие как выделенные ему IP-адреса, не могут быть статическими. Pods могут умереть внезапно или быть перенесены на основе существующих требований.

Возьмем, например, сценарий, в котором пользователь подключен к Pod, используя IP-адрес:

Неожиданно Pod, к которому пользователь подключен умирает и контроллер создает новый Pod. Новый Pod будет иметь новый IP-адрес, который не будет известен автоматически пользователю более раннего Pod.

Чтобы преодолеть эту ситуацию, Kubernetes предоставляет абстракцию более высокого уровня под названием Service, которая логически группирует модули и политику для доступа к ним. Эта группировка достигается с помощью Labels и Selectors, о которых мы говорили в предыдущей главе.

Например, в следующем графическом представлении мы использовали ключевое слово app в качестве label, а frontend и db в качестве значений для различных pods.

Используя селектор (app == frontend и app == db), мы можем сгруппировать их в две логические группы: одну с 3-мя pods и одну с одним pod.

Мы можем назначить имя логической группе, называемой Service name. В нашем примере мы создали две службы, frontend-svc и db-svc, и у них есть app==frontend и app==db, соответственно.