Привести: в практике Kubernetes, развертывание, чтобы решить миграцию POD, порта POD узла, динамическое распределение домена, разработчики должны выбрать соответствующий приемный раствор. Перед лицом многих входных продуктов на рынке, как разработчики рассказывают свои преимущества и недостатки? Как вы выбираете подходящее техническое решение в сочетании с собственным техническим стеком? В этой статье Tencent Yun Marmware Core R & D Engineer Li Hui представит вам, как использовать выделение технологии контроллера входа Kubernates. (Редактор: промежуточное программное обеспечение маленькая q сестра)

Глоссарий

Для чтения этой статьи необходимо ознакомиться со следующими основными понятиями:

Кластер: относится к набору облачных ресурсов, необходимых для работы контейнера, включая несколько облачных серверов, балансировщики нагрузки и другие облачные ресурсы.
Экземпляр (Pod): экземпляр состоит из одного или нескольких связанных контейнеров, которые совместно используют одно и то же хранилище и сетевое пространство.
Рабочая нагрузка (узел): объект ресурса Kubernetes, который управляет созданием, планированием и автоматическим контролем всего жизненного цикла реплик Pod.
Сервис: микросервис, состоящий из нескольких одинаково настроенных экземпляров (подов) и правил доступа к этим экземплярам (подам).
Ingress: Ingress - это набор правил для использования внешнего традиции HTTP (S) для обслуживания (услуга).

Состояние доступа Kubernetes

△ Внешний доступ к Kubernetes

В Kubernetes службы и IP-адреса Pod в основном используются службами для доступа внутри кластера и невидимы для приложений за пределами кластера. Как решить эту проблему? Чтобы разрешить внешним приложениям доступ к службам в кластере Kubernetes, обычно используются решения NodePort и LoadBalancer.

Каждое из этих двух решений на самом деле имеет некоторые недостатки:

Недостаток NodePort в том, что на порт можно смонтировать только один сервис, а для большей доступности нужно строить дополнительный балансировщик нагрузки.
Недостатком LoadBalancer является то, что у каждой службы должен быть свой IP-адрес, будь то внутренний IP-адрес или внешний IP-адрес. В большинстве случаев, чтобы обеспечить возможности LoadBalancer, как правило, необходимо полагаться на поставщиков облачных услуг.

На практике и при развертывании Kubernetes для решения таких проблем, как миграция Pod, перенос Node Pod, динамическое выделение доменных имен или динамическое обновление фоновых адресов Pod, было создано решение Ingress.

Выбор входа

Недостатки Nginx Ingress

Ingress — очень важная запись внешнего сетевого трафика в Kubernetes. По умолчанию в Kubernetes рекомендуется значение Nginx Ingress. Чтобы отличить его от коммерческой версии Ingress, предоставляемой Nginx, я называю его Kubernetes Ingress.

Kubernetes Ingress, как следует из названия, представляет собой платформу, основанную на Nginx. Nginx в настоящее время является самым популярным HTTP-сервером Nginx в мире. Я думаю, что все знакомы с Nginx, что является преимуществом. У него также есть то преимущество, что Nginx Ingress требует очень небольшой настройки для подключения к кластеру Kubernetes, и есть много документации, которая поможет вам его использовать. Для большинства людей или стартапов, которые плохо знакомы с Kubernetes, Nginx Ingress действительно является очень хорошим выбором.

Но когда Nginx Ingress используется в некоторых больших средах, возникает много проблем:

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

Принцип выбора входа

Поскольку я обнаружил, что с Nginx Ingress возникает много проблем, стоит ли мне подумать о выборе другого, более эффективного Ingress с открытым исходным кодом? На рынке есть как минимум дюжина Ingress, которые проще в использовании, чем Kubernetes Ingress, так как же выбрать тот, который подходит именно вам, из такого количества Ingress?

Ingress в конечном итоге основан на HTTP-шлюзах.На рынке в основном есть несколько типов HTTP-шлюзов: Nginx, нативные шлюзы Golang и недавно появившийся Envoy. Но каждый разработчик хорош в разных стеках технологий, поэтому подходящий Ingress тоже будет разным.

