Введение
Говоря о бессерверных вычислениях, невозможно обойти тему Kubernetes.
В сегодняшнем уроке мы продолжим изучать, как настроить частную бессерверную среду. В частности, мы построим бессерверную инфраструктуру на основе локального развертывания K8s из предыдущего урока. Затем мы установим дополнительные компоненты для расширения возможностей кластера K8s, чтобы в итоге локальный кластер K8s мог поддерживать бессерверные вычисления.
Предварительные требования для построения бессерверной среды
Прежде чем начать, давайте проясним один вопрос, который возник во время вводного курса по бессерверным вычислениям, особенно FaaS. Некоторые студенты спросили: «Как связаны между собой микросервисы, Service Mesh и бессерверные вычисления?»
Эти понятия часто встречаются в обсуждениях, но не стоит волноваться. Я тоже путался в этих концепциях, когда впервые начал изучать бессерверные вычисления. Давайте сначала вернемся к микросервисам. При создании BaaS с помощью микросервисов вы, возможно, заметили, что многие концепции в микросервисах очень похожи на те, что используются в бессерверных вычислениях.
Проще говоря, Service Mesh — это решение для сетевого взаимодействия микросервисов, которое работает без ведома самих микросервисов. Мы также можем делегировать сетевое взаимодействие в бессерверной архитектуре Service Mesh. С помощью Service Mesh компоненты бессерверной архитектуры могут тесно взаимодействовать с кластером K8s, в конечном итоге поддерживая наши развернутые приложения в бессерверном режиме. Давайте посмотрим на следующую диаграмму архитектуры:
Из диаграммы хорошо видно, что базовая инфраструктура бессерверных вычислений может быть построена на Service Mesh. Однако Service Mesh — это лишь одно из решений для реализации сетевого взаимодействия в бессерверных вычислениях. Существуют и другие варианты, такие как RSocket, gRPC и Dubbo. Я выбрал Service Mesh, потому что это решение может быть основано на компонентах K8s и предоставляет инструменты визуализации, которые помогают понять механизм работы бессерверных вычислений, например, как достичь нулевого времени запуска и управлять трафиком для постепенных релизов. Если вы хотите попрактиковаться, Service Mesh, несомненно, является лучшим выбором.
Инфраструктура бессерверных вычислений: Service Mesh
Некоторые называют Kubernetes, Service Mesh и технологии бессерверных вычислений «тремя столпами» разработки облачных нативных приложений. К этому моменту, я полагаю, вы понимаете причину этого. Однако я должен уточнить, что в следующих уроках мы познакомимся со многими новыми терминами. Я дал вам общее представление об этих терминах, чтобы вы имели широкое понимание. Если у вас есть время, стоит углубиться в их изучение.
А теперь вернемся к основной теме и подробнее рассмотрим принципы Service Mesh.
Когда мы обсуждали микросервисы, мы касались только теоретических рекомендаций по декомпозиции и интеграции, не затрагивая конкретную реализацию. Если перейти к реализации, в отрасли существует множество фреймворков микросервисов, но большинство из них ограничены SDK для конкретных языков, особенно Java.
Микросервисный фреймворк в форме SDK обычно имеет сильную направленность на реализацию сетевого взаимодействия между микросервисами, такую как повторные попытки при сбоях запросов к сервисам, балансировка нагрузки между несколькими экземплярами сервиса и ограничение трафика при высоком объеме запросов. Эта логика часто требует внимания разработчиков микросервисов и должна быть повторно реализована на каждом языке SDK. Возможно ли извлечь логику сетевого взаимодействия микросервисов из SDK, сделав наши микросервисы более легкими и даже избавив от необходимости беспокоиться о сетевом взаимодействии?
Ответ — Service Mesh.
Если мы развернем декомпозированные приложения в подах кластера K8s, процесс будет выглядеть так, как показано на диаграмме ниже, где приложение MyApp будет напрямую вызывать микросервис пользователя и микросервис задач в кластере через HTTP.
Но как насчет проблем безопасности, возникающих при прямом HTTP-доступе? Если кто-то запустит контейнер BusyBox в нашем кластере, не сможет ли он напрямую атаковать наш микросервис пользователя и микросервис задач? Кроме того, когда у нас есть несколько экземпляров микросервиса пользователя, как распределять трафик?
Традиционно мы использовали бы SDK микросервисной архитектуры, который содержит много такой логики и множество стратегий, которые нужно решать, когда активировать при вызове SDK. Наш код также стал бы сильно связанным с SDK микросервисной архитектуры.
Service Mesh, однако, предлагает другой подход, извлекая логику сетевого взаимодействия из микросервиса и управляя сетевым трафиком неинвазивным способом, что позволяет нам больше не беспокоиться о тяжеловесном SDK микросервисов. Давайте посмотрим, как Service Mesh решает эту проблему.
Service Mesh можно разделить на плоскость данных и плоскость управления. Плоскость данных отвечает за управление сетевым взаимодействием, в то время как плоскость управления контролирует и отслеживает состояние сетевого взаимодействия. Service Mesh перехватывает весь сетевой трафик путем внедрения Sidecar.
В плоскости данных наши приложения и микросервисы, по-видимому, общаются напрямую с Sidecar, но на самом деле Sidecar может достичь этого через перехват трафика. Поэтому наши приложения и микросервисы, как правило, не знают об этом и не требуют изменений, просто используя HTTP-запросы для передачи данных.
Плоскость управления более сложна и является ядром работы Service Mesh. Pilot — это драйвер всей плоскости управления, отвечающий за обнаружение сервисов, управление трафиком и масштабирование. Citadel — это крепость-хранитель плоскости управления, отвечающая за сертификаты безопасности и аутентификацию. Mixer — это офицер связи, распространяющий политики плоскости управления и собирающий статус работы каждого сервиса.
Теперь вы должны четко понимать, что такое Service Mesh, как он извлекает логику сетевого взаимодействия микросервисов из SDK и почему мы говорим, что Service Mesh — это основа сетевого взаимодействия для бессерверных вычислений.
Связь между бессерверными вычислениями и контейнерными движками
Основная ценность бессерверных вычислений заключается в отсутствии необходимости управлять серверами, что позволяет сосредоточиться на бизнес-логике. Контейнерные технологии предоставляют мощную инфраструктуру и гибкие возможности планирования, необходимые для бессерверных вычислений, особенно в сочетании с инструментами оркестрации, такими как Kubernetes.
Контейнеры предлагают такие преимущества, как легковесная упаковка, изоляция ресурсов и быстрый запуск. Контейнеры упаковывают приложения и их зависимости, обеспечивая согласованность среды выполнения, что облегчает быстрое развертывание и запуск экземпляров приложений на бессерверной платформе. Кроме того, контейнеры предоставляют изолированные среды выполнения, гарантируя, что разные приложения не мешают друг другу, повышая общую стабильность платформы. Более того, запуск контейнеров быстрее, чем запуск виртуальных машин, что соответствует высоким требованиям бессерверных приложений к эластичному масштабированию.
Как ядро планирования бессерверных вычислений, Kubernetes обладает функциями автоматического развертывания, эластичного масштабирования и обнаружения сервисов. Он может автоматически развертывать контейнеризированные приложения на основе предустановленных правил без вмешательства человека, регулировать количество экземпляров приложений в зависимости от реальной нагрузки, обеспечивая производительность и оптимизируя использование ресурсов, а также предоставляет механизмы обнаружения сервисов для облегчения взаимодействия между компонентами внутри бессерверной платформы.
Чтобы построить бессерверную платформу на основе контейнеров, сначала необходимо упаковать приложения и их зависимости в образы контейнеров, обеспечив возможность быстрого развертывания и запуска приложений на платформе. Затем выберите подходящую облачную платформу или настройте собственный кластер Kubernetes в качестве инфраструктуры для бессерверной платформы. Далее разработайте компоненты бессерверной платформы, включая API-шлюз для приема и маршрутизации внешних запросов, среду выполнения функций для загрузки и выполнения кода функций и управления жизненным циклом функций, а также триггеры событий, которые прослушивают различные источники событий и преобразуют события в вызовы функций. Наконец, используйте Deployment в Kubernetes для управления развертыванием и обновлением экземпляров приложений, Service для обнаружения сервисов и балансировки нагрузки, а HPA для автоматического эластичного масштабирования.
Бессерверная платформа на основе контейнеров предлагает высокую гибкость, сильную настраиваемость и экономическую эффективность. Разработчики могут свободно выбирать базовую контейнерную технологию и платформу Kubernetes, настраивать функции и возможности бессерверной платформы в соответствии со своими потребностями, а также использовать возможности планирования ресурсов Kubernetes для оптимизации использования ресурсов и снижения затрат.
Сочетание контейнерных технологий и Kubernetes предоставляет мощные инструменты и методы для создания эффективных, гибких и масштабируемых бессерверных платформ, позволяя разработчикам легко создавать свои собственные бессерверные платформы, сосредоточиться на разработке бизнес-логики и повысить эффективность разработки.
Novita AI Serverless
В Novita AI мы разработали собственный контейнерный движок Nexus. Используя мощные возможности распределенных вычислений и планирования ресурсов Nexus, Novita AI построила бессерверный сервис, ориентированный на следующее поколение генеративного ИИ. Пользователям нужно только сосредоточиться на бизнес-инновациях, не беспокоясь о базовых вычислительных ресурсах. Сейчас открыта предварительная запись; присоединяйтесь к списку ожидания, чтобы первыми опробовать Novita AI Serverless.
Novita AI — это универсальная облачная платформа, которая расширяет ваши ИИ-амбиции. Интегрированные API, бессерверные вычисления, GPU-инстансы — экономически эффективные инструменты, которые вам нужны. Устраните инфраструктуру, начните бесплатно и воплотите свое ИИ-видение в реальность.
Рекомендуемые статьи
Масштабирование по требованию: как бессерверные вычисления легко справляются с пиками трафика
