Неизбежное будущее Kubernetes: почему оркестратор должен пойти по пути Linux Kernel
На Kubecon + CloudNativeCon в Чикаго 9 ноября Тим Хокин, один из первых разработчиков Kubernetes выступил с докладом (а вот и его текстовый пересказ), в котором рассказал об одной из серьезный проблем оркестратора — неуклонно возрастающей сложности. Мысль простая: Kubernetes начинают использовать для большого количества специфических задач, например, для ML, в итоге у пользователей появляется все больше требований к K8s, разработчики пытаются за ними угнаться, а Kubernetes становится настолько сложным, что возникает сразу две подпроблемы:
Сами разработчики Kubernetes начинают теряться в обилии фичей и функциональности — то есть в коде проекта. Он становится слишком сложным для них.
Инженеры, которые внедряют и поддерживают Kubernetes в компаниях, уже с трудом способны освоить все его «крутилки».
Тим Хокин предложил решение проблемы — введение так называемого complexity budget. Согласно этому подходу, разработчики K8s будут иметь некий «бюджет» на сложность проекта и появление в релизе каждой из фичей будет это бюджет сжигать. Так, по мнению Тима, рост сложности проекта можно будет взять под контроль. Это разумно, однако, на мой взгляд, рынок: и разработчики Kubernetes, и бизнес, который его использует, и инженеры, которые его внедряют, — в ближайшие годы должны пересмотреть свое понимание оркестратора.
Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков).
На мой взгляд, такое понимание Kubernetes заводит рынок в тупик. Очевидно, что сложность оркестратора должна расти, очевидно, что будет все больше сфер, в которых он будет использоваться и которые способны извлечь немало пользы из внедрения K8s. И требованиям этих сфер он должен соответствовать, чтобы быть успешным продуктом и сохранять свои лидирующие позиции.
Рынок должен начать смотреть на Kubernetes как на Linux Kernel. Что я имею в виду? В трезвом уме сисадмину маленькой или средней компании не придет в голову говорить на работе, что не нужно использовать дистрибутив Linux, а вместо этого он сейчас возьмет ядро и соберет свой дистрибутив. Так просто не принято, все понимают, что надо выбирать готовый дистрибутив, подходящий под конкретный набор задач. Да, есть и универсальные дистрибутивы, которые более-менее успешно могут использоваться под разные задачи, но есть и куча специфических дистрибутивов вроде того же Talos Linux, которые заточены под конкретные виды задач.
Кроме того, у дистрибутивов есть свои удобные пакетные менеджеры, которые позволяют быстро добавлять различное необходимое ПО.
А что такое дистрибутив Linux? Это несколько компонентов:
Ядро с набором утилит от GNU.
Пакетный менеджер.
Собственные репозитории с проверенным и протестированным ПО.
Релизные циклы.
Тюнинг ядра под набор задач, которые дистрибутив решает.
Сочетание командных и графических оболочек, менеджеры конфигурации и т.п.
Сообщество и/или команда разработки, которая обеспечивает непрерывность обновлений системы.
Всё это, на мой взгляд, CNCF и рынку стоит взять на вооружение. Чтобы Kubernetes позволял максимально полно удовлетворять нужды различных технологических сфер, он должен прекратить существование в качестве условно самодостаточного ПО и превратиться в аналог Linux Kernel — сложной системы, с которой взаимодействует и которую знает очень ограниченное количество специалистов.
При этом аналогом дистрибутивов Linux станут платформы — свободные и проприетарные, которые будут поставлять Kubernetes с возможностью его расширения с помощью как cloud native-утилит, которые являются сателлитами оркестратора и работают исключительно на обогащение его «прямой» функциональности, так и баз данных, сервисов вроде Kafka и других инструментов, которые позволят использовать эту самую готовую платформу для развертывания окружения под решение конкретных задач.
Хотите крутить ML/AI — вот вам с десяток «дистрибутивов», которые изначально сконфигурированы под эту задачу, в которых уже есть Kuberbetes и остальные компоненты с предустановленными оптимальными настройками и каким-то количеством доступных пользователю «крутилок». Или можно выбрать один из универсальных дистрибутивов, на котором удовлетворительно крутится более-менее всё.
В такой схеме DevOps-инженерам, SRE-инженерам и прочим техническим специалистам уже не придется ковыряться в кишках Kubernetes и настраивать всю систему в целом — они начнут решать более важные для бизнеса продуктовые задачи и фокусироваться именно на них, а не на базовом уровне инфраструктуры.
Сейчас ситуация далека от этой картинки. Да, есть многочисленные облачные платформы, но они воспринимаются именно как альтернатива ванильному Kubernetes и сравниваются не только между собой, но и с ним или с инфраструктурой, собранной из «исходников». А инженеры нередко отвергают попытку привнесения готовых платформ, настаивая, что в них всё работает криво и они-то уж точно могут все настроить с нуля и сделать это лучше. Также часто слышатся лозунги: тут я знаю, как все работает, а там у меня закрытая коробка/открытая коробка, в коде которой не разобраться.
Я считаю, что такой взгляд на Kubernetes ограничивает развитие как самого оркестратора, так и всей облачной экосистемы. Инженеры и их квалификация становятся «бутылочным горлышком» в процессе построения и поддержания инфраструктуры.
Многие ли инженеры четко и полноценно понимают, что там скрыто в недрах Linux Kernel, какие крутилки ядра применены в том или ином дистрибутиве Linux? А все потому, что рынок принял дистрибутив как некий эталон юнита с минимальной единицей бизнес-ценности, дробить эту абстракцию до уровня ядра или отдельных компонентов ядра просто нет смысла. Конечно, крупные компании собирают свои дистрибутивы — например, тот же Microsoft уже в новой технологической истории сделал Azure Linux. Однако большинству компаний это не нужно.
Тут возникает вопрос:, а как поменять это мышление? Что для этого должно произойти? На мой взгляд, для полноценного запуска этого тектонического сдвига необходимы следующие процессы:
Рабочие группы CNCF (TAG App Delivery, Technical Oversight Committee, а также мейнтейнеры и главные спонсоры Kubernetes) должны запустить дискуссии по этой теме. Обсудить перспективы и угрозы, в итоге выработав некую продуктовую стратегию. Потому что в итоге Kubernetes как продукт должен претерпеть достаточно серьезные изменения — одно дело, когда разрабатывается полноценное ПО и совсем другое, когда разрабатывается компонент, пусть и центральный.
TAG App Delivery, Technical Oversight Committee должны начать говорить с рынком и транслировать в него послание о том, что необходимо много платформ, чтобы были альтернативы. А также создать документы и технические условия, позволяющие максимально упростить процесс создания платформы (собственно, Kubernetes как продукт должен сфокусироваться именно на том, что он становится центральным компонентом сторонней платформы).
Талантливые и предприимчивые инженеры, а также часть тех компаний, которые разрабатывали свои внутренние платформы, должны переключиться на разработку публичных платформ (свободных или проприетарных — это уже вопрос второй, главное, чтобы были альтернативы).
Крупные игроки различных рынков должны начать объединяться вокруг различных платформ или создавать новые, которые максимально соответствуют требованиям конкретного рынка и заточены под него.
CNCF и другие open source-организации должны брать такие проекты под свое крыло и помогать им развиваться, а также выделять под продвижение такого подхода временные слоты на ключевых конференциях, которые они организуют (речь, например, о Kubecon).
Итогом должен стать развитый рынок готовых решений, платформ, которые комплексно закрывают потребность компаний в построении как публичных облаков (сервис- и хостинг-провайдеры), так и приватных облаков или облаков на bare metal и в закрытых контурах (компании-конечные пользователи платформ).
В данный момент мы стремимся именно к этому и именно поэтому мы пытаемся затащить Cozystack в CNCF: это будет четкий сигнал рынку о том, что описанный выше процесс уже запущен. По нашему мнению, это положит начало очень классным изменениями, которые пойдут на пользу всем.
Буду благодарен за критику, уточнения, замечания и вообще любые ваши мысли. Ведь это не законченная концепция, уже проверенная рынком и временем, а только начало публичного обсуждения разобранной проблемы.
