Kubernetes уже давно стал стандартом в мире оркестрации контейнеров, но несмотря на свой огромный функционал и широкую популярность, он остаётся сложной, многослойной и, порой, непредсказуемой системой. Создатели и операторы часто сталкиваются с проблемами в эксплуатации, поддержке и масштабировании, что заставляет специалистов задумываться: а что если начать с чистого листа и создать более простой, понятный и при этом мощный Kubernetes? Идеи и размышления на эту тему, которые озвучил Дэвид Андерсон в 2020 году, проливают свет на пути к улучшению архитектуры контейнерных оркестраторов и могут стать отправной точкой для новых проектов и переосмысления существующих практик. Опыт эксплуатации и разработки Дэвид Андерсон, опираясь на свой опыт создания MetalLB — системы балансировки нагрузки для bare metal-кластеров, а также работы в команде Google GKE SRE, выделяет главные вызовы, с которыми сталкиваются как разработчики Kubernetes, так и крупные операционные команды. Основной проблемой остаётся комплексность и запутанность, из-за которой большинство пользователей не готовы к реальной эксплуатации, и даже эксперты вынуждены тратить много времени и сил на диагностику и устранение проблем. Образно Kubernetes сравнивается с языком C++ — мощным, широко функциональным, но при этом сложным и требующим глубокого погружения.
В противовес этому предлагается представить себе Kubernetes нового поколения как Go среди систем оркестрации — простую, агрессивно упрощённую и достаточно чётко ориентированную систему, которую можно изучить очень быстро и, главное, успешно использовать. Мутируемые поды для более гибкой работы Одной из ключевых идей является отказ от традиционной иммутабельности подов в Kubernetes. В классической модели изменение пода требует его удаления и создания нового, что не всегда эффективно и усложняет операционные задачи. Представляется идея сделать ресурсы подов полностью изменяемыми и управляемыми как обычные объекты API, что позволит выполнять рестарты и обновления без необходимости разрушать контейнер и создавать его заново. Такой подход стирает грань между временем жизни пода и жизненным циклом контейнера, превращая новую систему в более привычную для администраторов среду с гибкой и прозрачной обработкой изменений.
Кроме того, это даёт почву для внедрения системы управления версиями конфигураций подов с возможностью легко откатиться к предыдущей стабильной версии, что значительно упрощает управление состоянием и время реакции на ошибки. Важным аспектом является сохранение истории изменений в самом кластере — это избавляет от необходимости пользоваться внешними инструментами GitOps для ответа на вопрос "что изменилось?" и позволяет проводить локальную диагностику текущих и прошлых состояний. Изобретение «PinnedDeployment» — эффективный способ контролировать развертывания Идея внедрить тип ресурса PinnedDeployment была подчерпнута из практик опытных SRE инженеров. Он по сути даёт оператору возможность одновременно отслеживать две версии развертывания, что позволяет более чётко и управляемо контролировать процесс обновлений и валидации кластерного состояния. Комбинация этого подхода с возможностью mutability подов и версионного управления предоставляет гораздо более гибкий и надёжный механизм, который устраняет многие проблемы, связные с развертыванием многоподовых приложений.
Явные оркестрационные рабочие процессы вместо «рассредоточенных циклов контроля» Высокая модульность и большое количество отдельных контроллеров в современном Kubernetes – одна из причин сложности отладки, ведь система не умеет явно сигнализировать о том, сработал ли контроллер успешно, или же процесс застопорился из-за зависимостей или ошибок. Дэвид Андерсон предлагает уподобить процесс оркестрации системе init, например systemd, где жизненный цикл объектов представлен в виде цепочки задач с определёнными зависимостями, порядком запуска и завершения. Такой подход даёт и чёткое понимание, какие шаги выполнены, какие всё ещё обрабатываются, а какие завершились с ошибкой, позволяя точно локализовать причину сбоев и упрощая отладку. Это также открывает возможности для параллелизации операций, но при этом сохраняется контроль за порядком и условиями запуска, что делает жизненный цикл приложений более предсказуемым и расширяемым. Чёткое владение полями объектов кластерной конфигурации Одной из причин постоянной борьбы контроллеров друг с другом является неявное распределение ответственности за управляющие поля объектов.
В предлагаемой модели владение каждым полем прописывается явно и закрепляется за конкретным контроллером, что исключает конкуренцию и постоянные конфликты при записи. Подобный контроль, усиленный проверками на уровне API, позволит исключить «битвы контроллеров» вроде тех, что наблюдаются в MetalLB. Это также станет основой для формальных гарантий сходимости системы — ведь каждый контроллер знает, какие поля ему разрешено менять, и может анализировать влияние своих действий на состояние других компонентов. Смена парадигмы сетей: IPv6 для упрощения и безопасности В презентации проекта предлагается полностью отказаться от архитектуры сетевого стека Kubernetes с её наложениями, прокси, CNI и прочими сложными слоями во имя более простой и понятной модели, основанной на чистом IPv6. Каждый под получает уникальный адрес из большого адресного пространства, что практически исключает коллизии и упрощает маршрутизацию.
Внутрикластерное взаимодействие происходит через базовую IP-маршрутизацию, избавляя от необходимости сложных плагинов и оверлеев. Для доступа в интернет IPv4 продвигается только на уровне выходящего трафика с использованием masquerading и NAT64/CLAT при необходимости. Такой подход резко снижает сложность сетевой части, повышает её прозрачность и облегчает диагностику, в то время как нагрузка на координатор и нагрузочные сетевые компоненты уменьшается. В то же время остальное сетевое окружение остаётся открытым для интеграции через отдельные load-balancer'ы, что позволяет гибко настраивать балансировку и доступность. Максимальная безопасность по умолчанию Новый Kubernetes ориентируется на сильную изоляцию и минимализм в правах.
Взяты лучшие практики реального контейнерного сандбокса: акции по отключению root-доступа, включению профилей seccomp и AppArmor, применению namespace-моделей изоляции пользователей. Всё это должно быть стандартом по умолчанию со сложными и явными явками для ослабления механизмов безопасности. Данный подход резко сокращает риски эксплуатации уязвимостей в контейнерах и делает системы более упорядоченными для аудиторов и операторов. Рассмотрение возможности использования Firecracker и gVisor Поднимается тема применения специализированных легковесных виртуальных машин и сандбоксов вроде Firecracker или gVisor в качестве основного механизма запуска приложений. Их преимущества в повышенной безопасности очевидны, однако есть и значительные сложности: ограниченный функционал, увеличение сложности системы и потенциальные компромиссы производительности.
Поэтому будет разумным использовать такие технологии в опциональном режиме, позволяя пользователям выбирать уровень изоляции и функциональности по потребностям. Фокус на «очень распределённые» кластеры и edge-компьютинг Другая важная идея — создание системы, способной объединять самые разные узлы с разным уровнем доступности и надёжности в одну единую управляемую структуру. Узлы могут быть как в локальной сети, так и разбросаны по всему миру, одно целое управляется из одного «мозга» с максимально автономным поведением узлов. Это требует отхода от полной зависимости от централизованного контроллера и значительного усиления возможности автономной работы и кэширования данных на стороне нод. Допускается возможность разделения по типу подов на «с высокой доступностью», требующих немедленного восстановления, и «лучшим усилием», когда восстановление производится только при полной уверенности в потере узла.
Интеграция виртуальных машин как базовых единиц Важным требованием является возможность работы с виртуальными машинами наравне с контейнерами внутри единой экосистемы, без необходимости одновременно запускать и управлять отдельной инфраструктурой гипервизоров и оркестраторов. Это позволит значительно расширить кейсы применения системы, охватывая не только контейнерные приложения, но и традиционные VM-решения. Поддержка таких гипотез требует глубокой интеграции и пересмотра подходов управления ресурсами и жизненным циклом виртуальных машин и контейнеров. Хранение и управление данными как «не до конца решённая задача» В области работы со стореджем автор признаёт недостаточную разработанность своих представлений и предлагает держать эту часть максимально открытой и расширяемой, чтобы в дальнейшем уже на базе практического опыта улучшать и адаптировать решение. Заключение Перечисленные идеи и подходы — это попытка взглянуть на вопрос оркестрации контейнеров заново, отвергнуть тяжеловесность и непредсказуемость существующих систем и уйти к модели, которую можно освоить быстро, в которой просто отлаживать проблемы и которую безопасно эксплуатировать в самых разных средах, от локальных серверов до глобально распределённых кластеров.
Несмотря на масштабные перемены и рискованные новшества, подход, основанный на чётком разграничении ответственности, упрощении сетевых моделей и сильной безопасности, имеет все шансы стать новым ориентиром для будущих систем оркестрации, вдохновляя разработчиков и операторов на создание лучших инструментов для управления современными инфраструктурами.
