Возможности и вызовы технологической эволюции в Cloud Native

В настоящее время Cloud Native становится все более популярным, и CNCF определяет Cloud Native как:

• Основанный на современной и динамичной среде, также известной как облачная среда.
• С использованием контейнеризации как фундаментальной технологии, включая Service Mesh, неизменяемую инфраструктуру, декларативные API и т.д.
• Ключевые особенности включают автоматическое масштабирование, управляемость, наблюдаемость, автоматизацию, частые изменения и т.д.

Согласно опросу CNCF за 2021 год, в сообществе Kubernetes насчитывается значительное количество участников (более 62 000). С учетом текущих технологических трендов все больше компаний инвестируют в Cloud Native и присоединяются к этому направлению для активного развертывания в облаке. Почему компании внедряют Cloud Native в процессе разработки, и что это означает для них?

Технические преимущества Cloud Native

Популярность Cloud Native обусловлена его преимуществами на техническом уровне. Технология Cloud Native включает два основных аспекта: контейнеризацию, возглавляемую Docker, и оркестрацию контейнеров, возглавляемую Kubernetes.

Docker представил контейнерные образы в технологический мир, сделав их стандартизированной единицей доставки. На самом деле, до Docker технология контейнеризации уже существовала. Давайте поговорим о более современной технологии — LXC (Linux Containers) в 2008 году. По сравнению с Docker, LXC менее популярен, поскольку Docker предоставляет контейнерные образы, которые могут быть более стандартизированными и удобными для миграции. Кроме того, Docker создал публичный сервис DockerHub, который стал крупнейшим в мире репозиторием контейнерных образов. Кроме того, технология контейнеризации также обеспечивает определенную степень изоляции ресурсов, включая не только изоляцию CPU, памяти и других ресурсов, но и изоляцию сетевого стека, что упрощает развертывание нескольких копий приложений на одной машине.

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

Сейчас все больше компаний активно внедряют Kubernetes и преобразуют свои приложения для развертывания на Kubernetes. И Cloud Native, о котором мы говорим, фактически основан на предпосылке Kubernetes, краеугольном камне технологии Cloud Native.

Преимущества контейнеризации

1. Стандартизированная доставка

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

2. Портативность и легкость, экономия затрат

Технология контейнеризации достигает определенной изоляции с помощью возможностей ядра Linux, что упрощает миграцию. Кроме того, технология контейнеризации может напрямую запускать приложения, что легче в технической реализации по сравнению с технологией виртуализации, без необходимости использования ОС в виртуальной машине.

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

3. Удобство управления ресурсами

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

Преимущества оркестрации контейнеров

1. Упрощение рабочего процесса

В Kubernetes развертывание приложений легче управлять, чем в Docker, поскольку Kubernetes использует декларативную конфигурацию. Например, пользователь может просто объявить в конфигурационном файле, какой контейнерный образ будет использоваться приложением и какие порты сервиса будут открыты, без необходимости дополнительного управления. Операции, соответствующие декларативной конфигурации, значительно упрощают рабочий процесс.

2. Повышение эффективности и экономия затрат

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

С ростом популярности Docker и Kubernetes вы увидите, что их появление принесло значительные инновации и возможности для доставки приложений. Контейнерные образы как стандартные единицы доставки сокращают процесс доставки и упрощают интеграцию с системами CI/CD.

Учитывая, что доставка приложений становится быстрее, как архитектура приложений следует тренду Cloud Native?

Эволюция архитектуры приложений: от монолитов, микросервисов до Service Mesh

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

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

Кроме того, микросервисная архитектура включает различные паттерны. Например, паттерн "база данных на сервис", который представляет каждый микросервис с отдельной базой данных, — это паттерн, который позволяет избежать влияния на уровне базы данных на приложение, но может привести к увеличению количества экземпляров баз данных.

Другой паттерн — это API Gateway, который принимает входящий трафик кластера или всей микросервисной архитектуры через шлюз и распределяет трафик через API. Это один из наиболее используемых паттернов, и такие продукты, как Spring Cloud Gateway или Apache APISIX, могут быть применены.

Популярные архитектуры постепенно расширяются до Cloud Native архитектур. Может ли микросервисная архитектура в Cloud Native просто построить исходный микросервис как контейнерный образ и перенести его напрямую в Kubernetes?

Теоретически это кажется возможным, но на практике возникают некоторые сложности. В микросервисной архитектуре Cloud Native эти компоненты должны работать не только в контейнерах, но также включать другие аспекты, такие как регистрация сервисов, обнаружение и конфигурация.

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

