Сервис (Service) в Kubernetes: реализация виртуального IP

октября 10, 2019

В данном посте описаны некоторые особенности, использованные в реализации виртуального IP для сервисов.

Избегать коллизий

Одна из основных философий Kubernetes - то, что вы не должны подвергаться ситуациям, которые могут привести к тому, что ваши действия потерпят неудачу не по вашей вине. Для дизайна ресурса Сервис это означает не заставлять вас выбирать свой собственный номер порта, если этот выбор может вступить в конфликт с выбором другого. Это ошибка изоляции.

Чтобы позволить вам выбрать номер порта для ваших Сервисов, мы должны убедиться, что никакие два Сервиса не могут конфликтовать. Kubernetes делает это, выделяя каждому сервису свой IP-адрес.

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

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

Сервисные IP-адреса

В отличие от IP-адресов Pod, которые фактически маршрутизируют к фиксированному месту назначения, сервисные IP-адреса фактически не отвечают одним хостом. Вместо этого kube-proxy использует iptables (логику обработки пакетов в Linux) для определения виртуальных IP-адресов, которые прозрачно перенаправляются по мере необходимости. Когда клиенты подключаются к VIP (Virtual IP), их трафик автоматически транспортируется в соответствующую конечную точку. Переменные среды и DNS для Сервисов фактически заполняются с точки зрения виртуального IP-адреса (и порта) Сервиса.

kube-proxy поддерживает три режима прокси - userpace, iptables и IPVS - каждый из которых работает немного по-своему.

Пространство пользователя (userpace)

В качестве примера рассмотрим приложение обработки изображений, описанное в первом посте о сервисах. При создании серверной службы мастер Kubernetes назначает виртуальный IP-адрес, например 10.0.0.1. Предполагая, что Сервисный порт - 1234, Сервис наблюдается во всех экземплярах kube-proxy в кластере. Когда прокси-сервер видит новую службу, он открывает новый случайный порт, устанавливает перенаправление iptables с виртуального IP-адреса на этот новый порт и начинает принимать подключения к нему.

Когда клиент подключается к виртуальному IP-адресу Сервиса, правило iptables срабатывает и перенаправляет пакеты на собственный порт прокси-сервера. “Service proxy” выбирает бэкэнд и начинает передавать трафик с клиента на бэкенд.

Это означает, что владельцы Сервисов могут выбрать любой порт, который они хотят, без риска коллизий. Клиенты могут просто подключиться к IP-адресу и порту, не зная, к каким Pod'ам они фактически обращаются.

Iptables

Опять же, рассмотрим приложение для обработки изображений, упомянутое выше. При создании бэкенд сервиса плоскость управления Kubernetes назначает виртуальный IP-адрес, например 10.0.0.1. Предполагая, что Сервисный порт - 1234, Сервис наблюдается во всех экземплярах kube-proxy в кластере. Когда прокси-сервер видит новый сервис, он устанавливает серию правил iptables, которые перенаправляют с виртуального IP-адреса на правила для каждого сервиса. Правила для каждого сервиса ссылаются на правила для каждой конечной точки, которые перенаправляют трафик (с использованием целевого NAT) на внутренние интерфейсы.

Когда клиент подключается к виртуальному IP-адресу Сервиса, вступает в силу правило iptables. Бэкенд выбирается (либо на основе соответствия сеанса, либо случайным образом), а пакеты перенаправляются на бэкенд. В отличие от прокси пользовательского пространства, пакеты никогда не копируются в пользовательское пространство, для работы виртуального IP-адреса не нужно запускать kube-proxy, а узлы видят трафик, поступающий с неизмененного IP-адреса клиента.

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

IPVS

Операции с iptables резко замедляются в крупномасштабном кластере, например, 10 000 сервисов. IPVS разработан для балансировки нагрузки и основан на хэш-таблицах в ядре. Таким образом, вы можете достичь согласованности производительности в большом количестве Сервисов с помощью IP-сервиса на основе Kube-Proxy. Между тем, на основе IPVS kube-proxy есть более сложные алгоритмы балансировки нагрузки (least conns, locality, weighted, persistence).

Поиск по этому блогу

Kubernetes блог