Service и Ingress в Kubernetes

Сервис, метки и список адресов

Адрес пода недолговечен: я это видел, при пересоздании он сменился. Поэтому обращаются не к подам, а к сервису. У сервиса есть постоянный адрес внутри кластера и постоянное имя, которое разрешает встроенный сервер имён.

Связь сервиса с подами - по МЕТКАМ, а не по списку. Сервис говорит «мне все поды с меткой приложение равно web», и кластер сам поддерживает список подходящих адресов. Я наблюдал это вживую: удалил под - из списка ушёл его адрес и появился адрес нового.

// Отсюда самая частая поломка новичка: сервис есть, а список адресов пуст. Причин ровно две - метки в сервисе не совпадают с метками подов, либо поды не прошли пробу готовности. Проверяется это одной командой, которая показывает список адресов за сервисом: пусто - значит, ищите одну из этих двух причин, а не проблемы в сети.

сервис

постоянное имя и адрес поверх меняющегося набора подов

метки

пары имя-значение на объектах; по ним сервис и находит свои поды

список адресов

фактические адреса подов за сервисом; пустой список - главный симптом

Имена и поиск

Внутри кластера у каждого сервиса есть полное имя вида имя-сервиса.пространство.svc.cluster.local, где пространство - это отсек кластера, в котором живёт группа объектов. Поды при этом настроены так, что короткого имени достаточно: я посмотрел настройки резолвера внутри пода и увидел строку поиска с тремя суффиксами и порог в пять точек.

Это ровно та настройка, о которой я рассказывал в теме про службу имён, и цена у неё измеримая: имя с двумя точками считается неполным, поэтому сначала перебираются суффиксы кластера и только потом спрашивается настоящее имя. На обращениях к внешним адресам это добавляет лишние вопросы к серверу имён на каждый запрос.

// Лечится это точкой в конце внешнего имени или своими настройками резолвера для конкретного пода. А внутри кластера коротким именем пользоваться удобно и правильно - к соседу в том же пространстве обращаются просто по имени сервиса.

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

имя.пространство.svc.cluster.local; внутри достаточно короткого

суффиксы поиска

что дописывается к неполному имени; для внешних адресов это лишние запросы

Типы сервисов и вход снаружи

Внутренний сервис - тот, что я поднимал: адрес виден только внутри кластера, снаружи не достучаться. Это тип по умолчанию и правильный выбор для общения сервисов между собой.

Порт на узле открывает один и тот же порт на всех узлах кластера и заворачивает его на сервис. Работает везде, но порт из ограниченного диапазона и адрес узла надо где-то держать. Балансировщик просит внешний адрес у облака - удобно, но каждый такой сервис это отдельный платный балансировщик, и на тридцати сервисах это заметная сумма.

// Поэтому наружу обычно выставляют ОДИН вход, а за ним маршрутизируют по именам и путям. Правила описываются отдельным объектом, а исполняет их контроллер входа - по сути посредник, который принимает запросы снаружи и раздаёт их нужным сервисам внутри. Один внешний адрес, один сертификат на домен, десятки сервисов за ним.

внутренний сервис

адрес виден только внутри кластера; тип по умолчанию

контроллер входа

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

Как отвечать: «Сервис создан, но приложение по нему не отвечает. Где искать?»

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

Ответ даёт порядок проверки от самого частого к редкому и разбивает проблему на три различимых шага. Именно так это и делают в жизни.

На чём валятся

• −Не смотрят список адресов за сервисом и ищут проблему в сети.
• −Путают метки сервиса и метки подов.
• −Забывают, что под без пройденной пробы готовности в список не попадает.
• −Заводят отдельный внешний балансировщик на каждый сервис и платят за все.
• −Прописывают адреса подов вместо имён сервисов.