Kubernetes – это Multics нашего поколения

блог | oilhell.org

2041 – 10 – 19

Вчерашний пост перечислил # блоговых тем , связанных с пониманием и использованием оболочки. Сегодняшний пост начинался как “набор” других тем, но теперь он сосредоточен вокруг проблем с # распределенными системами .

Какая связь между оболочкой и распределенными системами?

В общем, сценарий оболочки вызывает Unix-процессы и распределенные системы (почти всегда) представляют собой наборы процессов.

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

Я надеюсь, что Oil может стать основой для лучшего системы, но еще предстоит преодолеть большой пробел. Этот пост сфокусирован на критике существующего положения вещей, поскольку мы должны выявлять проблемы, чтобы их решить.

Kubernetes – наш Мультики поколения

Давайте начнем этот пост со смелого утверждения: Kubernetes – это Multics !

То есть это серьезная, респектабельная, но чересчур сложная система, которая в конечном итоге будет заменена чем-то более простым: Unix распределенных операционных систем .

(Можно спорить, заслуживает ли Kubernetes называться распределенной ОС, но пока оставим это в стороне.)

Это то же утверждение, но в другой формулировке:

В будущем мы будем использовать распределенную ОС, разработанную с учетом Принцип Перлиса-Томпсона .

По сути, это означает, что в нем будет меньше концептов и быть более композиционным .

Кен Томпсон против Kubernetes

Вот еще цвет на претензии. Напомним, что определение принципа Перлиса-Томпсона получен из этой части первой статьи по оболочке Unix:

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

Я бы сказал, что «Kubernetes экспоненциально усложняется идеями, которые он изобретает для себя».

Я работал с Кластерный менеджер Borg на протяжении многих лет и Kubernetes вдохновлен Боргом. Я могу написать об этом опыте, но позвольте мне сначала обратиться к изображениям, твитам и опыту других.

Образы и чувства

Вот некоторые визуальные свидетельства и «ощущения» по поводу этой чрезмерно сложной проблемы в клоду.

«Cloud Native» Computing Foundation поддерживает эту диаграмму экосистема вокруг Kubernetes:

Вот реакции, которые я нашел в Twitter:

это единственная диаграмма, которую я когда-либо видел видно, что это более сложный ландшафт, чем базовый ландшафт облачных вычислений. https://t.co/G6CcTcRCi3

– Иммунитет к ботаникам (@monkchips) Январь 2002, 2020

и Hacker News:

Для меня весь этот образ представляет собой большую проблему современной разработки программного обеспечения: https://twitter.com/dankohn1/status/ 1215647625451646977

Индустрия полна инженеры, которые являются экспертами в «технологиях» (которые на самом деле являются просто продуктами и библиотеками), но не имеют представления о том, как работают фактические технологии (например, TCP / IP, файловые системы, иерархия памяти и т. д.). Я не знаю, что и думать, когда встречаю инженеров, которые знают, как настроить ELB на AWS, но не совсем понимают, что такое сокет …

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

Чтобы повторить утверждение: распределенная ОС, которая следует Принципу Перлиса-Томпсона будет иметь меньше понятий . Было бы проще использовать и легче создавать программное обеспечение. Схема была бы меньше и понятнее!

Предлагаю мем Кен Томпсон vs Kubernetes , чтобы помнить об этом. Кен Томпсон разработал бы что-то более простое и долговечное.

Kubernetes непродуктивен

В последнем разделе были некоторые “чувства” по поводу сложности, а не веские аргументы.

Сообщение ниже дает намного больше деталей. Наряду с сообщением в следующем разделе о бессерверной производительности он вдохновил меня на написание с тегом # комментарии и # архитектура программного обеспечения ранее в этом году.

MetalLB научил меня, что невозможно создать надежное программное обеспечение, которое интегрируется с Kubernetes.

GKE SRE научил меня, что даже самые передовые эксперты Kubernetes не могут безопасно управлять Kubernetes. в масштабе.

Это проклятие из-за авторской непосредственный опыт.

Моя первоначальная реакция заключается в том, что Unix-y модель автономных процессов, файловая система с адресной адресацией (нечто среднее между git и BitTorrent) и именованные порты будут будь проще. Авторизация и безопасность – огромные проблемы, и они свели на нет мои предыдущие усилия в этом направлении.

Но это еще не полностью сформированные мысли; сообщение в блоге более конкретное.

Бессерверная работа непродуктивна

Непродуктивен не только Kubernetes. В этой статье описываются проблемы производительности при использовании бессерверных приложений (например, AWS Lambda).

и

Резюме:

Кто-нибудь в 2021 сожалею, что не проводил больше времени с OLEDB, не говоря уже о том, что знаете, что это такое?

Точно так же, я думаю, Kubernetes будет надолго забыт в . Он будет заменен более простыми системами, которые следуют Принципу Перлиса-Томпсона .

Больше мудрости от Джоэла:

Посмотрите внимательно на программный ландшафт. Компании, которые преуспевают, меньше всего полагаются на крупные компании и не должны тратить все свои циклы на то, чтобы наверстать упущенное, переопределить и исправить ошибки, которые возникают только в Windows XP.

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

Еще # темы блога

Классические сообщения в блоге Джоэла Спольски . Ссылка на сообщение Джоэла Fire and Motion напоминает мне, что его блог и форум были неоценимы в начале моей карьеры. В этом посте будут цитироваться более проницательные посты Джоэла.

Влияние Рича Хикки . После этот недавний комментарий о динамических языках и «мире», Ци Сяо из Эльфийский напомнил мне, что Рич Хикки использует термин “ расположенные программы “.

Я не поверил Хики в этом комментарии, но его идеи определенно повлияли на меня. Я хочу написать еще один пост, посвященный его идеям о языковом дизайне и системах . Я бы сослался на этот комментарий к его докладу “Может быть, нет” .

Нефть – это во многом язык для программ, расположенных в “мире” .

Вывод

Я надеюсь обратиться к этому посту в будущем. Ссылки и комментарии предназначены для добавления цвета в дизайн Нефтяной язык и мотивация проекта в целом.

Дайте мне знать , было ли это интересно или полезно!

Завтра я рассмотрю другие сообщения и комментарии о # распределенные системы. Я ожидал написать один Бэклог блога сообщение , но он превратился в три !

Если вы еще не читал, посмотрите вчерашний пост о понимании и использовании оболочки .

Leave a comment

Your email address will not be published. Required fields are marked *