Этот цикл статей стал результатом попытки посмотреть на Kubernetes как на ядро Linux: что, если K8s будет аналогом Linux Kernel и инженеры начнут работать не с ванильным Kubernetes, а с готовыми дистрибутивами, не отвлекаясь на настройку и подгонку компонентов. Именно вокруг этой мысли и возникли эти материалы.
Осенью 2023 года на KubeCon в Чикаго Тим Хокин, один из тех, кто стоял у истоков Kubernetes, говорил со сцены о том, что Kubernetes становится сложнее с каждым релизом, и эта сложность не бесплатна, потому что каждая новая фича, нужная лишь кому‑то одному, ложится грузом на всех остальных; разработчики проекта всё хуже удерживают в голове всё целиком, а инженерам, которые его эксплуатируют, всё труднее разобраться во всех его настройках. Хокин предложил относиться к сложности как к бюджету, который у проекта есть и который можно потратить, но только один раз, а значит, надо научиться отказываться от того, что этот бюджет съест без достаточной пользы.
Меня эта мысль зацепила, потому что мне показалось, что у неё есть продолжение, о котором со сцены сказано не было. Если сложность, нужная машинному обучению, сетевым устройствам или промышленным контроллерам, не помещается в бюджет ядра проекта, то ей всё равно нужно какое‑то место, где она будет жить, никого не обременяя. В мире Linux такое место давно нашлось. Ядро там остаётся ядром, которое знают и трогают руками немногие, а вся специфика уходит в дистрибутивы, и никто не ждёт от Торвальдса, что он лично позаботится о роутерах, медицинских томографах и игровых консолях.
