Управление тем, как приложения в кластере Kubernetes связаны с внешним миром, является фундаментальной задачей.
В течение многих лет стандартный подход включал API Kubernetes Ingress. Несмотря на функциональную для базовых HTTP и HTTPS-маршрутизации, Ingress часто требует сложных, нестандартных аннотаций для обработки более продвинутых сценариев, что приводит к проблемам переносимости и головным болям конфигурации.
Например, Nginx Ingress имеет несколько аннотаций для настройки ресурса Ingress, что делает его запутанным и громоздким для управления.
Признавая эти ограничения, сообщество Kubernetes разработало API Gateway, более мощный, гибкий и стандартизированный преемник, предназначенный для упрощения управления трафиком.
API Gateway является официальным проектом Kubernetes, представляющим следующее поколение API для входа, балансировку нагрузки и потенциально даже взаимодействие сетки обслуживания. Он предоставляет унифицированную спецификацию для настройки маршрутизации сетевого трафика, стремясь быть выразительным, расширяемым и выровненным с различными ролями, связанными с управлением инфраструктурой и приложениями Kubernetes.
Понимание ограничений входа
Прежде чем погрузиться в API шлюза, это помогает понять компонент, который он улучшает. Kubernetes Ingress определяет правила для разоблачения услуг HTTP и HTTPS, работающих в кластере для внешних клиентов. Как правило, он опирается на контроллер входа, отдельную часть программного обеспечения, работающего в кластере, в котором наблюдается ресурсы вводящих ресурсов и соответственно настраивает балансирующий балансировщик или прокси -сервер.
В то время как простой путь и маршрутизацию на основе хоста хорошо работают с Ingress, его основная спецификация ограничена. Такие функции, как маршрутизация на основе заголовков, расщепление трафика для канарских выпусков, расширенная конфигурация TLS или поддержка протоколов, отличных от HTTP/S, часто требуют аннотаций, специфичных для поставщиков.
Этот подход, управляемый аннотациями, фрагменты экосистемы, что затрудняет порт между различными контроллерами проникновения или облачными средами. Кроме того, ресурс с одним входным ресурсом часто размывает линии ответственности между операторами инфраструктуры и разработчиками приложений, что может привести к конфликтам конфигурации или чрезмерно широким разрешениям.
API Gateway рассматривает эти недостатки с помощью принципиально переработанного подхода. Это не единый ресурс, а набор связанных типов API, определяемых как пользовательские определения ресурсов (CRD), которые более структурируют сетей службы. Обычно вам необходимо установить эти CRD и совместимую реализацию контроллера в свой кластер для использования API шлюза.
Основная идея состоит в том, чтобы обеспечить стандартный, выразительный и ролевой интерфейс для настройки как L4 (TCP/UDP), так и L7 (HTTP/S, GRPC). Он направлен на то, чтобы внедрить стандартные, расширенные возможности маршрутизации в основную спецификацию, сокращение потребности в невозможных аннотациях и содействие согласованности в разных реализациях.
Ролевая модель ресурса
Ключевым инновацией API Gateway является ее модель ресурсов, которая разработана вокруг различных организационных ролей. Это разделение проблем разъясняет обязанности и обеспечивает более безопасное, более масштабируемое управление сетевой инфраструктурой.
Основными ресурсами являются шлюз, шлюз и различные типы маршрутов. Gatewayclass-это кластерный шаблон, определяемый поставщиком инфраструктуры, который указал контроллер (например, Nginx, Engine, Haproxy или реализация облачного поставщика), который будет управлять шлюзами этого класса.
Оператор кластера обычно создает ресурс шлюза. Он запрашивает конкретную точку входа трафика, такую как IP -адрес балансировщика нагрузки, на основе шейного класса. Шлюз определяет слушателей, определяя порты, протоколы и потенциально настройки TLS. Важно отметить, что он также определяет, какие ресурсы маршрута могут прикрепляться к ним, часто на основе пространств имен или метки.
Наконец, маршрутные ресурсы, такие как Httproute, Tcproute или Grpcroute, обычно управляются разработчиками приложений. Эти ресурсы содержат конкретные правила для того, как трафик, прибывающийся со слушателем Gateway, должен быть нанесен на карту для бэкэндов Kubernetes Services.
Например, Httproute определяет правила, основанные на именах хостов, путей, заголовков или методов. Чтобы маршрут стал активным, он должен ссылаться на родительский шлюз, и этот шлюз должен явно разрешить вложение.
Этот многослойный подход позволяет командам платформы управлять базовой инфраструктурой (GatewayClass, Gateway) и устанавливать политики. Напротив, команды приложений могут самостоятельно управлять логикой маршрутизации, специфичной для их услуг (ресурсы маршрута) в рамках установленных границ.
Влияние сетки обслуживания и гамма -инициативы
В то время как API Gateway первоначально сосредоточился на внешнем проникновении (север-юг), его принципы проектирования резонировали с проблемами управления внутренним, сервис-сервис-сервис (восток-запад), традиционно домен обслуживания, такие как Istio или Linkerd. Сетки обслуживания предоставляют такие возможности, как взаимные TLS, мелкозернистый контроль трафика и наблюдение для внутренней связи.
Гибкая модель ресурсов API Gateway, в частности, ресурсы маршрута (Httproute, Grpcroute и т. Д.), Представляла возможность объединить опыт конфигурации как для трафика, так и для трафика. Это привело к инициативе гамма (Gateway API для управления и администрирования сетки).
Gamma расширяет модель API Gateway для настройки поведения сервисной сетки. Основная концепция включает в себя прикрепление ресурсов маршрута непосредственно к объектам обслуживания Kubernetes, а не к объектам шлюза.
Это позволяет разработчикам использовать ту же знакомую спецификацию HTTPROUTE, чтобы определить правила для того, как следует обрабатывать трафик между службами в сетке, контролируя такие аспекты, как таймауты, повторные ресурсы или маршрутизацию на основе пути для внутренних вызовов.
Цель состоит в том, чтобы предоставить единый, согласованный API для управления как внешнего доступа (через вложение шлюза), так и внутренние взаимодействия с сервисом (через вложение службы), упрощая общую ландшафт конфигурации сети в Kubernetes.
В то время как Gamma предлагает стандартизированный подход, стоит отметить, что конкретные реализации сервисной сетки могут по -прежнему предлагать свои собственные CRD для расширенных функций за пределами объема стандартных типов маршрутов API Gateway. Эта интеграция подчеркивает амбиции API Gateway служить комплексным стандартом обслуживания для Kubernetes.
Практические последствия для разработчиков
Для разработчиков API Gateway предлагает более прямой контроль и лучший опыт. Вы можете определить сложную логику маршрутизации для вашего приложения, используя HTTPROUTE или другие типы маршрутов, указав сопоставление пути, условия заголовка, разрывы трафика между версиями обслуживания, изменениями запроса/ответа и тайм -аутами непосредственно.
Эта конфигурация живет вместе с вашим кодом приложения и может управляться независимо, если она придерживается правил, установленных оператором кластера на родительском шлюзе. Это четкое разделение дает возможность разработчикам эффективно управлять точками входа в приложение, не требуя глубоких знаний о базовой инфраструктуре или полагаясь на потенциально хрупкие аннотации.
Соображения для усыновления
Хотя API Gateway, Gateway, вводит больше концепций, чем ресурс с одним входным ресурсом. Его модель с несколькими ресурсами (Gatewayclass, Gateway, Route, Relightgrant) имеет более крутую кривую обучения. Кроме того, поскольку он опирается на CRD, вы должны убедиться, что в вашем кластере установлены определения API и совместимый контроллер, прежде чем вы сможете его использовать. Экосистема контроллеров и инструментов быстро созревает, но в некоторых областях все еще может быть менее обширной, чем давно установленная экосистема Ingress.
Вывод: будущее сети Kubernetes
API API Kebernetes Gateway представляет собой значительный шаг вперед от ограничений INGRESS API. Предлагая стандартизированную, выразительную, расширяемую и ориентированную на ролевую модель, она обеспечивает гораздо более надежную основу для управления сетевым трафиком в современных средах Kubernetes. Его нативная поддержка передовой маршрутизации, нескольких протоколов, четкого разделения проблем и интеграции с концепциями сервисной сетки обеспечивает как операторы платформы, так и разработчики приложений.
Требуя некоторых первоначальных инвестиций для понимания своих концепций, API Gateway обеспечивает большую переносимость, гибкость и контроль, позиционируя его как стратегическое направление для управления тем, как приложения соединяются в пределах и за пределами кластеров Kubernetes.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Janakiram MSV является основным аналитиком в Janakiram & Associates и адъюнкт -преподавателем Международного института информационных технологий. Он также является квалифицированным Google Cloud Developer, сертифицированным архитектором решений Amazon, сертифицированным разработчиком Amazon, … Подробнее от Janakiram MSV