В этом случае мы можем использовать модель Sidecar для абстрагирования и упрощения вышеуказанного сценария.

Обычно модель Sidecar представлена в виде Sidecar Proxy, который эволюционирует от левой части диаграммы ниже к правой, погружая некоторые общие возможности (такие как аутентификация, авторизация, безопасность и т.д.) в Sidecar. Как видно из диаграммы, эта модель адаптировалась от необходимости поддержки нескольких компонентов до необходимости поддержки только двух вещей (приложение + Sidecar). В то же время сама модель Sidecar содержит некоторые общие компоненты, поэтому ей не нужно поддерживаться бизнес-стороной, что легко решает проблему взаимодействия микросервисов.

Чтобы избежать сложных сценариев отдельной конфигурации и повторного создания колеса при внедрении Sidecar для каждого микросервиса, процесс может быть реализован путем внедрения плоскости управления или инъекции плоскости управления, что постепенно формирует текущий Service Mesh.

Service Mesh обычно требует двух компонентов, т.е. плоскость управления + плоскость данных. Плоскость управления завершает распределение конфигурации и выполнение связанной логики, например, Istio, который в настоящее время является самым популярным. На плоскости данных можно выбрать API-шлюз, такой как Apache APISIX, для пересылки трафика и взаимодействия сервисов. Благодаря высокой производительности и масштабируемости APISIX, также возможно выполнение некоторых пользовательских требований и логики. Ниже показана архитектура решения Service Mesh с Istio+APISIX.

Преимущество этого решения заключается в том, что при желании мигрировать с предыдущей микросервисной архитектуры на архитектуру Cloud Native можно избежать массовых изменений на стороне бизнеса, используя решение Service Mesh напрямую.

Технические вызовы Cloud Native

В предыдущей статье упоминались некоторые преимущества текущего тренда Cloud Native с технической точки зрения. Однако у каждой медали есть две стороны. Хотя некоторые новые элементы и возможности могут быть привнесены, вызовы возникают из-за участия определенных технологий.

Проблемы, вызванные контейнеризацией и K8s

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

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

Аналогично, внедрение K8s также привело к вызовам в области безопасности компонентов. Увеличение количества компонентов привело к увеличению поверхности атаки, а также к дополнительным уязвимостям, связанным с базовыми компонентами и уровнями зависимостей. На уровне инфраструктуры миграция с традиционных физических или виртуальных машин на K8s включает затраты на преобразование инфраструктуры и больше затрат на выполнение резервного копирования данных кластера, периодических обновлений и обновления сертификатов.

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

Безопасность

Использование новых технологий требует дополнительного внимания на уровне безопасности:

• На уровне сетевой безопасности можно реализовать детализированный контроль трафика с помощью Network Policy или других методов шифрования соединений, таких как mTLS, для формирования сети с нулевым доверием.

• На уровне безопасности данных K8s предоставляет ресурс secret для обработки конфиденциальных данных, но на самом деле он не безопасен. Содержимое ресурса secret кодируется в Base64, что означает, что вы можете получить доступ к содержимому через декодирование Base64, особенно если они размещены в etcd, который можно прочитать напрямую, если у вас есть доступ к etcd.

• На уровне безопасности разрешений также существует ситуация, когда настройки RBAC не являются разумными, что приводит к тому, что злоумышленник использует соответствующий Token для взаимодействия с apiserver для достижения цели атаки. Такой тип настройки разрешений чаще всего встречается в сценариях контроллеров и операторов.

Наблюдаемость

Большинство сценариев Cloud Native включают некоторые операции, связанные с наблюдаемостью, такие как логирование, мониторинг и т.д.

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

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

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

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

Кроме того, другая ситуация в кластере K8s, когда весь кластер или узел исчерпывает ресурсы, приведет к вытеснению ресурсов, что означает, что ресурсы, уже работающие на узле, вытесняются на другие узлы. Если ресурсы кластера ограничены, шторм узлов может легко привести к сбою всего кластера.

Эволюция приложений и мультикластерный паттерн

На уровне эволюции архитектуры приложений ключевым вопросом является обнаружение сервисов.

K8s предоставляет механизм обнаружения сервисов на основе DNS по умолчанию, но если бизнес включает сосуществование облачного бизнеса и локального бизнеса, использование механизма обнаружения сервисов на основе DNS для обработки ситуации будет более сложным.

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

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

Как APISIX способствует цифровой трансформации

