Разработчики ядра Kubernetes должны тщательно взвешивать преимущества, которые дают новые фичи, чтобы не раздувать сложность всего проекта, поскольку K8s и так становится слишком сложным не только для конечных пользователей, но и для core-команды разработки. Этой теме, а также обзору почти 10 первых лет развития Kubernetes Тим Хокин посвятил свой доклад на Kubecon + CloudNativeCon в Чикаго 9 ноября.
Этот материал — пересказ статьи «Tim Hockin: Kubernetes Needs a Complexity Budget» (автор — Joab Jackson, шеф-редактор The New Stack), дополненный нашими мыслями и рассуждениями.
По словам Тима, Kubernetes уже довольно неплохо поддерживает масштабируемые веб-приложения, но его все чаще выбирают как платформу для еще более сложных и специфических задач — например, для логического вывода в машинном обучении (Machine Learning Inference), — что в итоге неизбежно влечет за собой необходимость расширения функциональности K8s для покрытия большего числа сценариев применения.
Тим поспрашивал участников cloud native-сообщества, что именно им кажется самой большой проблемой Kubernetes, и получил ответ: многих инженеров уже пугает сложность развертывания и обслуживания открытого решения для оркестрации контейнеров (у нас был доклад на эту тему). Один из слушателей даже назвал возрастающую сложность «самой большой экзистенциальной угрозой» для K8s.
Решение проблемы Хокин видит в жестком ограничении уровня сложности при разработке Kubernetes — он предлагает заложить «бюджет на сложность» (complexity budget), который как раз и задавал бы лимит на новые фичи и неконтролируемый рост способов применения. Чем больше сложность проекта, тем меньше возможностей остается у core-команды для внесения изменений в будущем и тем большее сопротивление такое нововведение будет встречать со стороны пользователей.
«Существует конечный уровень сложности, который мы можем внедрить в проект за определенное время».
Тим Хокин
За почти 10 лет существования Kubernetes к его разработке приложили руку порядка 74 000 человек — кто-то писал код, кто-то присылал issues и баг-репорты. Однако новые поколения пользователей и разработчиков Kubernetes уже не смогут погружаться во внутреннее устройство оркестратора так же глубоко, как первая волна. Следовательно, по мнению Хокина, core-команда должна приложить все усилия, чтобы упростить использование и не усложнять слишком сильно дальнейшее поддержание и развитие проекта.
«Чем сложнее что-то, что мы добавляем, тем большую часть бюджета мы съедаем. А когда бюджет заканчивается, происходят очень неприятные вещи».
Тим Хокин
Речь о том, что с ростом сложности все труднее становится внедрять инновации, приносить свежие перспективные технологии — в итоге пользователи просто начнут искать другие решения. Поэтому руководители проекта должны понимать сложность не как некую абстрактную величину, а как конкретный, а главное, конечный ресурс. Правда, сам Хокин пока не знает, как именно можно измерять эту сложность и как определить и предсказать, где заканчивается терпимость пользователей к сложности ПО.
При этом он отметил, что некое внутреннее понимание чрезмерной сложности есть у каждого инженера. А потому, добавляя новую фичу, разработчики должны задавать себе простые вопросы: а точно ли нам хватает остатков из бюджета на сложность на такую фичу? И если бюджета хватает, стоит ли его вообще тратить именно на эту функциональность? Например, вы расширили кодовую базу ради повышения производительности какой-то функции на 5%, но стоит ли оно того, если при этом серьезно возрастает внутренняя сложность проекта и его становится гораздо труднее поддерживать и развивать? А если есть желание дополнить API, чтобы Kubernetes мог научиться решать какие-то нишевые задачи, то насколько оправданно будет привносить эту дополнительную сложность для пользователей?
Правильный отказ от части новый функций, даже хороших, полезных и легкореализуемых, оставляет некий задел, люфт, который в будущем позволит реализовать более важные проекты.
«Мы должны сказать „нет” сегодняшним фичам, чтобы завтра иметь возможность делать более интересные вещи. Мы привыкли думать, что чем больше, тем лучше, но Kubernetes, возможно, подходит к тому, что теперь меньшее равно большему».
Тим Хокин
Все, что дальше — уже наши мысли.
Сложность — типичная продуктовая проблема
По сути, это проблема любого продукта — в том числе коммерческого. И в продуктовом менеджменте вопрос добавления новых функций в угоду какому-то количеству пользователей является одним из краеугольных. Удовлетворить 10% пользователей и сделать продукт не тем, чем он был изначально и за что его полюбили пользователи, или оставить часть пользователей неудовлетворенными, сохранив изначальный дух и предназначение продукта?
Похожие проблемы затрагивал и Ли Якокка в «Карьере менеджера», когда анализировал американский автопром: компания выпускает компактное авто, которое нравится людям именно из-за своих скромных габаритов, но с каждой новой модификацией модель становится все больше и больше. Покупатели говорят, что машина отличная, но вот если бы в ней было чуть больше места, чуть более вместительный багажник, то она стала бы еще лучше. В конечном итоге любая компактная модель через несколько поколений становилась стандартным большим авто.
Конечно, в Open Source-проекте подобный баланс соблюсти гораздо сложнее — и даже если в проекте есть авторитетный руководитель вроде Линуса Торвальдса, слишком много сил влияет на конечное решение: корпорации, которые тратят деньги и силы своих сотрудников на развитие проекта, опытные, заслуженные разработчики из core-команды, у которых тоже есть свой взгляд на развитие, пользователи, которые пишут многочисленные статьи и просьбы о том, что им хотелось бы видеть в проекте и чего, по их мнению, в проекте быть не должно. А еще вечная проблема легаси, обратной совместимости и постоянной нехватки времени и сил.
Что может ожидать Kubernetes
Это довольно фантазийный раздел. Некоторые сценарии уже реализуются, некоторые могут показаться откровенно нереалистичными — нам просто хотелось порассуждать о том, какие пути решения сложившейся ситуации могут быть у Kubernetes. И конечно, нам бы очень хотелось узнать и ваше мнение относительно будущего оркестратора.
Сценарий 1. Со сложностью будут бороться платформы. Согласно прогнозам Gartner, к 2027 году более 50% enterprise-компаний начнут использовать готовые облачные платформы для ускорения бизнес-инициатив. Появление managed Kubernetes от крупных провайдеров или платформ вроде OpenShift, Rancher или нашего Deckhouse — это в том числе и ответ на вопрос «Как бороться со сложностью Kubernetes и как оцифровать опыт и лучшие практики работы с K8s, упаковав их в продукт?».
Сценарий 2. Внесение специфической функциональности в отдельные независимые модули. По такому пути пошла команда Kotlin, вынеся корутины за пределы языка в отдельную независимую библиотеку. Это позволяет развивать язык и корутины асинхронно и независимо друг от друга, без жесткой привязки к версиям. Примеры в экосистеме Kubernetes:
Container Storage Interface, пришедший на смену различным in-tree-плагинам;
Pod Security Admission и Pod Security Standards, заменившие Pod Security Policies;
и в целом борьба между in-tree-плагинами и out-of-tree-плагинами.
Сценарий 3. Kubernetes пойдет по пути Linux. Это более радикальный вариант первого сценария. Kubernetes уже называют операционной системой для облаков. Так что в будущем его развитие может пойти по пути Linux: сам Kubernetes будет развиваться и существовать в виде некоего «ядра», на основе которого разные вендоры будут собирать свои дистрибутивы под разные специфические задачи. Отличие от первого сценария в том, что ядро Linux фактически используется только создателями дистрибутивов, а не конечными пользователями (даже когда речь идет о проектах вроде LFS).
Сценарий 4. Новые продукты вокруг Kubernetes, которые будет поддерживать core-команда разработки. Это развитие второго и третьего сценариев. При таком подходе core-команда может формировать отдельные независимые продукты, которые будут вынесены за рамки Kubernetes. Например, отдельное решение для ML, отдельное — для каких-то еще задач. Уже существует немало kubernetes-sigs-проектов, которые не взяли в ядро K8s. Яркие примеры — cluster-api или gateway-api.
Сценарий 5. Все останется как есть. Пользователи будут терпеть возрастающую сложность, потому что деваться некуда, компании будут предпочитать «ванильный» Kubernetes платформам и пытаться растить собственную экспертизу из страха перед vendor lock.
Сценарий 6. Kubernetes уступит место кардинально новому продукту — молодому, дерзкому, модному, более привлекательному, тому, который будет лучше отвечать на вызовы современного ИТ и соответствовать запросам пользователей. Родиться он может как в недрах самого Kubernetes, так и независимо от оркестратора.
Сценарий 7. Придут NoCode, SkyNet и OpenAI и всех заменят :)
В то, что проблему способен эффективно решить «бюджет на сложность», верится с трудом — это может лишь замедлить рост сложности, сделать его более контролируемым, но остановить его подобными средствами вряд ли получится.
P.S.
Читайте также в нашем блоге:
Смотрите на YouTube:
