A First Look at Kubernetes Service APIs

Предисловие

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

Для унификации различных реализаций Ingress и упрощения единого управления в Kubernetes сообщество SIG-NETWORK выпустило Kubernetes Service APIs, набор стандартных реализаций, называемых Ingress второго поколения.

Описание темы

Эта статья представляет собой введение в основные концепции Kubernetes Service APIs, начиная с нескольких вопросов.

Введение

Kubernetes Service APIs называют технологией Ingress второго поколения, но в чем они лучше первого поколения

Kubernetes Service APIs не были разработаны исключительно для Ingress, а скорее для улучшения сетевого взаимодействия сервисов с акцентом на следующие аспекты: выразительность, масштабируемость и RBAC.

1. Больше функций, например, управление трафиком на основе заголовков, весов.

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"

2. Улучшение масштабируемости: Service APIs вводят концепцию многоуровневого API, где каждый уровень предоставляет свой интерфейс, позволяя другим пользовательским ресурсам взаимодействовать с API для более детального (API-уровневого) управления.

3. RBAC, ориентированный на роли: Реализация многоуровневого API, одна из идей заключается в проектировании ресурсов с точки зрения пользователей. Эти ресурсы в конечном итоге будут сопоставлены с общими ролями, используемыми при запуске приложений на Kubernetes.

Какие ресурсы абстрагируют Kubernetes Service APIs

На основе ролей пользователей Kubernetes Service APIs определяют следующие ресурсы:

GatewayClass, Gateway, Route

1. GatewayClass определяет набор типов шлюзов с общей конфигурацией и поведением:

• Отношение к Gateway, аналогично аннотации ingess.class в ingress;
• GatewayClass определяет группу шлюзов, которые разделяют одну и ту же конфигурацию и поведение. Каждый GatewayClass будет обрабатываться одним контроллером, при этом контроллер имеет отношение "один ко многим" с GatewayClass;
• GatewayClass является ресурсом кластера. Для функционирования шлюза должен быть определен хотя бы один GatewayClass.

2. Gateway запрашивает точку, в которой трафик может быть преобразован в сервисы внутри кластера:

• Что он делает: переносит трафик извне кластера внутрь кластера. Это реальная сущность ingress;
• Он определяет запрос на конкретную конфигурацию LB, которая также является реализацией конфигурации и поведения GatewayClass;
• Ресурсы Gateway могут быть созданы непосредственно оператором или контроллером, обрабатывающим GatewayClass;
• Gateway и Route находятся в отношении "многие ко многим".

3. Route описывает, как трафик, проходящий через шлюз, сопоставляется с сервисом.

Кроме того, Kubernetes Service APIs определяют ресурсный объект BackendPolicy для обеспечения гибкой конфигурации сервисов бэкенда.

Объект BackendPolicy позволяет настраивать TLS, проверки здоровья и указывать тип сервиса бэкенда, например, сервис или под.

Какие изменения привнесут Kubernetes Service APIs

Kubernetes Service APIs, как стандарт реализации, привносят следующие изменения.

1. Универсальность: может быть несколько реализаций, так же как и множество реализаций ingress. ingress-контроллеры могут быть настроены в соответствии с характеристиками шлюза, но все они имеют согласованную структуру конфигурации. Одна структура данных может использоваться для настройки нескольких ingress-контроллеров.
2. Концепция классов: GatewayClasses позволяют настраивать различные типы реализаций балансировки нагрузки. Эти классы позволяют пользователю легко и явно понимать, какие функции могут быть использованы как сами ресурсные модели.
3. Общие шлюзы: Позволяя независимым ресурсам маршрутизации HTTPRoute быть привязанными к одному и тому же GatewayClass, они могут совместно использовать балансировщики нагрузки и VIP. Разделение по пользователям позволяет командам безопасно использовать инфраструктуру, не заботясь о конкретной реализации нижнего уровня Gateway.
4. Ссылки на бэкенд с типами: Ссылки на бэкенд с типами позволяют маршрутам ссылаться на Kubernetes Services или любой другой тип ресурсов Kubernetes, предназначенных для использования в качестве бэкенда шлюза, таких как под, statefulset, например, база данных, или даже доступный внешний ресурс кластера.
5. Перекрестные ссылки между пространствами имен: Маршруты из разных пространств имен могут быть привязаны к одному Gateway, что позволяет осуществлять доступ между пространствами имен. Также можно ограничить диапазон пространств имен, к которым может обращаться Route под Gateway.

Какие реализации Ingress поддерживают Kubernetes Service APIs

Известные реализации Ingress, которые поддерживают ресурсные объекты Kubernetes Service APIs на уровне кода, это Contour и ingress-gce.

Как Kubernetes Service APIs управляют правами на чтение и запись ресурсов

Kubernetes Service APIs разделены на 3 роли на основе пользовательского измерения:

1. Поставщик инфраструктуры GatewayClass;
2. Оператор кластера Gateway;
3. Разработчик приложений Route.

RBAC (Role Based Access Control) — это стандарт, используемый для авторизации в Kubernetes. Он позволяет пользователям настраивать, кто может выполнять операции над определенным диапазоном ресурсов. RBAC может быть использован для предоставления каждой из определенных выше ролей.

В большинстве случаев ожидается, что все роли смогут читать все ресурсы.

Трехуровневая модель имеет следующие права на запись.

Какие точки расширения есть у Kubernetes Service APIs

Требования к шлюзам очень разнообразны, и существует множество способов реализации одного и того же сценария, каждый из которых имеет свои преимущества и недостатки. Kubernetes Service APIs выделили многоуровневые ресурсные объекты, а также оставили некоторые точки расширения.

Kubernetes Service APIs в настоящее время сосредоточены на Route:

• RouteMatch расширяет правила сопоставления Route.
• Указание Backend расширяет конкретные типы сервисов бэкенда, такие как файловые системы, функциональные выражения и т.д., помимо упомянутых выше ресурсов Kubernetes.
• Фильтр Route добавляет расширения к жизненному циклу Route для обработки запросов/ответов.
• Если ни одно из вышеуказанных расширений не может быть удовлетворено, можно полностью настроить Route.

Заключение

Эта статья предоставила базовое введение в Kubernetes Service APIs, задавая вопросы. В целом, Kubernetes Service APIs уточняют множество лучших практик ingress, таких как улучшенная выразительность, которая фактически расширяет возможности Route, и объекты BackendPolicy, которые могут указывать практически любой ресурс Kubernetes для бэкенда. Kubernetes Service APIs в настоящее время определяют ресурсные объекты на широком уровне, но внутри ресурсных объектов все еще много деталей, которые необходимо обсудить, прежде чем они будут определены, чтобы предотвратить возможные конфликтные сценарии, и есть определенные переменные в структуре.