Faas что это такое
Как работают и где применяются бессерверные вычисления (Function-as-a-Service)
Serverless-вычисления и работающие на их основе решения Function-as-a-Service помогают разработчикам развивать продукты, ориентируясь на бизнес-фичи. Мы поэкспериментировали с этими технологиями и пришли к выводу, что для боевого применения существующие решения сыроваты. Пойдём по порядку.
Термин «бессерверные вычисления» отчасти вводит в заблуждение – конечно, в основе продукта сервера остаются, но разработчикам не приходится о них заботиться. По сути своей Serverless продолжает те же идеи виртуализации, что и более ранние aaS-технологии: позволить команде сосредоточиться на коде и развитии функций. Если IaaS – это абстракция оборудования, контейнеры – абстракция приложений, то FaaS – это абстракция бизнес-логики сервиса.
Идея в том, чтобы не паковать в контейнер сервер приложения, базу данных, средства балансировки нагрузки. Разработчики могут изолировать функцию в коде, загрузить её на облачной платформе и запускать её в тот момент, когда она нужна. Выделение инстансов, развёртывание кода и распределение ресурсов, запуск веб-интерфейсов, мониторинг работоспособности, обеспечение безопасности – всё это происходит автоматически.
FaaS обеспечивает максимальную гибкость в управлении производительностью – во время простоя функция вообще не потребляет ресурсы, а если потребуется, платформа быстро выделяет мощности, которых будет достаточно практически с любой нагрузкой. Обслуживает приложение одного пользователя или сразу сто тысяч – производительность системы с FaaS-архитектурой фактически не страдает, а у продукта с традиционной архитектурой обязательно начались бы проблемы.
Команда не беспокоится о бэкенде и процессах деплоя, В идеальных условиях реализация новой фичи сводится к загрузке одной функции на сервер. В результате разработка двигается быстрее, Time-to-Market ползёт вниз. А в компании в целом внедрение FaaS помогает развить платформенный подход – для Serverless-вычислений нужен либо пул облачных ресурсов от провайдера, либо Kubernetes-кластер.
Как это работает на практике
На рынке есть уже целый набор Serverless-платформ. Мы внимательно изучили два решения: Lambda от Amazon и KNative. Первое представляет собой проприетарный сервис для работы с облаком Amazon, второе работает поверх Kubernetes.
Amazon Lambda – вполне рабочий вариант со всеми возможностями, о которых мы говорили выше. Платформа выполняет все рутинные операции с продуктом, разворачивает приложения, мониторит работоспособность и производительность групп инстансов, обеспечивает отказоустойчивость и масштабирование.
Главное «но» – это проприетарный продукт, а значит вы ограничены амазоновским облаком и вынуждены использовать другие продукты их экосистемы. Если захотите сменить платформу, скорее всего, вам придётся сильно перестраивать продукт, поскольку в новой инфраструктуре правила могут сильно отличаться.
KNative – для нас решение более интересное, поскольку оно работает поверх Kubernetes.
В отличие от Lambda, в этом случае используется собственная платформа, приходится глубже погрузиться в архитектуру процесса. Выглядит она так:
Event source – сущность FaaS-платформы, которая взаимодействует с внешними источниками событий. Триггером может быть HTTP-запрос, сообщение от брокера сообщений, событие самой платформы
Broker – «корзина», которая принимает и хранит информацию о событиях от Event Source. Брокер может представлять собой модуль Kafka, работать в оперативной памяти и т.п.
Trigger – подписанный на Broker компонент, который достаёт сообщения из «корзины» и передаёт их на исполнение в Service.
Service – рабочая функция, изолированная бизнес-логика.
С точки зрения разработчика процесс выглядит практически так же, как с уже привычными контейнеризированными приложениями, меняется только объект: (1) написать функцию, (2) упаковать её в Docker-образ, (3) загрузить.
Главный недостаток KNative – нет средств логирования и мониторинга, а для FaaS-решений это критически важно. Если ваш продукт разбит на функции, без эффективного мониторинга и логирования быстро установить источник сбоя невозможно, поскольку придётся смотреть на каждую функцию отдельно.
Преимущества FaaS
Лучше всего подход показывает себя, когда не требуется мгновенный ответ пользователю и когда нагрузка может колебаться от 0 до 100%:
Задачи, которые выполняются по расписанию. Операции экспорта/импорта в системах финансовой отчётности, учётных системах, решениях для создания резервных копий.
Асинхронная отправка уведомлений пользователю (push, email, СМС).
Машинное обучение, Интернет вещей, системы ИИ – все эти отрасли точно оценят такие возможности. Serverless позволяет выполнять вычисления ближе к эндпойнту, т.е. к пользователю. А значит, у продукта уменьшается задержка, сокращается нагрузка на передачу данных.
Какие можно выделить недостатки Serverless:
Такая архитектура плохо подходит для долгосрочных процессов. Если функция используется в приложении практически постоянно, то и потребление ресурсов будет таким же, как у традиционных продуктов.
Лучшие платформы на данный момент привязывают компанию к тому или иному облачному провайдеру – будь то AWS, Microsoft Azure или Google Cloud. Решениям для Kubernetes ещё предстоит подрасти до этого уровня.
FaaS – это не «волшебная таблетка», с которой разработчики могут забыть об инфраструктуре и просто отправлять на прод фичи. Всё равно нужно продумывать архитектуру, проектировать функции и их взаимодействие с помощью DDD. Иначе продукт превращается в массу сильно связанных между собой функций, в которых будет сложно разобраться. Разработчики не смогут деплоить такие функции и менять по отдельности. В худшем случае при обработке пользовательских запросов пользователя придётся поднимать все функции.
Наш вывод – до эпохи Serverless ещё несколько лет
…При условии, что разработчики будут развивать это направление, в частности – развивать open source платформы до уровня того же Amazon Lambda.
Мотивацией таких проектов может быть сокращение затрат на ресурсы, улучшение управления большими энергозатратными продуктами. Но на данный момент разработчикам может быть проще работать «по старинке». Владение Serverless и умение использовать эти инструменты – это хороший багаж, до боевого применения компаниям стоит подождать пару лет.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Что такое функция как сервис (FaaS)?
Еще один модный термин
Функция как сервис или FaaS (Function as a service) это относительно новомодный термин, которым определяется возможность бессерверного запуска кусков кода, что дает возможность разработчикам писать и обновлять эти куски кода на лету, которые будут запускаться в результате отклика на какое-нибудь событие, к примеру, когда пользователь нажмет на элемент в веб-приложении. Благодаря этому масштабировать код и внедрять микросервисы становится на порядок проще.
Что такое микросервисы?
Такой подход к написанию приложения из набора модульных компонентов известен как микросервисная архитектура. Причем подобный подход довольно тепло воспринимается разработчиками, так как они могут создавать и модифицировать маленькие куски кода, которые относительно легко имплементировать в структуру приложения. Причем в монолитном приложении совершенно обратная ситуация, когда это приложение является огромной и экстремально сложной системой, где изменение одного из элементов может порушить его работу и процесс внесения изменения приближается по сложности к запуску шаттла. Таким образом, использование FaaS многократно снижает сложность внесения изменений и запуска нового кода, что дает возможность разработчикам сосредоточиться на самом коде, в то время как FaaS провайдер будет следить за нужным количеством вычислительных ресурсов и различных бэкэнд сервисов.
Какие плюсы такой технологии?
Увеличенная скорость разработки
С FaaS разработчики могут тратить больше времени на логику приложения и не думать о том, куда и как это приложение воткнуть, что как правило ведет к более высокой скорости написания и имплементации кода.
Bстроенная масштабируемость
Оптимизация затрат
Знаете, какой самый большой страх пользователя облачных серверов? Что вы наберете кучу серверов, а необходимой нагрузки не будет, что повлечет за собой в пустую простаивающие мощности. Логично, что появилась такая модель как FaaS, которая позволяет заказчикам платить только за то время, когда вычислительные мощности действительно работают.
Какие минусы технологии FaaS?
Снижение степени контроля системы в общем
Процесс тестирования становится гораздо сложнее
Впихнуть невпихуемое, а именно микросервисное приложение (или целый комплект таких приложений) в локальное окружение для тестирование становится нетривиальной задачей, и часто начинают требоваться люди с нетривиальным опытом и экспертизой.
Как начать использовать FaaS?
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
FaaS и serverless-решения на примере PoC kubeless-функции
Первая ассоциация, которая приходит на ум при упоминании serverless-решений, — это облачные сервисы вроде AWS Lambda, Azure Functions или Google Functions, а на российском рынке — Yandex Cloud Functions. У них имеются определённые бесплатные лимиты, и это подкупает. В случаях когда вы уже используете в работе K8s, смысла выносить отдельные части вашего приложения за кластер нет. Если вам интересно познакомиться с возможностями использования функций и с вариантами serverless-решений на bare-metal Kubernetes, а также узнать, как и где можно бесплатно развернуть своё PoC-решение на облачной виртуальной машине, то приглашаю под кат.
Зачем вам FaaS, если у вас K8s
Ссылки на авторитетные источники принято оставлять по поводу и без, поэтому в качестве примера возможной микросервисной архитектуры я приведу иллюстрацию, взятую со странички Serverless Architectures Мартина Фаулера:
Вместо монолитного API у нас две функции.
Монолиты определенно не в тренде, но сложно категорично сказать, что они уже отжили свой век; зато очевидно, что FaaS-решения (function-as-a-service) обладают определёнными плюсами:
Более низкая стоимость.
Более высокая скорость разработки. Возможность разрабатывать сервисы различными командами одновременно.
Повышенная отказоустойчивость и, как правило, лучшая масштабируемость.
Меньший и, следовательно, более понятный объём кода. Вы не привязаны к одному языку программирования: каждую функцию можно писать на своём языке. Если захотите, то сможете переписать любую функцию в относительно короткие сроки.
Основным минусом я бы назвал то, что функции гораздо сложнее тестировать. С монолитными приложениями таких трудностей не возникает. Кроме того, взаимосвязи между функциями (если они есть) в FaaS-решениях не всегда очевидны. Этого недостатка монолиты также лишены.
Облачные функции обладают «болячкой» в виде лимитов на использование памяти, времени выполнения, размера payload. Ну и, конечно же, у них имеется ограничение на количество бесплатных запусков. За деньги все ограничения снимаются и даже появляются возможности масштабирования облачных решений в соответствии с планируемой загрузкой.
Serverless-решения довольно хорошо вписываются в микросервисную архитектуру. Есть определённые кейсы, когда они лучше подходят под планируемое решение, чем Docker-контейнеры, содержащие в себе ОС и приложение. Например, если кодовая база довольно невелика, то смысла разворачивать отдельный контейнер с операционной системой нет. Это расточительно с точки зрения использования ресурсов Kubernetes. Разумеется, в таком случае проще использовать определённую функцию — особенно если какая-то операция выполняется раз в сутки или реже. Иногда функции используются как временные вспомогательные службы, либо как сервисы, применяемые для тестовой среды.
Два самых популярных способа запустить функцию — это HTTP- и CronJob-триггеры. Первые требуют конфигурации ingress и выполняют функцию после запроса, отправленного на определённый URL. Вторые же, как следует из названия, будут запускать функцию по расписанию. Кроме них есть и другие виды триггеров: различные webhooks; триггеры очереди; какие-либо триггеры, срабатывающие при загрузке файла. Иногда функции объединяют в цепочку. В таком случае одна функция по завершении своей работы вызывает другую.
Как выбрать serverless-фреймворк под себя
Если у вас уже имеется свой созданный кластер Kubernetes, то вы можете развернуть среду для написания безлимитных и бессерверных функций — Kubernetes-based installable serverless platform. Таких платформ-фреймворков несколько, и вы можете выбрать подходящую под свои нужды.
На что следует обратить внимание при выборе serverless-фреймворка, так это на поддержку языков программирования. Не всё и не везде поддерживается. JS доступен практически везде. Python и Go также пользуются довольно широкой поддержкой. Очень часто имеется возможность использовать Ruby, Java или C#.
Отличное сравнение самостоятельно устанавливаемых serverless-платформ, основанных на Kubernetes, содержится в следующем артикуле на сайте Cisco: Examining the FaaS on K8S Market. Я даже приведу изображение из этого артикула для большей наглядности (по скриншоту сразу становится понятно, что оно взято «с блога Сisco» :), но первоначального источника я не нашёл):
От себя добавлю, что Knative — это уже скорее CaaS (container-as-a-service), а не FaaS.
Чем интересен Kubeless
Kubeless большей частью написан на Go. Хочется верить, что проект, рождённый в стенах Google Go, будет ближе других к изначально их же Kubernetes.
К минусам Kubeless относят отсутствие поддержки scale-to-zero. Данный функционал удаляет все реплики, если в них нет необходимости. Эти возможности есть, например, у OpenFaaS. Зато у Kubeless имеется функция автоматического масштабирования с помощью кубернетовского Horizontal Pod Autoscaler.
Начиная с версии Kubernetes 1.16, доступна возможность использовать фичу под названием HPAScaleToZero. На момент написания статьи она находится в стадии Alpha.
Как потрогать Kubernetes своими руками
Для этого хорошо бы обзавестись собственной нодой Kubernetes. Если вы под Linux, то это для вас совсем не проблема. Если же вы под Windows, то можете не выходя из системы установить Docker с WSL и добавить интеграцию Kubernetes. Docker on Mac, кстати, тоже содержит в настройках возможность включить single-node кластер Kubernetes.
В Сети есть несколько сервисов, предоставляющих Kubernetes на бесплатной основе для создания PoC. Для меня открытием оказался Kubernautic. Он предоставляет Alpine Linux с уже установленным Kubernetes, но, как оказалось, с определёнными ограничениями, и у меня банально не хватило прав для того, чтобы установить на нём Kubeless. Примерно такие же впечатления остались от сервиса под названием Krucible.
Помимо Kubernautic, есть чуть более известный сервис Okteto. Его бесплатный тариф позволяет пользоваться сервисом через день. Это, конечно, не очень удобно с точки зрения разработки проектов, но для PoC иногда годится.
Мой тест в облаке
Так как FaaS всё-таки относится больше к облакам, я предпочитаю работать в них. Поэтому для демо решено было завести виртуальную машину у одного из крупных провайдеров. И где бы вы думали я её завел? В Oracle Cloud. Дело в том, что AWS и Azure предлагают виртуалки бесплатно только в первый год пользования аккаунтом, а Oracle — на постоянной основе. Справедливости ради упомяну, что и в Google Cloud также можно «взять погонять» виртуалку бесплатно на постоянной основе, но с 2016 года в России регистрация доступна только для юридических лиц.
Характеристики оракловской виртуалочки следующие:
1 core OCPU, 1 GB memory, 0.48 Gbps network bandwidth.
Существует несколько способов установить Kubernetes локально на одну машину и устроить себе learning environment для тестов и разработки. Один из самых популярных — это, пожалуй, Minikube. Он разворачивает кластер внутри виртуальной машины. Его основным плюсом, помимо популярности, является универсальность: развернуть его можно практически на любой ОС. Но Minikube первой же проверкой сузил мне круг выбора. Команда:
не возвратила ничего. Виртуализация не поддерживается моей виртуальной машиной.
У Minikube есть масса конкурентов:
Microk8s от разработчиков Ubuntu. Он работает без VM и устанавливается с помощью Snap.
Заманчивый и очень лёгкий (менее 100 МБ) K3s. Хорошо подходит для IoT.
Милый kind (Kubernetes IN Docker) — self-contained Linux-приложение, которое скачивается и записывается в PATH.
В результате я остановился на K3s. Кластер «завёлся» с одной команды, ну или точнее, с одного скрипта:
Для того чтобы всё заработало на Oracle Linux, мне пришлось отключить файрвол командой:
Добавить права на файл конфигурации:
И установить значение переменной среды KUBECONFIG:
Скрипт автоматически установил и утилиту kubectl. Убедиться, что с нодой всё в порядке, можно следующей командой:
А ещё лучше проверить, что все поды работают:
Если что-то пойдёт не так, то рестартануть K3s можно с помощью systemctl:
Установка Kubeless
Теперь приступим к установке Kubeless. Для этого нам необходимо скачать и установить CLI. Этот процесс немного автоматизирован, и номер актуальной версии подтягивается с GitHub автоматически с помощью следующей команды:
Далее мы создаём namespace, в котором будут содержаться все наши объекты, относящиеся к Kubeless:
И наконец, устанавливаем сам Kubeless:
Я использую команду для RBAC (role-based access control), так как он более прост и популярен по сравнению с ABAC (attribute-based access control).
Прежде чем приступить к следующему шагу, убедитесь, что контейнер запустился:
Работа с функциями
Воспользуемся vi для создания первой функции.
Не буду приводить список всех команд vi. Достаточно будет только двух.
Чтобы сохранить, нажимаем Esc, а затем :w! Enter.
Чтобы выйти — Esc, а затем :q! Enter.
Деплоим функцию так:
В этой команде первый параметр “hello” — это имя функции.
Далее идёт используемый runtime. Чтобы получить список поддерживаемых runtime, можно выполнить команду:
Ну и наконец, имя файла и handler, описывающий путь к запускаемому методу (имя класса и имя метода, разделённые точкой).
Проверить, задеплоена ли уже функция, можно командой:
Удалить — с помощью:
Если необходимо вывести список всех функций:
Проверить состояние пода:
Теперь создадим простой Cron-триггер:
Он должен будет выполнять нашу функцию каждые 10 минут. Для каждого выполнения будет создан новый под — это то, что называется cold start. Следует учитывать, что cold start занимает какое-то время и ваша функция будет выполнена не ровно через 10 минут.
CronJob может мониторить какой-нибудь health-сервис и отправлять сообщения в случае «падения». Также он может проверять наличие новых данных и производить их обработку — получится что-то вроде ETL (extract, transform and load). Можно разбить какую-нибудь долгую операцию на несколько небольших batch job’ов и выполнять их по таймеру CronJob.
Очень часто возникает необходимость вызвать триггер из Сети. Для этого можно создать HTTP-триггер. Чтобы получить доступ к функции, вашему кластеру необходим ingress. В K3s уже установлен по умолчанию Traefik, и HTTP-триггер можно создать сразу командой:
Проверить, что ingress был создан, можно командой:
У меня этот способ не сработал, поэтому пришлось создавать ingress вручную. Для этого мне потребовалось название сервиса функции и её порт. Получить эти данные можно, выполнив команду:
Мне она выдала такой результат:
Ну и теперь можно создавать ingress:
На всякий случай лишний раз предупреждаю: пробелы довольно важны в YAML-файлах. Создаём ingress командой:
Для того чтобы он начал работать и перенаправлять запросы на сервис hello, необходимо разрешить виртуальной машине доступ извне по протоколу TCP.
На странице Instance виртуальной машины заходите в Primary VNIC и кликайте на вашу Subnet. Со страницы Subnet заходите в Security Lists (у вас будет один security list, созданный по умолчанию). Теперь вам нужно разрешить доступ с вашего IP-адреса по TCP-протоколу, добавив Ingress Rule. Чтобы указать единственный IP в виде CIDR, достаточно добавить к нему /32.
Теперь с помощью curl вы можете активировать триггер (IP адрес — это адрес вашей виртуальной машины):
А вот убедиться, что функция отработала, в нашем простом случае можно только проверив логи (указав при этом начало интервала времени, чтобы отсечь старые записи):
В этой команде hello-5b5cf4b6d4-28tgl — это имя пода.
Заключение
Надеюсь, что на этом примере вы разобрались, как создать бессерверное решение на Kubeless и как с ним можно работать. Если у вас имеется Kubernetes-кластер, то, учитывая, что его ресурсы не бесконечны, вы можете перенести какую-то логику на serverless. Экономия ресурсов — это далеко не единственный кейс. Редко выполняемые операции; задания, выполняемые по таймеру; stateless-операции, требующие создания отдельного экземпляра; обработка файлов и видео, — все эти кейсы довольно благоприятно вписываются в архитектуру в качестве serverless-решений.
В чем разница между IaaS, PaaS, SaaS, FaaS и CaaS
IaaS, SaaS, PaaS, CaaS и FaaS – разновидности сервисов, которые предлагают облачные провайдеры. С их помощью ИТ-службы компаний избавляются от необходимости управлять ресурсами сети, хранением данных, контейнерными технологиями и т.п. Использование облачных сервисов позволяет понизить CAPEX и в целом снизить затраты компании на IT, повысить масштабируемость и скорость разработки и выпуска продукции.
В статье подробно рассмотрим облачные сервисы, их назначение и примеры использования.
IaaS – Инфраструктура как сервис
Классический подход для многих компаний – покупка собственного физического оборудования. IaaS позволяет отказаться от капитальных затрат и арендовать виртуальную инфраструктуру, то есть виртуальный аналог обычного компьютера, на который можно точно так же устанавливать операционную систему и программное обеспечение.
Обслуживанием аппаратной части полностью занимаются специалисты провайдера. Клиентам достаточно просто подключиться к виртуальным машинам и начать работу.
Главные особенности IaaS:
IaaS включает в себя виртуальные серверы, все необходимые сетевые настройки (для связи между виртуальными серверами, а также с внешними серверами клиента и внешним интернетом), управление доступом, облачные хранилища и сервисы резервного копирования.
Использование IaaS позволяет:
В случае аренды виртуальной инфраструктуры возможны различные модели оплаты. В Cloud4Y вы можете арендовать виртуальный сервер на VMware по модели pay-as-you-go. Это означает, что вы платите только за те ресурсы, которые реально потребляли.
PaaS – Платформа как услуга
В рамках услуги PaaS клиент получает полноценную платформу для разработки, выполнения и тестирования приложений. Сюда входит оборудование, необходимое программное обеспечение, а также настройка и обслуживание инфраструктуры. PaaS упрощает разработку, позволяя сконцентрироваться на процессе, а управление бэкэндом оставить провайдеру.
Какие преимущества даёт использование модели PaaS:
Модель оплаты – почасовая за каждый экземпляр.
SaaS – Программное обеспечение как сервис
SaaS – это услуга, благодаря которой можно арендовать лицензионное программное обеспечение. Например, получить во временное пользование облачный Office 365.
Софт имеет лицензию по подписке и находится у поставщика облачных услуг. Практически все SaaS-решения сделаны на базе многопользовательской архитектуры. В рамках этой модели у всех клиентов будет установлена одинаковая версия программного обеспечения с единой конфигурацией.
Услуга SaaS позволяет бизнесу сэкономить на IT за счет выноса обслуживания и поддержки ПО на аутсорс. Приложения по модели SaaS обновляются чаще обычных (раз в месяц или даже раз в неделю). Это вызвано следующими причинами:
Модель оплаты – каждый месяц или раз в год взимается фиксированная плата за каждого пользователя. То есть клиент может убирать или добавлять новых пользователей в любой момент и платить только за реальное их количество.
FaaS – Функция как услуга
Сервис FaaS представляет собой возможность бессерверного запуска кусков кода, благодаря чему разработчики могут писать и обновлять код в процессе. Написанные функции вызываются при наступлении какого-либо события. FaaS позволяет намного проще масштабировать код и вводить микросервисы.
Основные особенности FaaS:
Модель оплаты – обычно тарифицируются по объему и используемому vCPU. Иногда дополнительно взимается плата за вызов функций сверх бесплатного лимита.
CaaS – Контейнер как услуга
Контейнер – это аналог гипервизора, используемый для безопасного запуска приложений. Контейнеры можно запускать в изолированных разделах одного ядра Linux, запущенного на физическом сервере.
Контейнеризация позволяет добиться большей производительности, чем при виртуализации, так как отсутствуют накладные расходы на гипервизоры. Помимо этого, емкость может динамически меняться с вычислительной нагрузкой, поэтому услугу можно оплачивать на основе данных о реальном потреблении ресурсов.
Что такое CaaS?
Container-as-a-Service (CaaS) является формой виртуализации на основе контейнеров, где поставщик облачных услуг предоставляет все решения и инструменты в качестве сервиса. Данная услуга упрощает одноконтейнерные развертывания, в том числе для запуска простых микросервисов, либо предлагает платформу контейнерной оркестровки, например, Kubernetes, позволяющий запускать более сложные многоконтейнерные развертывания.
К платформам контейнерной оркестровки относятся такие услуги, как обнаружение сервисов, планирование контейнеров, сетевое взаимодействие контейнеров, мониторинг и другие.
Модель оплаты – за ресурсы, затраченные на организацию контейнерного кластера (например, за виртуальную машину, балансировщики нагрузки, блочные хранилища). Ряд провайдеров может дополнительно брать плату за управление кластером.
Каждая модель имеет свои особенности, поэтому выбор подходящего сервиса будет полностью зависеть от потребностей вашего бизнеса.