Kubernetes на пальцах: как устроена оркестрация

Kubernetes годами подавали как высшую математику: куча компонентов, схемы как карта метро большого города. Но в основе лежит одна простая идея, и когда ты её ловишь, всё остальное встаёт на места само.

Забудь про кубер на минуту. Представь огромный склад Amazon. Тысячи заказов в день, на полу работают роботы: берут товары, пакуют коробки, отправляют посылки. Ты не командуешь каждым роботом вручную, это безумие при таких объёмах. Ты просто говоришь системе: держи на полу пять упаковочных роботов постоянно. Один сломался, поднимут замену. Отвалилась целая зона, роботов перекинут в другую. Ты задал желаемое состояние, а система бесконечно приводит к нему реальность. Вот это и есть Kubernetes.

Работает это как круиз-контроль в машине. Выставил 110 км/ч, пошёл в горку и скорость упала, система добавляет газу. Покатился под уклон и разогнался, притормаживает. Ты задал цель один раз, дальше кластер сам её удерживает. Ты не пишешь скрипты, которые вручную стартуют контейнеры и перезапускают их после падения, ты пишешь конфиг с желаемым состоянием и отдаёшь его кластеру.

Теперь роли на складе. kube-apiserver это ресепшен, единственная точка входа: любая команда и любой статус идут сначала через него, и он же проверяет, кто ты и что тебе разрешено. etcd это база склада, единый источник правды, и напрямую с ней говорит только apiserver. kube-controller-manager это менеджер зала, он крутит цикл наблюдай, сравнивай, действуй: сказал пять роботов, а работают четыре, создаёт ещё одного. kube-scheduler это распределитель зон, он подбирает бездомному поду лучшую ноду по ресурсам. kubelet это супервайзер зоны, он поднимает робота через рантайм, следит за здоровьем и перезапускает при падении. kube-proxy это маршрутизатор, он держит правила и раздаёт трафик живым подам. Container Runtime качает образ и запускает контейнер. Pod это сам робот, он временный: упал, кубер его не чинит, а поднимает новый.

Важно не путать управление кластером и маршрутизацию трафика. Связка apiserver, etcd, scheduler и контроллеры отвечает за состояние кластера. Пользовательские запросы через них не ходят, реальный трафик течёт через Сервис, Ingress или балансировщик к нужному поду. У подов постоянно меняются IP, поэтому клиент ходит на Сервис с постоянным адресом, а метки, селекторы и EndpointSlices следят за тем, к каким живым роботам слать заказы. EndpointSlices режут громадный список адресов на маленькие листки, чтобы при падении одного пода не рассылать всю таблицу на каждую ноду.

Сейчас самая горячая тема индустрии это инфраструктура для LLM, и продакшн-инференс больших моделей стоит ровно на таких оркестраторах. Автор оригинального разбора полез в кубер настолько глубоко именно потому, что копал масштабирование LLM-инференса вместе с командой llm-d.

Оригинальный разбор с диаграммами: https://x.com/jaga_prasanna/status/2079614504451838426