Комментарии 13
Яндекс опять делает всё на свой лад, ведь знает всё лучше всех. Мне кажется лучше это останется у Вас в яндексе
Господи, Яндекс и его ...ные велописеды наносят очередной удар по здравому смыслу.
Я уже не в первый раз вижу когда большая компания делает что то, на что я смотрю и недоумеваю «зачем».
Одни например изобрели кубернетис для crd, контроллеры к которому депоятся «снаружи». :)
Вопрос к автору - можете пожалуйста в 3х булетах описать почему вы выбрали путь написать что то свое вместо того чтобы адаптировать существующие решения например crossplane? Как будто такой подход мог быть дешевле и быстрее.
Попробую ответить не буллетами, но по пунктам :)
Я уже не в первый раз вижу когда большая компания делает что то, на что я смотрю и недоумеваю «зачем».
Разумеется, большие компании это делают не от большой скуки. Основные причины бывают две: «стандартное» решение либо где-то жмёт, либо дороже. В нашем случае и то, и другое.
Одни например изобрели кубернетис для crd, контроллеры к которому депоятся «снаружи»
Вообще в контексте описываемой в посте архитектуры абсолютно неважно, где поднимать контроллеры. <дальше лирическое отступление не в тему поста, но раз уж коллега спрашивает, разверну подробнее> Если бы у нас для поднятия контейнеров использовался честный кубер с его kubelet'ами и всем прочим, то мы могли бы запустить контроллеры и там, никаких архитектурных ограничений нет. Но мы используем своё облако со своими примитивами контейнеров. Почему? По многим причинам. Одна из самых простых и очевидных — это то что максимальное количество нод, которое удалось людям в мире держать в одном kubernetes-кластере, составляет емнип примерно 30к. Потом кубер складывается. У нас это немного другие порядки. Это в том числе пример того, где большим компаниям «жмёт». Чтобы не сталкиваться с этой проблемой, в менее крупных компаниях в том числе принято каждой команде поднимать свой отдельный кубер, самостоятельно его администрировать и резвиться в нём как захочется. Это приводит к намного более сильной фрагментации и недоутилизации железа, увеличению накладных расходов на сам кубер, увеличению расходов на SRE (каждой команде надо иметь своих), т.е. это просто дорого. На наших объёмах — очень значительно.
вместо того чтобы адаптировать существующие решения например crossplane? Как будто такой подход мог быть дешевле и быстрее.
Чтобы меня потом не обвиняли, я сразу оговорюсь, что crossplane — отличная концепция, и как я и говорил в посте, во многих случаях она прекрасно подойдёт :) Сам crossplane состоит по сути из двух частей:
Providers. Они скрываются под общим зонтиком crossplane, но на самом деле по сути это фреймворк для кодогенерации и написания самодостаточных контроллеров, такой же, например, как kubebuilder. Мы использовали контроллер upjet для управления теми нашими элементами инфраструктуры, которые используют терраформ, и он нормально вписывается в нашу общую структуру. Вместе с тем основная сила crossplane тут заключается в реестре уже существующих провайдеров, а в нашем случае это не даёт профита. Для написания собственных контроллеров мы смотрели и на crossplane, и на kubebuilder, и пришли к выводу, что их добавочная польза поверх стандартного controller-runtime не очень высока и проще написать небольшую аналогичную кодогенерацию, которая будет хорошо вписываться в нашу систему сборки вместо Makefile. Там действительно на стороне провайдеров не очень много всего, это не так, что мы тут писали монструозный велосипед :)
Compositions и Claims. Это как раз кмк основная суть crossplane, обработку которой вы устанавливаете, когда устанавливаете себе crossplane в кластер. Идея хорошая, но тут они в позиции догоняющих: раньше это были сугубо статические шаблоны с простыми подстановками, которые позволяют из набора параметров срендерить несколько простых hard mode (в наших терминах) спек, где остальные параметры уже проставлены. А что, если надо что-то сложнее? Если количество создаваемых hard mode спек зависит от количества переданных параметров (например, передали список зон доступности, в которых надо развернуть копии приложение) или в срендеренной спеке надо вычислять значение параметра как сумму трёх других параметров? Поддержку composition functions в crossplane зарелизили только в конце августа. Поэтому честный ответ тут такой: если бы мы дизайнили и писали свои easy mode контроллеры сейчас, мы бы намного более пристально смотрели на crossplane, но так получилось, что мы тут уже всё написали раньше и (имхо) во многом пока ещё лучше.
И ещё дополнительно тут на всякий случай скажу, что в целом crossplane не противопоставляется всем тезисам, о которых я пишу в этой статье (скорее пересекается: они точно так же требуют блюсти обратную совместимость, например). Можно с тем же успехом реализовывать всё перечисленное и поверх crossplane.
Спасибо!
Я до сих пор считаю что добавить нужные фичи в опенсорс (там где это технически возможно) лучше чем пилить свое с нуля, но позиция редакции понятна и принимается. :)
максимальное количество нод, которое удалось людям в мире держать в одном kubernetes-кластере, составляет емнип примерно 30к. Потом кубер складывается. У нас это немного другие порядки. Это в том числе пример того, где большим компаниям «жмёт».
Было бы интересно узнать, как эту проблему решают, например, в Google :)
Google внутри себя тоже использует не кубер, а своё проприетарное облако Google Borg: https://research.google/pubs/pub43438/
Это в том числе пример того, где большим компаниям «жмёт». Чтобы не сталкиваться с этой проблемой, в менее крупных компаниях в том числе принято каждой команде поднимать свой отдельный кубер, самостоятельно его администрировать и резвиться в нём как захочется. Это приводит к намного более сильной фрагментации и недоутилизации железа, увеличению накладных расходов на сам кубер, увеличению расходов на SRE (каждой команде надо иметь своих), т.е. это просто дорого. На наших объёмах — очень значительно.
Было бы интересно почитать про риск-менеджмент в "крупных" компаниях. С одной стороны, если у каждой команды свой кубер/свои SRE, то это, по идее, было бы более надежно (не должно падать одновременно, а падения/деградации, все-таки, неизбежны). С другой стороны, если упадет инфра даже у одной команды, то с учетом взаимозависимостей между сервисами внутри крупной компании, все равно будет плохо всем. В общем, если есть какие-то цифры с оценками вероятности и моделями, которые бы показывали что в итоге надежнее / выгоднее в таком масштабе - можете поделиться?
Ох, этот рассказ тянет на отдельный доклад. Если вкратце, то мы решаем эту проблему немного иначе. Инфраструктура одна, но мы стараемся избегать единых точек отказа, без которых всё ляжет.
Делаем инфраструктуру достаточно устойчивой к отказам. Начинаем с датацентров и учений. Каждый элемент должен быть по возможности максимально автономным и устойчивым к отказам других компонентов и систем. Стажёрам я обычно это описываю как то, что вы должны писать микросервис так, чтобы он работал как та собачка.
Та собачка
Проектируем компоненты работать в рамках заданных датацентров / зон доступности (пересекается с учениями).
Там, где не можем или не хотим делать систему полокационной, она не должна быть единой точкой отказа и система должна позволять т.н. факапный режим работы. Например, если вдруг откажет git-репозиторий или CI/CD (условный Argo CD), пользователь должен иметь возможность пойти и поправить спеку напрямую в кубере. Если откажет описываемый в статье кубер (его кросслокационная инсталляция, которая в том числе позволяет описать, как размазывать сервис по нескольким локациям), то пользователь имеет возможность опять-таки пойти напрямую в конечную систему и что-то починить/поменять там напрямую. При этом мы должны думать и о восстановлении после сбоя: если пользователь что-то починил руками, то проснувшийся CI/CD не должен молча перетереть спеки каким-то новым коммитом, а должен максимально орать «эй, я вижу ручные изменения, которых нет в коде!»
Ну и остальное в таком же духе. Таким образом, мы не переходим к ситуации «если сломается наша единая инфра, то положим весь Яндекс» — у нас достаточно изоляции и резервирования, несмотря на уменьшение гранулярности.
Как мы нарушили все гайдлайны Kubernetes, чтобы описывать инфраструктуру в разы быстрее