На Kubecon + CloudNativeCon в Чикаго 9 ноября Тим Хокин, один из первых разработчиков Kubernetes выступил с докладом (а вот и его текстовый пересказ), в котором рассказал об одной из серьезный проблем оркестратора — неуклонно возрастающей сложности. Мысль простая: Kubernetes начинают использовать для большого количества специфических задач, например, для ML, в итоге у пользователей появляется все больше требований к K8s, разработчики пытаются за ними угнаться, а Kubernetes становится настолько сложным, что возникает сразу две подпроблемы:

1. Сами разработчики Kubernetes начинают теряться в обилии фичей и функциональности — то есть в коде проекта. Он становится слишком сложным для них.

2. Инженеры, которые внедряют и поддерживают Kubernetes в компаниях, уже с трудом способны освоить все его опции и настройки.

Тим Хокин предложил решение проблемы — введение так называемого complexity budget. Согласно этому подходу, разработчики K8s будут иметь некий «бюджет» на сложность проекта и появление в релизе каждой из фичей будет это бюджет сжигать. Так, по мнению Тима, рост сложности проекта можно будет взять под контроль. Это разумно, однако, на мой взгляд, рынок: и разработчики Kubernetes, и бизнес, который его использует, и инженеры, которые его внедряют, — в ближайшие годы должны пересмотреть свое понимание оркестратора.

Сейчас Kubernetes воспринимается как «готовое» и самодостаточное ПО — грубо говоря, как отдельная программа. Да, чтобы его использовать в проде, придется добавить к нему разных cloud native-инструментов: CNI, service mesh и т.п. штуковины. Однако всё же K8s выглядит именно как приложение (иногда его даже называют ОС для облаков). 

На мой взгляд, такое понимание Kubernetes заводит рынок в тупик. Очевидно, что сложность оркестратора должна расти, очевидно, что будет все больше сфер, в которых он будет использоваться и которые способны извлечь немало пользы из внедрения K8s. И требованиям этих сфер он должен соответствовать, чтобы быть успешным продуктом и сохранять свои лидирующие позиции.

Рынок должен начать смотреть на Kubernetes как на Linux Kernel. Что я имею в виду? В трезвом уме сисадмин маленькой или средней компании вряд ли станет говорить на работе, что не нужно использовать дистрибутив Linux — мол, сейчас он возьмет ядро и соберет свой дистрибутив. Так просто не принято: все понимают, что надо выбирать готовый дистрибутив, подходящий под конкретный набор задач. Да, есть и универсальные дистрибутивы, которые более-менее успешно могут использоваться под разные задачи, однако помимо дистрибутивов общего пользования (generic purpose), есть и куча специфических дистрибутивов вроде того же Talos Linux, Kali Linux, VyOS, DSL, SLAX, которые заточены под конкретные виды задач. 

Кроме того, у дистрибутивов есть свои удобные пакетные менеджеры, которые позволяют быстро добавлять различное необходимое ПО.

А что такое дистрибутив Linux? Это несколько компонентов:

1. Пакетный менеджер.

2. Ядро с набором утилит от GNU.

3. Собственные репозитории с проверенным и протестированным ПО.

4. Релизные циклы. 

5. Тюнинг ядра под набор задач, которые дистрибутив решает.

6. Сочетание командных и графических оболочек, менеджеры конфигурации и т.п.

7. Сообщество и/или команда разработки, которая обеспечивает непрерывность обновлений системы.

Всё это, на мой взгляд, CNCF и рынку стоит взять на вооружение. Чтобы Kubernetes позволял максимально полно удовлетворять нужды различных технологических сфер, он должен прекратить существование в качестве условно самодостаточного ПО и превратиться в аналог Linux Kernel — сложной системы, с которой взаимодействует и которую знает очень ограниченное количество специалистов.

При этом аналогом дистрибутивов Linux станут платформы — свободные и проприетарные, которые будут поставлять Kubernetes с возможностью его расширения с помощью как cloud native-утилит, которые являются сателлитами оркестратора и работают исключительно на обогащение его «прямой» функциональности, так и баз данных, сервисов вроде Kafka и других инструментов, которые позволят использовать эту самую готовую платформу для развертывания окружения под решение конкретных задач. 

Хотите крутить ML/AI — вот вам с десяток «дистрибутивов», которые изначально сконфигурированы под эту задачу, в которых уже есть Kubernetes и остальные компоненты с предустановленными оптимальными настройками и каким-то количеством доступных пользователю опций и настроек. Или можно выбрать один из универсальных дистрибутивов, на котором удовлетворительно крутится более-менее всё.

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

