Контейнеризация заметно упростила разработку и развертывание приложений. Но по мере роста инфраструктуры появляются новые задачи: как распределить ресурсы, что произойдет при отказе узла или как обновить сервис без простоя.
Часть из них можно передать специализированной платформе. При этом подходы к организации такой платформы могут быть разными. В одном случае пользователь получает максимально простой интерфейс для запуска контейнеров. В другом — готовый Kubernetes, с которым можно работать через стандартный API.
Обе модели позволяют запускать контейнеризированные приложения, но предлагают разные уровни контроля. Разберемся, в чем разница между CaaS и KaaS, какие задачи решает каждая модель и что учитывать при выборе.
CaaS: когда платформа берет контейнеры на себя
CaaS (Container as a Service) — это сервисная модель, дающая разработчикам готовую среду и инструменты оркестрации для создания, запуска и управления контейнерными приложениями.
Задача CaaS — дать разработчикам удобный способ работы с контейнерами, без необходимости самостоятельно управлять всем нижним уровнем.
Платформа может предоставлять:
- запуск и остановку контейнеров;
- управление сетевым взаимодействием;
- автоматическое масштабирование приложений;
- интеграцию с реестрами образов;
- мониторинг и другие инструменты наблюдаемости.
При этом CaaS не означает конкретную технологию. Под капотом такой платформы могут использоваться разные механизмы оркестрации контейнеров.
Однако Kubernetes сегодня широко применяется в подобных решениях. Он предоставляет готовые механизмы планирования, масштабирования, восстановления приложений, управления конфигурациями и сетевым взаимодействием.
Поэтому CaaS-платформа вполне может использовать Kubernetes внутри, но при этом не показывать пользователю весь его функционал напрямую.
KaaS: Kubernetes как готовая платформа
KaaS (Kubernetes as a Service) — модель предоставления услуг, при которой пользователю доступен управляемый Kubernetes-кластер.
В отличие от CaaS, KaaS предоставляет непосредственно Kubernetes в качестве готовой платформы. При этом пользователь работает с Kubernetes API и стандартными средствами оркестрации, а управление частью инфраструктуры и связанных с ней задач осуществляется провайдером.
Платформа отвечает за:
- создание кластеров;
- развертывание и обслуживание control plane;
- обновление Kubernetes;
- управление совместимостью компонентов;
- настройку сетевых плагинов и сервисной сети;
- управление несколькими кластерами;
- настройку доступа и политик безопасности.
Главное отличие KaaS от самостоятельного развертывания Kubernetes — многие эксплуатационные задачи переносятся на платформу. Администраторам не требуется вручную создавать и настраивать каждый кластер. Отметим, что степень автоматизации зависит от конкретной реализации KaaS и распределения зон ответственности между пользователем и провайдером.
При этом для Kubernetes по-прежнему требуется инфраструктура: вычислительные узлы, сеть и хранилища. В публичном облаке ее может предоставлять провайдер, а в частной или корпоративной инфраструктуре ее обычно нужно обеспечивать самостоятельно.
Кому подходит CaaS
CaaS хорошо подходит для сценариев, в которых команде важнее простота работы с приложениями, чем полный контроль над механизмами оркестрации.
Такой подход может быть удобен, если:
- нужно быстро запускать контейнеризированные приложения;
- команда не хочет самостоятельно управлять оркестратором;
- важна высокая степень автоматизации;
- нет необходимости использовать весь набор возможностей Kubernetes;
- инфраструктурные детали желательно скрыть за единым интерфейсом.
Пользователь при этом сосредотачивается на приложении и его параметрах, а не на том, каким образом контейнеры распределяются внутри инфраструктуры.
Кому подходит KaaS
KaaS, в свою очередь, подойдет командам, которым нужен именно Kubernetes и его экосистема.
Например, это актуально, если необходимо:
- использовать стандартный Kubernetes API;
- работать с Kubernetes-манифестами;
- применять Deployment, Service, Ingress, StatefulSet и другие объекты;
- использовать инструменты и решения экосистемы Kubernetes;
- самостоятельно определять поведение приложений на уровне Kubernetes;
- при этом не заниматься развертыванием и базовым обслуживанием самого кластера.
В таком случае управляемый Kubernetes позволяет сохранить необходимый уровень контроля, одновременно сократив объем инфраструктурной работы.
Что выбрать для своей инфраструктуры
Универсального ответа здесь нет. Выбор зависит от того, насколько глубоко команда должна контролировать среду исполнения приложений.
Если главная цель — максимально упростить запуск контейнеров и передать платформе большую часть рутинных операций, логичным выбором будет CaaS.
Если же нужен полноценный Kubernetes с его API, объектами и экосистемой, но при этом хочется отказаться от самостоятельного развертывания и обслуживания кластеров, стоит рассматривать KaaS.
