faas что это такое
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Что такое функция как сервис (FaaS)?
Еще один модный термин
Функция как сервис или FaaS (Function as a service) это относительно новомодный термин, которым определяется возможность бессерверного запуска кусков кода, что дает возможность разработчикам писать и обновлять эти куски кода на лету, которые будут запускаться в результате отклика на какое-нибудь событие, к примеру, когда пользователь нажмет на элемент в веб-приложении. Благодаря этому масштабировать код и внедрять микросервисы становится на порядок проще.
Что такое микросервисы?
Такой подход к написанию приложения из набора модульных компонентов известен как микросервисная архитектура. Причем подобный подход довольно тепло воспринимается разработчиками, так как они могут создавать и модифицировать маленькие куски кода, которые относительно легко имплементировать в структуру приложения. Причем в монолитном приложении совершенно обратная ситуация, когда это приложение является огромной и экстремально сложной системой, где изменение одного из элементов может порушить его работу и процесс внесения изменения приближается по сложности к запуску шаттла. Таким образом, использование FaaS многократно снижает сложность внесения изменений и запуска нового кода, что дает возможность разработчикам сосредоточиться на самом коде, в то время как FaaS провайдер будет следить за нужным количеством вычислительных ресурсов и различных бэкэнд сервисов.
Какие плюсы такой технологии?
Увеличенная скорость разработки
С FaaS разработчики могут тратить больше времени на логику приложения и не думать о том, куда и как это приложение воткнуть, что как правило ведет к более высокой скорости написания и имплементации кода.
Bстроенная масштабируемость
Оптимизация затрат
Знаете, какой самый большой страх пользователя облачных серверов? Что вы наберете кучу серверов, а необходимой нагрузки не будет, что повлечет за собой в пустую простаивающие мощности. Логично, что появилась такая модель как FaaS, которая позволяет заказчикам платить только за то время, когда вычислительные мощности действительно работают.
Какие минусы технологии FaaS?
Снижение степени контроля системы в общем
Процесс тестирования становится гораздо сложнее
Впихнуть невпихуемое, а именно микросервисное приложение (или целый комплект таких приложений) в локальное окружение для тестирование становится нетривиальной задачей, и часто начинают требоваться люди с нетривиальным опытом и экспертизой.
Как начать использовать FaaS?
Представляя функции как сервис — OpenFaaS
Прим перев.: OpenFaaS — serverless-фреймворк, формально представленный в августе, но появившийся около года назад и быстро укрепившийся на самой вершине проектов GitHub по тегу Kubernetes. Опубликованный ниже текст — перевод технической части официального анонса проекта от его автора Alex Ellis, который хорошо известен в сообществе своим энтузиазмом в области Docker (имеет статус Docker Captain).
Functions as a Service или OpenFaaS — фреймворк для создания serverless-функций поверх контейнеров. Я начал проект как proof of concept в октябре прошлого года, когда хотел понять, можно ли запускать Alexa skills или функции AWS Lambda в Docker Swarm. Начальные успехи привели меня к публикации в декабре того же года первой версии кода на Golang в GitHub.
Эта публикация предлагает быстрое введение в бессерверные (serverless) вычисления и рассказывает о трёх главных возможностях, появившихся в FaaS за последние 500 коммитов.
С момента первого коммита FaaS набирал популярность: получил более 4000 звёздочек на GitHub (уже более 7000 на сегодняшний день — прим. перев.) и небольшое сообщество разработчиков и хакеров, которые рассказывали о нём на различных встречах, писали свои функции и вносили изменения в код. Значимым событием для меня стало получение места среди главных сессий Moby Cool Hacks на Dockercon в Остине в апреле. Стоявшая перед этими выступлениями задача звучала как расширение границ того, для чего был создан Docker.
Что такое serverless?
Архитектура эволюционирует
Serverless («бессерверный») — неудачное название. Мы говорим о новом архитектурном паттерне для управляемых событиями (event-driven) систем. Serverless-функции часто используются как связующее звено между другими сервисами или в архитектуре, управляемой событиями. Раньше мы называли подобное сервисной шиной (service bus).
Serverless — это эволюция
Serverless-функции
Бессерверная функция — это небольшая, отдельная и ориентированная на повторное использование часть кода, которая:
С одной стороны, у нас есть такие serverless-реализации от IaaS-провайдеров, как Lambda, Google Cloud Functions и функции Azure, а с другой — фреймворки вроде OpenFaaS, позволяющие выполнять тяжёлую работу платформам оркестровки вроде Docker Swarm или Kubernetes.
Cloud native: используй свой любимый кластер.
Serverless-продукт от IaaS-вендора является полностью управляемым, поэтому предлагает высокий уровень удобства использования и оплату по секундам/минутам. Обратная сторона медали — вы очень привязаны к их циклу релизов и поддержки. FaaS с открытым кодом существуют для обеспечения разнообразия и возможности выбора.
В чём особенность OpenFaaS?
OpenFaaS построен на основе технологий, являющихся индустриальным стандартом в мире cloud native:
Стек OpenFaaS
Особенность проекта OpenFaaS заключается в том, что каждый процесс может стать serverless-функцией с помощью компонента watchdog и контейнера Docker. Это означает три вещи:
Например:
Команда cat или sha512sum может быть функцией, не требующей каких-либо изменений, поскольку функции взаимодействуют через stdin/stdout. Windows-функции также поддерживаются в Docker CE.
В этом и есть основное отличие FaaS от других serverless-фреймворков с открытым кодом, которые зависят от специальных исполняемых сред для каждого поддерживаемого языка.
Посмотрим на 3 самые значимые фичи, которые появились с момента DockerCon (т.е. с апреля по август 2017 года — прим. перев.): CLI и шаблоны для функций, поддержка Kubernetes и асинхронная обработка.
1. Новый CLI
Простое развёртывание
Консольный интерфейс (CLI) был добавлен в проект FaaS, чтобы упростить функции деплоя и добавить им поддержку скриптования. До сих пор для этих целей можно было использовать пользовательский интерфейс (UI) к API Gateway или curl. Появившийся CLI позволяет определять функции в YAML-файле и деплоить их в тот же API Gateway.
Finnian Anderson написал замечательное введение в FaaS CLI на Practical Dev / dev.to.
Скрипт утилиты и brew
Для установки CLI есть специальный скрипт, а John McCabe помог с рецептом для brew:
Шаблоны
С помощью шаблонов в CLI достаточно написать обработчика на любимом языке программирования, после чего CLI воспользуется шаблоном для сборки этого обработчика в Docker-контейнер со всей магией FaaS.
Подготовлены два шаблона: для Python и Node.js, — но легко создать и свой собственный.
CLI поддерживает три действия:
Вот пример конфигурационного файла CLI в формате YAML ( sample.yml ):
А вот минимальный (пустой) обработчик для функции на Python:
2. Поддержка Kubernetes
Будучи капитаном Docker, я в основном занимаюсь изучением Docker Swarm и статьями о нём, однако меня всегда интересовал и Kubernetes. Начав изучать, как настроить Kubernetes в Linux и Mac, я уже написал три руководства об этом, и их хорошо встретили в сообществе.
Проектируя поддержку Kubernetes
Получив хорошее понимание того, как перенести концепции Docker Swarm на Kubernetes, я подготовил прототип и портировал весь код за несколько дней. Выбор пал на создание нового микросервисного демона, взаимодействующего с Kubernetes, — вместо добавления дополнительных зависимостей в основную кодовую базу FaaS.
FaaS проксирует вызовы к новому демону через стандартный RESTful-интерфейс для таких операций, как Deploy/List/Delete/Invoke и Scale.
Такой подход означает, что пользовательский интерфейс, CLI и автомасштабирование заработали из коробки без необходимости вносить изменения. Получившийся микросервис поддерживается в новом GitHub-репозитории под названием FaaS-netes и доступен в Docker Hub. Его настройка в кластере занимает около 60 секунд.
Демонстрация поддержки Kubernetes
В этом видео FaaS разворачивается на пустом кластере, после чего показывается, как работать с пользовательским интерфейсом, Prometheus и автомасштабированием.
Но подождите… ведь есть другие фреймворки, которые работают на Kubernetes?
Пожалуй, есть две категории serverless-фреймворков для Kubernetes: те, которые полагаются на очень специфическую исполняемую среду для каждого поддерживаемого языка программирования, и те, что, как и FaaS, позволяют любому контейнеру стать функцией.
У FaaS есть привязки для родного API у Docker Swarm и Kubernetes, то есть он использует объекты, с которыми вы уже работали для управления Deployments и Services. Это означает, что здесь меньше магии и нуждающегося в расшифроке кода, когда дело доходит до сути написания новых приложений.
При выборе фреймворка стоит учитывать, хотите ли вы привносить в проекты новые возможности или исправления. Например, OpenWhisk написан на Scala, а большинство других — на Golang.
3. Асинхронная обработка
Одна из особенностей бессерверной функции — она маленькая и быстрая, исполняется синхронно и обычно за несколько секунд. Но есть ряд причин, почему можно захотеть асинхронной обработки функции:
Иллюстрация из Twitter-анонса асинхронного режима в FaaS
Асинхронный вызов с NATS Streaming в качестве бэкенда включён в кодовую базу проекта. Инструкция по его использованию доступна здесь.
Приветствуются любые изменения
… и не важно, хотите вы помочь с issues, фичами в коде, релизами проекта, скриптованием, тестами, измерением производительности, документацией, обновлением примеров или даже написанием в блоге о проекте.
Для каждого всегда что-нибудь найдётся, и всё это помогает проекту двигаться вперёд.
Любую обратную связь, идеи, предложения отправляйте @alexellisuk или через один из репозиториев GitHub.
Не уверены, с чего начать?
Вдохновитесь обсуждениями и примерами функций от сообщества, которые включают в себя машинное обучение с TensorFlow, ASCII art и простые интеграции.
P.S. от переводчика
Месяц назад автором этого материала была также опубликована инструкция по началу работы с OpenFaaS на Kubernetes 1.8 с использованием Minikube.
Если вас интересует тема serverless под Kubernetes, стоит также обратить внимание (как минимум) на проекты Kubeless и Fission, а более полный список приводит сам автор статьи выше. Вероятно, мы про них ещё напишем в нашем блоге, а пока — читайте среди прошлых материалов:
Как работают и где применяются бессерверные вычисления (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 и умение использовать эти инструменты – это хороший багаж, до боевого применения компаниям стоит подождать пару лет.
Нужно ли готовиться к бессерверному будущему?
Что нужно знать о FaaS и serverless-архитектурах
В прошлый раз я рассказывал о том, как модель FaaS помогает максимально автоматизировать функцию DevOps’ов и снизить их вовлечение в само развертывание кода на инфраструктуре. Парадигма, при которой разработчики могут напрямую взаимодействовать с облачной платформой, минуя devops-инженеров, — это совершенно новый уровень абстракции и автоматизации, с которым предстоит сжиться разработчикам. В этой статье в подробностях изложено, что из себя представляют serverless-среды, какое место в них занимает FaaS, а также об их плюсах и минусах.
Контейнеры или виртуальные машины по-прежнему имеют огромное значение в работе serverless-архитектур. Но избавившись от необходимости ручного управления, разработчики могут сфокусироваться на своих основных задачах (то есть реализации требуемой логики в коде), не вовлекаясь в тонкости инфраструктуры.
Логика приложения должна быть “упакована” в виде отдельных функций, которые исполняются при срабатывании триггеров, вызываемых событиями. Поэтому уже существующие приложения должны в значительной степени подвергнуться рефакторингу, чтобы “вписаться” в эту модель, а новые приложения должны быть уже написаны с учетом этого подхода. Парадигма serverless подходит для микросервисных архитектур, но может потенциально привести к разрастанию кода и числа интерфейсов. Чтобы этого не произошло, требуется особенно внимательно отнестись к проектированию архитектуры системы.
Архитекторам приложений понадобятся новые навыки и адаптация подходов под новую концепцию serverless. На рынке таких специалистов совсем немного, и нарабатывание нужного опыта, пока парадигма бессерверных сред очень новая, обычно означает набивание всевозможных шишек, в связи с чем может снизиться скорость разработки и увеличиться time-to-market. Но знания могут прийти только с опытом.
Модель управляемого сервиса дает разработчикам множество преимуществ в плане ускорения разработки и “аутсорсинга” части функций DevOps, но многих из них может отпугнуть то, что исполнение кода нужно доверить облачной инфраструктуре, которая в их глазах играет роль “черного ящика”. С другой стороны, этот минус частично нивелируется тем, что у крупных облачных провайдеров безопасности и изоляции обычно уделяется намного больше внимания и ресурсов, нежели может себе позволить типичная небольшая ИТ-компания.
FaaS (Function-as-a-Service) — это исполнение функций в бессерверной среде, “упакованное” в сервис, доступный по подписке. В этом случае разработчики пишут код в виде функций, а исполнение этих функций обеспечивается в виде управляемого сервиса, предоставляемого третьей стороной. FaaS отлично подходит для нагрузок, которые предполагают периодическое исполнение функции по запросу или событию.
Самое главное преимущество FaaS — это упрощение и ускорение развертывания: разработчик концентрируется на написании кода, а FaaS-провайдер обеспечивает нужную среду исполнения без привлечения человеческих ресурсов на администрирование инфраструктуры со стороны компании-разработчика.
Но, как и любая свежая технология, FaaS пока имеет некоторые незакрытые пробелы. Например, то, что инфраструктура становится для разработчика “черным ящиком”, ограничивает возможности дебаггинга кода и мониторинга исполнения функции на уровне сервера. Это само по себе нельзя назвать недостатком технологии; скорее это означает, что при разработке нужно учесть очень много тонкостей.
Реализация FaaS на базе облачного сервис-провайдера дает большую гибкость, поддержку многочисленных сред исполнения, а также тесную интеграцию с другими сервисами на платформе.
Основные преимущества при реализации FaaS на базе распределенной облачной платформы — это высокая производительность и низкая задержка.
Перед переходом на FaaS осталось определить, что важнее, и здесь нужно учесть несколько факторов, которые индивидуальны для каждого заказчика в зависимости от его бизнес-задач: емкость сети, охват, снижение нагрузки на серверы оригинации, возможности масштабирования, число и точки размещения узлов и так далее.
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-решений.