Итак, вопрос в том, как выбрать более полезный Ingress? Или, чтобы сузить круг, разработчики, знакомые с Nginx или OpenResty, какой Ingress им выбрать?

Позвольте мне рассказать о моем опыте выбора контроллера Ingress.

△ Принцип выбора

Основные характеристики

Во-первых, я считаю, что Ingress-контроллер должен иметь следующие основные функции, если у вас нет этих функций, вы можете передать его напрямую.

Должен быть с открытым исходным кодом, не с открытым исходным кодом нельзя использовать.
Поды очень часто меняются в Kubernetes, и обнаружение сервисов очень важно.
Сейчас, когда HTTPS очень популярен, возможности TLS или SSL также очень важны, например, функция управления сертификатами.
Поддержка распространенных протоколов, таких как WebSocket, а в некоторых случаях также может потребоваться поддержка таких протоколов, как HTTP2 и QUIC.

Базовое программное обеспечение

Как упоминалось ранее, все хорошо разбираются в разных технических платформах, поэтому очень важно выбрать HTTP-шлюз, с которым вы лучше знакомы. Например, собственный шлюз Nginx, HAProxy, Envoy или Golang. Поскольку вы знакомы с его принципами, вы можете добиться быстрой посадки в использовании.

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

Функциональные требования

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

Протокол: поддерживать ли HTTP2, HTTP3;
Алгоритм балансировки нагрузки: могут ли самые простые алгоритмы балансировки нагрузки WRR и последовательного хеширования соответствовать требованиям, или требуется более сложный алгоритм балансировки нагрузки, подобный EWMA.
Поток полномочий аутентификации: требуется только простая аутентификация или более сложные методы аутентификации. Или его нужно интегрировать и можно быстро разработать функцию аутентификации, такую как Tencent Cloud IM. В дополнение к упомянутым выше проблемам, заключающимся в том, что перезагрузка Nginx занимает много времени, а возможности расширения подключаемых модулей плохие, у Kubernetes Ingress также есть проблема, заключающаяся в том, что способность внутреннего узла регулировать вес недостаточно гибка.

Выберите APISIX в качестве контроллера Ingress.

Лично я рекомендую APISIX вместо Kubernetes Ingress. Хотя APISIX намного менее функционален, чем Kong, хорошие возможности маршрутизации, гибкие возможности подключаемых модулей и собственная высокая производительность APISIX могут компенсировать некоторые недостатки в выборе Ingress. Для программистов, использующих разработку Nginx или Openresty, если вас не устраивает текущий Ingress, я рекомендую использовать APISIX в качестве Ingress.

Как использовать APISIX в качестве Ingress? Сначала мы должны сделать различие: Ingress — это определение имени или правила Kubernetes, а Ingress-контроллер — это компонент, который синхронизирует состояние кластера Kubernetes со шлюзом. Но сам APISIX — это просто шлюз API, как реализовать APISIX в качестве Ingress-контроллера? Давайте начнем с краткого рассмотрения того, как реализован Ingress.

Для реализации Ingress по сути всего две части:

Часть 1. Конфигурацию в кластере Kubernetes или состояние в кластере Kubernetes необходимо синхронизировать с кластером APISIX.
Часть 2. Некоторые понятия в APISIX, такие как сервисы, восходящий поток и т. д., необходимо определить как CRD в Kubernetes.

Если реализована вторая часть, APISIX можно быстро сгенерировать с помощью конфигурации Kubernetes Ingress. Конфигурация, связанная с APISIX, может быть создана с помощью контроллера APISIX Ingress. В настоящее время, чтобы быстро внедрить APISIX в качестве Ingress, поддерживающего Kubernetes, мы создали проект с открытым исходным кодом под названием Ingress controller.

Схема архитектуры контроллера входящего трафика

