Knative
Knative — это открытая платформа на основе Kubernetes, предназначенная для развёртывания, запуска и управления бессерверными (serverless) приложениями и контейнерными рабочими нагрузками. Разработанная совместно компаниями Google, Pivotal, IBM и Red Hat, платформа предоставляет набор компонентов, автоматизирующих такие задачи, как автоматическое масштабирование, управление версиями, трафиком и событиями, что позволяет разработчикам сосредоточиться на логике приложения, а не на инфраструктурных деталях.
История
Проект Knative был анонсирован в июле 2018 года на конференции Google Cloud Next. Основной целью было создание стандартизированной платформы для бессерверных вычислений поверх Kubernetes, которая бы абстрагировала сложность оркестрации контейнеров. В 2019 году проект был передан в управление фонду CNCF (Cloud Native Computing Foundation), а в марте 2022 года достиг статуса инкубационного проекта. Ключевые версии: v0.1 (2018), v1.0 (2021), v1.14 (2024). На момент 2024 года Knative используется в таких продуктах, как Google Cloud Run, IBM Code Engine, Red Hat OpenShift Serverless и VMware Tanzu.
Архитектура
Knative состоит из двух основных компонентов: Serving (обслуживание) и Eventing (события). Они работают как расширения Kubernetes, добавляя собственные Custom Resource Definitions (CRD).
Knative Serving
Компонент Serving отвечает за развёртывание и эксплуатацию контейнерных приложений. Он предоставляет следующие абстракции:
- Service — высокоуровневый ресурс, управляющий всем жизненным циклом приложения. Автоматически создаёт Configuration, Revision и Route.
- Configuration — определяет желаемое состояние приложения (образ, переменные окружения, команды). При каждом изменении создаёт новую Revision.
- Revision — неизменяемый снимок состояния приложения, соответствующий конкретной версии кода и конфигурации. Каждая Revision имеет уникальный идентификатор.
- Route — управляет распределением трафика между различными Revision. Позволяет настраивать канареечное развёртывание, A/B-тестирование и откаты.
Ключевая особенность Serving — автоматическое масштабирование до нуля. Когда приложение не получает запросов, количество реплик может быть сокращено до нуля, что снижает затраты на ресурсы. При поступлении нового запроса активируется «холодный старт» — создание новой реплики, что может вызывать задержки. Для управления масштабированием используется компонент Activator (активатор), который перехватывает запросы к неактивным репликам и запускает их, а также Autoscaler (автомасштабировщик), который на основе метрик (например, количество одновременных запросов) принимает решения о масштабировании.
Knative Eventing
Компонент Eventing обеспечивает связь между приложениями через события. Он реализует модель публикация-подписка (pub/sub) и поддерживает стандарт CloudEvents. Основные абстракции:
- Source (источник) — генерирует события. Встроенные источники включают: ApiServerSource (события Kubernetes API), PingSource (периодические события по расписанию), KafkaSource (события из Apache Kafka), SinkBinding (связывает любое приложение с получателем).
- Broker (брокер) — центральный узел, принимающий события от источников и доставляющий их подписчикам. Поддерживает фильтрацию по атрибутам события (например, по типу или источнику).
- Trigger (триггер) — связывает брокер с конкретным получателем, определяя фильтр событий.
- Channel (канал) — более низкоуровневая абстракция, обеспечивающая буферизацию и маршрутизацию событий. Поддерживает различные реализации (InMemoryChannel, KafkaChannel, NatssChannel).
Eventing позволяет строить сложные асинхронные архитектуры, такие как event-driven микросервисы, ETL-пайплайны и интеграционные шины.
Применение
Knative используется в сценариях, где требуется высокая эластичность, асинхронная обработка и автоматическое управление инфраструктурой:
- Бессерверные веб-приложения — сайты, API, бэкенды для мобильных приложений, которые могут масштабироваться до нуля в периоды бездействия.
- Обработка событий — приёмы и обработка вебхуков, сообщений из очередей (Kafka, RabbitMQ), потоков данных.
- CI/CD пайплайны — автоматизация сборки, тестирования и развёртывания приложений на основе событий (например, push в Git-репозиторий).
- Пакетная обработка — выполнение задач по расписанию или при наступлении определённых условий (например, генерация отчётов, обработка изображений).
- Асинхронные микросервисы — реализация архитектуры, где сервисы общаются через события, а не через прямые HTTP-вызовы.
Сравнение с альтернативами
| Платформа | Тип | Зависимость | Масштабирование до нуля | Управление событиями |
|---|---|---|---|---|
| Knative | Open source | Требует Kubernetes | Да | Встроенное (Eventing) |
| AWS Lambda | Проприетарная | Облачный провайдер | Да | Через AWS EventBridge |
| Azure Functions | Проприетарная | Облачный провайдер | Да | Через Azure Event Grid |
| Google Cloud Functions | Проприетарная | Облачный провайдер | Да | Через Google Cloud Pub/Sub |
| OpenFaaS | Open source | Требует Kubernetes | Опционально | Через внешние брокеры |
Knative отличается от облачных решений тем, что работает на любом Kubernetes-кластере, включая локальные, гибридные и мультиоблачные среды. Однако он требует более глубокого понимания Kubernetes и дополнительных компонентов (например, Istio или Kourier для управления трафиком).
Критика и ограничения
- Сложность настройки — для полноценной работы Knative требуется предварительная установка и настройка нескольких компонентов (метрики, логи, сетевой прокси).
- Холодный старт — при масштабировании до нуля первый запрос к неактивному приложению может занимать от нескольких сотен миллисекунд до нескольких секунд, что критично для низколатентных систем.
- Ограниченная поддержка языков — хотя Knative работает с любыми контейнерами, для некоторых языков (например, Go, Node.js) существуют готовые шаблоны, а для других (например, C++, Rust) требуется ручная настройка.
- Зависимость от Kubernetes — не подходит для команд, не имеющих опыта работы с Kubernetes или не желающих администрировать кластер.
- Отсутствие встроенных инструментов мониторинга — для отслеживания производительности и ошибок необходимо интегрировать внешние решения (Prometheus, Grafana, Jaeger).
Интересные факты
- Название «Knative» происходит от слов «Kubernetes» и «native» (родной), подчёркивая тесную интеграцию с Kubernetes.
- Проект поддерживает стандарт CloudEvents (спецификация CNCF), что позволяет использовать Knative с любыми совместимыми источниками и получателями событий.
- В 2023 году Google объявил, что Google Cloud Run (управляемый сервис бессерверных вычислений) использует Knative в качестве основы, что подтверждает зрелость и надёжность платформы.
- Knative может работать с различными сетевыми прокси: Istio, Kourier, Contour, Gloo.
Источники
- Официальная документация Knative (knative.dev/docs)
- Репозиторий проекта на GitHub (github.com/knative)
- Статья «Knative: A Deep Dive» на сайте CNCF (cncf.io)
- Документация Google Cloud Run (cloud.google.com/run/docs)
- Книга «Knative in Action» автора Jacques Chester (Manning Publications, 2021)
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →