Открыть сервис

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-вызовы.

Сравнение с альтернативами

ПлатформаТипЗависимостьМасштабирование до нуляУправление событиями
KnativeOpen sourceТребует KubernetesДаВстроенное (Eventing)
AWS LambdaПроприетарнаяОблачный провайдерДаЧерез AWS EventBridge
Azure FunctionsПроприетарнаяОблачный провайдерДаЧерез Azure Event Grid
Google Cloud FunctionsПроприетарнаяОблачный провайдерДаЧерез Google Cloud Pub/Sub
OpenFaaSOpen 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 →