CaaS vs KaaS — где заканчивается управление контейнерами и начинается управление Kubernetes

Запустить контейнер — дело нескольких секунд. Но как только их количество начинает исчисляться сотнями и тысячами, начинаются сложности — их нужно размещать по узлам, распределять ресурсы, обновлять приложения, не нарушая их доступность, обеспечивать отказоустойчивость и следить, чтобы вся система работала стабильно. И очень быстро оказывается, что основная проблема уже не в самих контейнерах, а в инфраструктуре, на которой они работают.

В ответ на эти сложности появились сервисные модели, позволяющие снять с команд часть рутинных задач и операций. Одни из них полностью скрывают от пользователя серверы и механику оркестрации, оставляя только возможность передать образ и получить работающий сервис. Другие предоставляют готовый Kubernetes-кластер,  избавляя от необходимости разворачивать и обслуживать его control plane, но сохраняя привычную модель работы через API Kubernetes.

На первый взгляд различие между ними не то чтобы огромное — и там, и там в итоге запускаются контейнеры. Но по факту это два разных подхода с разным уровнем контроля, гибкости и разделением зон ответственности. В этой статье разберем, чем Container as a Service отличается от Kubernetes as a Service и как выбрать более подходящую под ваши задачи модель.

Что такое CaaS

CaaS (Container as a Service) — сервисная модель, в которой платформа предоставляет пользователю среду для развертывания и эксплуатации контейнеризированных приложений, беря на себя часть задач по управлению инфраструктурой.

Главная задача CaaS — скрыть часть инфраструктурной сложности и дать разработчикам или операционным командам удобный способ работать с контейнерами без необходимости самостоятельно управлять всем нижним уровнем.

В зависимости от реализации платформа может обеспечивать:

• запуск контейнеров;

• планирование их размещения;

• управление сетевым взаимодействием;

• автоматическое масштабирование;

• интеграцию с реестрами образов;

• средства наблюдаемости и мониторинга.

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

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

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

Что такое KaaS

KaaS (Kubernetes as a Service) — сервисная модель, в которой пользователю предоставляется управляемый Kubernetes-кластер.

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

В зависимости от реализации KaaS-платформа может отвечать за:

• создание Kubernetes-кластеров;

• развертывание и обслуживание control plane;

• управление версиями Kubernetes;

• обновление и совместимость компонентов кластера;

• настройку сетевых плагинов и сервисной сети;

• управление несколькими кластерами;

• разграничение доступа и применение политик безопасности.

При этом объем ответственности зависит от конкретного сервиса — провайдер может управлять только control plane или брать на себя также worker-ноды и связанные с ними инфраструктурные компоненты.

Пользователь при этом работает с декларативными объектами Kubernetes — namespace, deployment, service, ingress и другими ресурсами через Kubernetes API.

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

Главное отличие KaaS от самостоятельного развертывания Kubernetes в том, что значительная часть эксплуатационных задач переносится на платформу. Администраторам не нужно вручную поднимать каждый кластер, следить за совместимостью компонентов или выполнять типовые операции обслуживания. При этом конкретный объем автоматизации зависит от реализации KaaS и распределения ответственности между провайдером и пользователем.

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

Упрощенно границу между моделями можно провести так: в CaaS Kubernetes, если он используется, обычно остается частью реализации платформы, а пользователь взаимодействует с более высоким уровнем абстракции. В KaaS Kubernetes становится непосредственно предоставляемой пользователю платформой — он получает доступ к Kubernetes API и использует его объекты и механизмы для управления приложениями.

Подробнее о разнице между моделями

CaaS и KaaS решают похожую задачу — предоставляют удобный способ работы с контейнеризированными приложениями. Однако отличаются они тем, на каком уровне происходит управление.

В случае CaaS пользователь получает среду для запуска контейнеров. Платформа скрывает часть инфраструктурных деталей и позволяет сосредоточиться на приложениях. В KaaS он имеет дело с управляемым Kubernetes-кластером и работает с ним через стандартный Kubernetes API. Не с абстракцией для запуска контейнеров, а напрямую с объектами Kubernetes — Deployment, Service, Ingress, StatefulSet и другими ресурсами.

Предположим, нужно развернуть новый микросервис. Само приложение уже собрано в образ и готово к запуску.

Если используется CaaS, пользователь передает платформе образ контейнера, указывает необходимые параметры — например, объем памяти, CPU, переменные окружения и число экземпляров приложения. Дальше платформа берет на себя выполнение типовых операций — например, размещение приложения, запуск контейнеров, распределение нагрузки и, в зависимости от реализации, их масштабирование и контроль состояния. Пользователь взаимодействует с сервисом через интерфейс или API платформы, не занимаясь непосредственно механизмами оркестрации.

В случае использования KaaS механика будет несколько иная. В этом случае пользователь работает напрямую с Kubernetes — описывает приложение в виде Deployment, создает Service для доступа к нему, при необходимости настраивает Ingress, Horizontal Pod Autoscaler, ConfigMap, Secret и другие объекты Kubernetes. После применения манифестов Kubernetes планировщик выбирает узлы для подов, а контроллеры следят за соответствием фактического состояния кластера заданному. При этом пользователь определяет поведение приложения через предоставленные Kubernetes API и механизмы.

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

Что же выбрать?

Главный критерий при выборе между CaaS и KaaS — требуемый уровень контроля, потребность в Kubernetes API и готовность команды работать с Kubernetes. Если вам нужен полноценный доступ к Kubernetes API, стандартным объектам и инструментам экосистемы Kubernetes, но при этом хочется исключить этапы ручной подготовки виртуальных машин, настройки сети и прочую инфраструктурную рутину — у нас для вас отличные новости.

Прямо сейчас мы работаем над решением, которое берет эти задачи на себя, объединяя возможности нашей платформы виртуализации VMmanager и платформы контейнеризации.