Сейчас ситуация далека от этой картинки. Да, есть многочисленные облачные платформы, но они воспринимаются именно как альтернатива ванильному Kubernetes и сравниваются не только между собой, но и с ним или с инфраструктурой, собранной из «исходников». А инженеры нередко отвергают попытку привнесения готовых платформ, настаивая, что в них всё работает криво и они-то уж точно могут все настроить с нуля и сделать это лучше. Также часто слышатся лозунги: тут я знаю, как все работает, а там у меня закрытая коробка/открытая коробка, в коде которой не разобраться. 

Хотя многие инженеры принимают и осознают тот факт, что они могут всё это настроить самостоятельно, они всё же выбирают opinionated-дистрибутивы, потому что такие дистрибутивы позволяют решать определённый скоуп рутинных задач и делают это хорошо. Благодаря этому, можно абстрагироваться от рутины и посвятить больше времени решению конкретных бизнесовых задач. По той же причине готовые дистрибутивы любят руководители и владельцы бизнеса.

Я считаю, что такой взгляд на Kubernetes ограничивает развитие как самого оркестратора, так и всей облачной экосистемы. Инженеры и их квалификация становятся «бутылочным горлышком» в процессе построения и поддержания инфраструктуры. 

Многие ли инженеры четко и полноценно понимают, что там скрыто в недрах Linux Kernel, какие крутилки ядра применены в том или ином дистрибутиве Linux? А все потому, что рынок принял дистрибутив как некий эталон юнита с минимальной единицей бизнес-ценности, дробить эту абстракцию до уровня ядра или отдельных компонентов ядра просто нет смысла. Конечно, крупные компании собирают свои дистрибутивы — например, тот же Microsoft уже в новой технологической истории сделал Azure Linux. Однако большинству компаний это не нужно.

Тут возникает вопрос: а как поменять это мышление? Что для этого должно произойти? На мой взгляд, для полноценного запуска этого тектонического сдвига необходимы следующие процессы:

1. Рабочие группы CNCF (TAG App Delivery, Technical Oversight Committee, а также мейнтейнеры и главные спонсоры Kubernetes) должны запустить дискуссии по этой теме. Обсудить перспективы и угрозы, в итоге выработав некую продуктовую стратегию. Потому что в итоге Kubernetes как продукт должен претерпеть достаточно серьезные изменения — одно дело, когда разрабатывается полноценное ПО и совсем другое, когда разрабатывается компонент, пусть и центральный. 

2. TAG App Delivery, Technical Oversight Committee должны начать говорить с рынком и транслировать в него послание о том, что необходимо много платформ, чтобы были альтернативы. А также создать документы и технические условия (или инициировать формирование новой рабочей группы), позволяющие максимально упростить процесс создания платформы (собственно, Kubernetes как продукт должен сфокусироваться именно на том, что он становится центральным компонентом сторонней платформы).

3. Талантливые и предприимчивые инженеры, а также часть тех компаний, которые разрабатывали свои внутренние платформы, должны переключиться на разработку публичных платформ (свободных или проприетарных — это уже вопрос второй, главное, чтобы были альтернативы). 

4. Крупные игроки различных рынков должны начать объединяться вокруг различных платформ или создавать новые, которые максимально соответствуют требованиям конкретного рынка и заточены под него.

5. CNCF и другие open source-организации должны брать такие проекты под свое крыло и помогать им развиваться, а также выделять под продвижение такого подхода временные слоты на ключевых конференциях, которые они организуют (речь, например, о Kubecon).

Итогом должен стать развитый рынок готовых решений, платформ, которые комплексно закрывают потребность компаний в построении как публичных облаков (сервис- и хостинг-провайдеры), так и приватных облаков или облаков на bare metal и в закрытых контурах (компании-конечные пользователи платформ).

В данный момент мы стремимся именно к этому и именно поэтому мы пытаемся передать Cozystack в CNCF: это будет четкий сигнал рынку о том, что описанный выше процесс уже запущен. По нашему мнению, это положит начало очень классным изменениями, которые пойдут на пользу всем.

Буду благодарен за критику, уточнения, замечания и вообще любые ваши мысли. Ведь это не законченная концепция, уже проверенная рынком и временем, а только начало публичного обсуждения разобранной проблемы.