Архитектура Kubernetes хорошо подходит для организаций типа FAANG, но может оказаться избыточной и чрезмерно сложной для прочих.
Kubernetes, оркестратор контейнеров с открытым исходным кодом, стал по факту безальтернативным решением для тех, кто развертывает контейнерные приложения в производственной среде. Тому есть много веских причин, и в том числе факт, что Kubernetes предлагает высокую степень надежности, автоматизации и масштабируемости. Тем не менее, мне иногда кажется, что архитектура Kubernetes перебрала хайпа: при том, что ей уже больше шести лет от роду, она всё ещё подвержена множеству недостатков. Некоторые из них присущи Kubernetes от рождения, другие результат развития образовавшейся вокруг платформы экосистемы.
Прежде чем нырнуть в Kubernetes с головой, примите во внимание следующие проблемы с этим опенсорсным оркестратором контейнеров.
1. Kubernetes разработан для компаний типа FAANG
Прежде всего, архитектура Kubernetes изначально была и остаётся предназачена для компаний, которым требуется управлять чрезвычайно масштабными программными окружениями.
Если вы Google (чей оркестратор Borg лег в основу проекта Kubernetes с открытым исходным кодом), Kubernetes для вас отличный инструмент. Также это верно, если вы Netflix, Facebook, Amazon или другая веб-компания с десятками ЦОД и сотнями распределенных по ним приложений и сервисов.
Но если вы небольшая организация, у которой есть одна серверная «на земле» или облачная подписка и, возможно, десяток приложений для развертывания, архитектура Kubernetes, скорее всего для вас избыточна, так же, как перебор бульдозером перекапывать садовый участок. Если вы не используете Kubernetes масштабно, эффект от его решений не стоит требуемых для его настройки усилий и эксплуатационных расходов.
Это не значит, что Kubernetes никогда не будет полезен для небольших развертываний: я полагаю, что он к тому движется. Но всякий раз, когда я сегодня запускаю кластер Kubernetes для развертывания всего одного или двух приложений на небольшом количестве серверов, я остаюсь в убеждении, что лучше бы мне было использовать решение попроще.
2. Рынок Kubernetes раздроблен
Еще одна проблема с архитектурой Kubernetes заключается в том, что существует слишком много дистрибутивов Kubernetes — и слишком много различных инструментов, философий и связанных с ними подходов — так, что экосистема Kubernetes получилась слишком раздробленной.
Конечно, фрагментация это удел любой экосистемы с открытым исходным кодом, до некоторой степени. Например, в Red Hat Enterprise Linux другой менеджер пакетов, другие инструменты управления и так далее, чем в Ubuntu. Однако в Red Hat и Ubuntu больше сходства, чем различий. Если вы системный администратор и сегодня работаете с Red Hat, вам не нужно тратить шесть месяцев на изучение новых инструментов, если вы вдруг захотите перейти на Ubuntu.
Я не думаю, что то же самое верно применительно к Kubernetes. Если вы сегодня используете, скажем, OpenShift, но захотели перейти на VMware Tanzu, вам предстоит весьма крутая кривая обучения. Хотя оба этих дистрибутива Kubernetes используют одну и ту же базовую платформу, добавленные ими методологии и инструменты сильно различаются.
Подобная фрагментация наблюдается и в облачных сервисах Kubernetes. У Google Kubernetes Engine, или GKE, совсем другой пользовательский интерфейс и набор инструментов управления, чем у такой платформы, как Amazon EKS (аналога GKE в облаке AWS).
Конечно, тут не вина самой архитектуры Kubernetes, а результат стремления вендоров к дифференциации своих продуктов. Но это болезненная проблема с точки зрения пользователей Kubernetes.
3. В Kubernetes слишком много частей
Мы говорим о Kubernetes как о единой платформе, но на самом деле он состоит из более чем полудюжины различных компонентов. Это означает, что когда вы собираетесь установить Kubernetes или обновить его, вам придется иметь дело с каждой его частью отдельно. Но в большинстве дистрибутивов Kubernetes для этого отсутствуют худо-бедно автоматизированные решения.
Конечно, Kubernetes — сложная платформа, и для ее работы реально требуется множество частей. Но, сравнительно с другими сложными платформами, Kubernetes выделяется низким качеством интеграции своих различных частей в легко управляемое целое. Хотя ваш типичный дистрибутив Linux также состоит из множества различных программ, вам доступна установка и управление всеми ими централизованным и оптимизированным способом. С архитектурой Kubernetes так не получится.
4. Kubernetes не гарантирует высокую доступность автоматически
Одна из наиболее часто упоминаемых причин использования Kubernetes — это представление о его магической способности управлять вашими приложениями таким образом, чтобы гарантировать что они никогда не упадут, даже если упадёт часть вашей инфраструктуры.
Это верно, что архитектура Kubernetes автоматически принимает разумные решения о том, где разместить рабочие нагрузки в кластере. Однако Kubernetes далеко не палочка-выручалочка для обеспечения высокой доступности. Например, он будет успешно работать в производственной среде с одним мастер-узлом — а это дорога к падению всего кластера. (Ведь рабочие нагрузки недолго протянут, если упадёт управляющий кластер из мастер узлов.)
Кроме того, Kubernetes не может автоматически гарантировать, что ресурсы кластера правильно распределяются между выполняемыми в нём различными рабочими нагрузками. Чтобы этого добиться, вам необходимо вручную настроить квоты ресурсов.
5. Управлять Kubernetes вручную сложно.
Несмотря на то, что Kubernetes требует серьёзного ручного вмешательства для обеспечения высокой доступности, он умудряется значительно затруднить вам ручной контроль, если именно таковой вам необходим.
Безусловно, есть способы изменить тайминги, используемые Kubernetes чтобы определить, правильно ли работает контейнер, или чтобы отправить рабочую нагрузку запускаться на определенном сервере в кластере. Но архитектура Kubernetes, на самом деле, не рассчитана на то, что администраторы будут вносить эти изменения вручную. Предполагается, что вы всегда будете довольны настройками по умолчанию.
Смысл в этом есть, учитывая, что (как отмечалось выше) Kubernetes был создан в первую очередь для крупномасштабных развертываний. Имея тысячи серверов и сотни приложений, вы не собираетесь многое настраивать вручную. Но Kubernetes вам не поможет, если у вас небольшая фирма и вы хотите больше контроля над структурой рабочих нагрузок в кластере.
6. У Kubernetes есть проблемы с мониторингом и оптимизацией производительности
Kubernetes пытается поддерживать ваши рабочие нагрузки в рабочем состоянии (хотя, как выше отмечалось, его способность делать это зависит от таких факторов, как количество установленных вами мастеров и ваша структура распределения ресурсов).
Но архитектура Kubernetes не очень-то помогает вам отслеживать рабочие нагрузки и обеспечивать их оптимальную производительность. Он не предупреждает вас о проблемах и не упрощает сбор данных мониторинга из кластера. Большинство поставляемых с дистрибутивами Kubernetes панелей мониторинга также не предлагают всестороннего обзора вашей среды. Существуют сторонние инструменты, которые дают вам такую видимость — но это еще одна сущность, которую вам предстоит настроить, изучить её и управлять ею, если вы хотите запустить Kubernetes.
Точно так же, Kubernetes не очень-то хорош в том, чтобы помочь вам оптимизировать ваши расходы. Он не уведомляет вас, если серверы в кластере используются только на 20% мощности, что вероятно значит, что вы тратите деньги на избыточно выделенную инфраструктуру. И здесь сторонние инструменты могут помочь вам справиться с подобными проблемами, но сами они добавляют ещё больше сложности.
7. Kubernetes всё сводит к коду
В Kubernetes требуется писать код для выполнения практически любой задачи, обычно в виде файлов YAML, которые затем необходимо применить в командной строке Kubernetes.
Многие люди видят не баг, а фичу в архитектурном принципе Kubernetes «всё есть код». Однако, хотя я, безусловно, понимаю ценность возможности управлять всей платформой с использованием единых методологии и инструментария (то есть файлов YAML), я также хотел бы, чтобы Kubernetes предлагал и другие варианты для тех людей, которые в них нуждаются.
Бывают случаи, когда я для развертывания простой рабочей нагрузки не хочу писать длинный файл YAML — или тащить его с гитхаба, а затем вручную настраивать по частям в соответствии с моей средой. Когда мне нужно сделать что-нибудь простое в Kubernetes, мне действительно хотелось бы просто нажать кнопку или запустить простую команду (я имею в виду команду kubectl, не требующую дюжины аргументов, многие из которых настроены с помощью загадочной копипасты) — но так сделать редко удаётся.
8. Kubernetes хочет всё полностью контролировать
Моя последняя жалоба на Kubernetes заключается в том, что он совершенно не предназначен для работы с системами другого типа. Он хочет быть единственной платформой, которую вы используете для развертывания приложений и управления ими.
Это хорошо, если все ваши рабочие нагрузки контейнеризированы и могут оркестрироваться Kubernetes. Но что, если у вас есть устаревшие приложения, которые не могут работать в контейнерах? Или что, если вы хотите запустить часть рабочей нагрузки в кластере Kubernetes, а другую часть выполнять где-то снаружи? Kubernetes не предлагает встроенных функций для подобных задач. Он разработан в предположении, что все хотят запускать всё внутри контейнеров, и это навсегда.
Заключение
Чтобы меня не обвинили в ненависти к Kubernetes, позвольте мне еще раз заявить, что это мощный инструмент для оркестрации крупномасштабных контейнеризованных приложений. Есть множество вариантов использования, для которых Kubernetes отлично подходит.
Но у архитектуры Kubernetes есть и недостатки. В целом, это не лучшее решение, если у вас есть устаревшие рабочие нагрузки, которыми нужно управлять, и-или если масштаб ваших развертываний недостаточно велик, чтобы оправдать всю сложность, которую приносит с собой Kubernetes. Чтобы доказать свою полноценность и соответствовать репутации, которой он пользуется в определенных сферах ИТ-экосистемы, Kubernetes должен решить эти проблемы.
— От переводчика:
Напоминаю более вкусные ссылки для ценителей кондитерских изделий:
K8s в проде и в разработке: четыре мифа
10 антипаттернов деплоя в Kubernetes: распространенные практики, для которых есть другие решения
11 факапов PRO-уровня при внедрении Kubernetes и как их избежать
Автор:
sundmoon