На приведенном выше рисунке показана общая архитектура проекта контроллера Ingress. Левая часть — это кластер Kubernetes, куда вы можете импортировать некоторые файлы yaml, чтобы внести изменения в конфигурацию Kubernetes. Правая часть — это кластер APISIX, а также его плоскость управления и плоскость данных. Как видно из схемы архитектуры, APISIX Ingress выступает в роли соединителя между кластером Kubernetes и кластером APISIX. В основном он отвечает за мониторинг изменений узлов в кластере Kubernetes и синхронизацию состояния в кластере с кластером APISIX. Кроме того, поскольку Kubernetes выступает за высокую доступность всех компонентов, в начале разработки APISIX Ingress мы приняли двухузловой или многоузловой режим, чтобы обеспечить высокую доступность контроллера APISIX Ingress.

Суммировать

Горизонтальное сравнение различных типов Ingress

По сравнению с популярными на рынке контроллерами Ingress давайте кратко сравним преимущества и недостатки APISIX Ingress. На картинке выше представлена таблица, сделанная зарубежными разработчиками для выбора Kubernetes Ingress. На основе исходной формы в сочетании с собственным пониманием я добавил функцию APISIX Ingress. Мы видим, что APISIX крайний слева, за ним Kubernetes Ingress и Kong Ingress, а Traefik — это Ingress, основанный на Golang. HAproxy относительно распространен и раньше был популярным балансировщиком нагрузки. Istio и Ambassador — два очень популярных Ingress за рубежом.

Далее мы суммируем преимущества и недостатки каждого из этих Ingress:

APISIX Ingress: преимущества APISIX Ingress также упоминались ранее: он обладает очень мощными возможностями маршрутизации, гибкими возможностями расширения подключаемых модулей и отличной производительностью. В то же время его недостатки также очень очевидны.Хотя APISIX имеет много функций после того, как он был открытым исходным кодом, в нем отсутствуют целевые случаи, и нет соответствующей документации, которая бы помогла вам использовать эти функции.
Kubernetes Ingress: Nginx Ingress, рекомендованный Kubernetes по умолчанию. Его главные преимущества — простота и доступность. Недостаток в том, что проблема долгой перезагрузки Nginx никак не решается. Кроме того, несмотря на то, что доступно много плагинов, возможности расширения плагинов очень слабы.
Nginx Ingress: основное преимущество заключается в том, что он полностью поддерживает протоколы TCP и UDP, но не имеет других функций, таких как методы аутентификации и планирование трафика.
Конг: Это сам по себе API-шлюз, а также пионер, представивший API-шлюз в Kubernetes как Ingress. Кроме того, по сравнению с пограничными шлюзами, Kong отлично справился с аутентификацией, ограничением тока и развертыванием в градациях серого. У Kong Ingress также есть большое преимущество: он предоставляет некоторые определения API и сервисов, которые можно абстрагировать в CRD Kubernetes, а состояние можно синхронизировать с кластером Kong через конфигурацию Kubernetes Ingress. Недостатком является то, что развертывание особенно сложно, а с точки зрения высокой доступности APISIX уступает ему.
Traefik: Ingress на основе Golang, который сам по себе является шлюзом микросервисов, широко используется в сценариях Ingress. Его основная платформа основана на Golang, поддерживает множество протоколов, недостатков, в общем-то, нет. Если вы знакомы с Golang, также рекомендуется использовать его.
HAproxy: известный балансировщик нагрузки. Его главное преимущество заключается в том, что он обладает очень мощными возможностями балансировки нагрузки и не доминирует в других аспектах.
И Istio Ingress, и Ambassador Ingress основаны на очень популярном Envoy. Честно говоря, я не думаю, что у этих двух Ingress есть какие-то недостатки, пожалуй, единственный недостаток в том, что они основаны на платформе Envoy, с которой все не очень хорошо знакомы, и порог для начала будет относительно высоким.

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

об авторе

Ли Хуэй, главный специалист по исследованиям и разработкам Tencent Cloud Middleware API Gateway, Apache APISIX PPMC. Люблю открытый исходный код, готов делиться, активен в сообществе Apache APISIX.

Добро пожаловать, чтобы отсканировать код, чтобы подписаться на нашу общедоступную учетную запись WeChat, и с нетерпением ждем встречи с вами ~