Apache APISIX — это Cloud Native API-шлюз под эгидой Apache Software Foundation, который является динамичным, реального времени и высокопроизводительным, предоставляя богатые функции управления трафиком, такие как балансировка нагрузки, динамический апстрим, канареечные выпуски, разрыв цепи, аутентификация, наблюдаемость и т.д. Вы можете использовать Apache APISIX для обработки традиционного север-южного трафика, а также восточно-западного трафика между сервисами.

В настоящее время, основываясь на эволюции архитектуры и изменениях в приложениях, описанных выше, в Apache APISIX также были разработаны решения на основе Ingress controller и Service Mesh, чтобы помочь предприятиям лучше осуществлять цифровую трансформацию.

Решение APISIX Ingress

Apache APISIX Ingress Controller — это реализация Kubernetes Ingress Controller, которая в основном служит шлюзом для обработки север-южного трафика Kubernetes.

Архитектура APISIX Ingress Controller похожа на APISIX в том, что это отдельная архитектура для плоскости управления и плоскости данных. В этом случае APISIX используется как плоскость данных для фактической обработки трафика.

В настоящее время APISIX Ingress Controller поддерживает следующие три метода конфигурации и совместим со всеми плагинами APISIX из коробки:

• Поддержка ресурсов Ingress, родных для K8s. Этот подход позволяет APISIX Ingress Controller иметь более высокий уровень адаптируемости. На данный момент APISIX Ingress Controller является наиболее поддерживаемой версией среди всех открытых и влиятельных продуктов Ingress controller.

• Поддержка использования пользовательских ресурсов. Текущие пользовательские ресурсы APISIX Ingress Controller — это набор спецификаций CRD, разработанных в соответствии с семантикой APISIX. Использование пользовательских ресурсов упрощает интеграцию с APISIX и делает его более родным.

• Поддержка Gateway API. Как следующее поколение стандарта Ingress, APISIX Ingress Controller начал поддерживать Gateway API (на этапе Beta). По мере эволюции Gateway API он, вероятно, станет встроенным ресурсом для K8s напрямую.

APISIX Ingress Controller имеет следующие преимущества перед Ingress NGINX:

• Разделение архитектуры. В APISIX Ingress архитектура плоскости данных и плоскости управления разделены. Когда давление на обработку трафика высокое и вы хотите расширить емкость, вы можете просто расширить плоскость данных, что позволяет обслуживать больше плоскостей данных без необходимости вносить изменения в плоскость управления.

• Высокая масштабируемость и поддержка пользовательских плагинов.

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

В настоящее время APISIX Ingress Controller используется многими компаниями по всему миру, такими как China Mobile Cloud Open Platform (продукт открытых API и облачной IDE), Upyun и Copernicus (часть проекта Europe's Eyes on Earth).

APISIX Ingress Controller продолжает активно развиваться, и мы планируем улучшить больше функций следующими способами:

1. Полная поддержка Gateway API для включения большего количества сценариев конфигурации.
2. Поддержка внешнего прокси сервисов.
3. Нативная поддержка нескольких реестров, чтобы сделать APISIX Ingress Controller более универсальным.
4. Обновления архитектуры для создания новой архитектурной модели;
5. Интеграция с Argo CD/Flux и другими инструментами GitOps для создания богатой экосистемы.

Если вы заинтересованы в решении APISIX Ingress, пожалуйста, следите за обновлениями сообщества для итераций продукта и трендов сообщества.

Решение APISIX Service Mesh

В настоящее время, помимо API-шлюза и решения Ingress, решение Service Mesh на основе APISIX также активно развивается.

Решение Service Mesh на основе APISIX состоит из двух основных компонентов, а именно плоскости управления и плоскости данных. Istio был выбран для плоскости управления, так как он является лидером в отрасли с активным сообществом и поддерживается несколькими поставщиками. APISIX был выбран для замены Envoy на стороне данных, что позволяет использовать высокую производительность и масштабируемость APISIX.

Service Mesh на основе APISIX продолжает активно развиваться, с последующими итерациями, запланированными в следующих направлениях:

• Выполнение ускорения eBPF для повышения общей эффективности.

• Интеграция возможностей плагинов для лучшего использования возможностей APISIX Ingress в архитектуре Service Mesh.

• Создание инструмента для бесшовной миграции, чтобы предоставить пользователям более простые инструменты и упростить процесс.

В целом, эволюция архитектуры и технологий в эпоху Cloud Native приносит нам как возможности, так и вызовы. Apache APISIX как Cloud Native шлюз стремится к большей технической адаптации и интеграции для тренда Cloud Native. Различные решения на основе APISIX также начали помогать корпоративным пользователям осуществлять цифровую трансформацию и помогать предприятиям более плавно переходить на путь Cloud Native.