С тех пор, как операторы облаков переключились с полноценных виртуальных машин на контейнеры — менее ресурсоемкие изолированные переносимые ВМ с одним приложением и всеми его зависимостями, доминирующей платформой оркестровки контейнеров остается система с открытым кодом Kubernetes. Вместе с тем, как показывают опросы, во многих организациях воздерживаются от внедрения контейнеров, сетуя на чрезмерный уровень сложности и проблемы с мониторингом, безопасностью и соблюдением требований. Это и не удивительно, учитывая, насколько масштабным является любой проект по переходу от монолитных систем к микросервисам и другим современным технологиям. Тем не менее, в Gartner прогнозируют, что уже к концу этого года больше 95% всех новых цифровых рабочих нагрузок будут развертываться в облачной инфраструктуре.

Эксперты считают, что для завоевания массового рынка Kubernetes нужны усовершенствования с точки зрения удобства использования — сегодня для подготовки платформы к внедрению на предприятии требуется огромный объем работы. Решением проблемы могут стать внутренние платформы разработки (internal developer platforms, IDP) — готовые инструментальные цепочки, сервисы и процессы, которые позволяют значительно ускорить процессы разработки, настройки и внедрения систем на базе Kubernetes. Готовые платформы IDP сегодня предлагаются сообществом открытого кода и рядом стартапов.

Решить проблемы безопасности и комплаенса, которые препятствуют освоению облачных технологий, помог бы эффективный универсальный механизм ведения журналов. Перспективной в этом отношении считается система OpenTelemetry — интерес к ней в последнее время такой же высокий, как и к самой Kubernetes. По данным организации Cloud Native Computing Foundation (CNCF), под эгидой которой разрабатывается OpenTelemetry, система относится к числу самых быстро развивающихся ее проектов с открытым кодом. Ее также называют фреймворком наблюдаемости — OpenTelemetry позволяет создавать исчерпывающие системы телеметрии для мониторинга микросервисов и других современных распределенных систем.

При этом создание собственных внутренних платформ разработки (инженерия платформ, platform engineering) остается делом весьма непростым — здесь тоже нужны перемены, уверены специалисты: по их мнению, необходимо выкарабкаться из «дебрей языков разметки» и повысить уровень абстракции. Прогнозируется, что управление внутренними платформами и инфраструктурой со временем будет исключено из числа задач специалистов по эксплуатации и инженерии надежности производственных сред (Site Reliability Engineering, SRE). Уже сейчас специальные фреймворки позволяют полностью автоматизировать управление инфраструктурой.

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

Эксперты считают, что новый уровень абстракции ПО после контейнеризации может быть достигнут с помощью WebAssembly (WASM), низкоуровневого переносимого языка программирования для Всемирной паутины, код на котором может работать и на клиентской, и на серверной стороне. Приложения, отвечающие компонентной модели WASM, совместимы с контейнерной экосистемой, но не зависят от нее. Компонентым приложениям не присуща проблема холодного запуска (задержки, возникающей при подготовке длительно неиспользуемых контейнеров к запуску), они компактнее контейнеров, более надежно защищены и могут разрабатываться на более широком круге языков и фреймворков.

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

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

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

Помимо облаков Kubernetes начинают применять локально и в классических центрах обработки данных, а также на пограничных системах, что позволяет отказаться от дорогостоящего непрерывного перемещения данных в облако и обратно. Существуют и развиваются малоресурсоемкие дистрибутивы Kubernetes, специально рассчитанные для развертывания на пограничных узлах, в частности, K3 и KubeEdge. Кроме того, под эгидой CNCF активно развивается оркестровщик с открытым кодом wasmCloud, который позволяет быстро разрабатывать и развертывать компонентные приложения на WASM в облачных средах, в ЦОДах и на пограничных системах.