По мере роста популярности Kubernetes фокус обсуждений сместился с простого запуска контейнеров на управление все более сложными жизненными циклами приложений. Современные платформы поддерживают stateless-веб-сервисы, stateful-базы данных, пакетную обработку, рабочие нагрузки ИИ и платформенные сервисы. При этом они должны оставаться надежными во время обновлений, событий масштабирования и сбоев инфраструктуры.
Каждый пользователь Kubernetes полагается на SIG Apps, осознает он это или нет. Deployments, StatefulSets, DaemonSets, Jobs и CronJobs составляют основу того, как приложения развертываются, обновляются, масштабируются и эксплуатируются в экосистеме Kubernetes.
SIG Apps фокусируется на повышении устойчивости рабочих нагрузок, совершенствовании управления жизненным циклом приложений и решении операционных задач, возникающих при сбоях узлов, нарушениях процесса развертывания и в условиях все более сложной инфраструктуры.
В этом выпуске мы беседуем с двумя из трех руководителей SIG Apps, Джанет Куо и Мацеем Шуликом, чтобы обсудить эволюцию управления рабочими нагрузками в Kubernetes, проблемы баланса между надежностью приложений и простотой эксплуатации, а также будущее управления жизненным циклом приложений в рамках одной из самых влиятельных групп по интересам (SIG) в Kubernetes.
Представляем SIG Apps
Натали Фишер: Можете ли вы представиться, рассказать о своей роли и о том, как вы начали участвовать в работе SIG Apps?
Джанет Куо: Я старший штатный инженер-программист в Google и являюсь мейнтейнером Kubernetes с 2015 года, присоединившись к сообществу как раз в тот момент, когда мы стремились к запуску версии 1.0. В те первые дни я была сосредоточена на создании ядра Workloads API, в частности, на разработке контроллеров, таких как Deployment, ReplicaSet, StatefulSet и DaemonSet, определении их поведения при развертывании и доведении их от первоначальных проектов до статуса GA. Эта практическая работа стала моей отправной точкой в SIG Apps.
С тех пор я глубоко вовлечена как в техническую, так и в общественную жизнь Kubernetes. Я возглавляю SIG Apps в качестве сопредседателя и технического руководителя с 2019 года. В настоящее время, помимо поддержки workloads API, я занимаюсь развитием новых подпроектов, таких как Agent Sandbox, чтобы гарантировать готовность Kubernetes к рабочим нагрузкам нового поколения, связанным с агентами и ИИ.
Мацей Шулик: Я начал вносить свой вклад в Kubernetes еще в 2014 году. С тех пор я работал в различных областях проекта: контроллеры, kubectl и apimachinery, что в конечном итоге привело меня к должности одного из председателей и технических руководителей SIG Apps. Мой текущий фокус — надежность контроллеров рабочих нагрузок под эгидой SIG Apps, а также стабильность и простота использования kubectl в рамках моей роли технического руководителя SIG CLI. Я также забочусь об общем состоянии и развитии сообщества в рамках своей роли в Руководящем комитете. Помимо Kubernetes, я работаю штатным инженером по платформе в Defense Unicorns, где помогаю сделать Kubernetes более приспособленным к работе в изолированных сетях (airgap) с помощью проекта под названием zarf.
Проблема и решение
SIG Apps отвечает за основные API рабочих нагрузок, которые определяют, как приложения работают в Kubernetes. От Deployments и StatefulSets до Jobs и CronJobs — эти контроллеры определяют, как рабочие нагрузки создаются, обновляются, масштабируются и восстанавливаются в случае возникновения проблем.
По мере того как Kubernetes расширяется для поддержки все более разнообразных рабочих нагрузок, включая ИИ, пакетную обработку и крупномасштабные распределенные приложения, SIG Apps продолжает развивать эти API, балансируя между надежностью, обратной совместимостью и простотой эксплуатации.
НФ: Для читателей, которые, возможно, не знакомы с этим, что такое SIG Apps и какую роль она играет в более широкой экосистеме Kubernetes?
МШ: SIG Apps — это группа по интересам Kubernetes, отвечающая за API рабочих нагрузок. CronJob и Job помогают запускать пакетные задачи, в то время как DaemonSet, Deployment, ReplicaSet и StatefulSet обслуживают большинство других приложений. В более широком смысле, SIG Apps владеет уровнем, с которым большинство разработчиков сталкиваются ежедневно: контроллерами, которые превращают спецификацию рабочей нагрузки в работающие, самовосстанавливающиеся поды. Это группа, которая решает, как развертываются Deployments, как Jobs повторяют попытки, как DaemonSets размещают под на каждом узле.
ДЖК: Дополняя то, что описал Мацей, по мере изменения отрасли мы видим огромный спрос на запуск сложных, нетрадиционных рабочих нагрузок, таких как распределенное обучение ИИ, пакетные вычисления и динамические агентские среды. Наша роль расширяется: мы не просто поддерживаем классический workloads API, мы активно развиваем его и создаем новые шаблоны (например, Agent Sandbox), чтобы гарантировать, что Kubernetes остается лучшей платформой для рабочих нагрузок следующего поколения, таких как ИИ.
НФ: Глядя на API рабочих нагрузок, которыми владеет SIG Apps (Deployments, StatefulSets, DaemonSets, Jobs и CronJobs), какие области получают наибольшее внимание со стороны мейнтейнеров и участников?
МШ: После длительного периода, сосредоточенного на том, чтобы пакетные рабочие нагрузки бесперебойно работали в Kubernetes, мы переключили внимание на то, чтобы сервисные рабочие нагрузки (DaemonSets, StatefulSets и т. д.) не остались без внимания. Это означает повышение производительности и масштабируемости поведения при развертывании и масштабировании, а также работу с нашим бэклогом проблем, о которых сообщают пользователи, приоритизируя те, которые имеют наибольшую поддержку со стороны пользовательской базы.
Текущие области внимания
По мере того как рабочие нагрузки Kubernetes растут в масштабе и сложности, проблемы, с которыми сталкиваются контроллеры рабочих нагрузок, также эволюционируют. Мы спросили председателей SIG Apps, на чем сегодня сосредоточены усилия участников и какие проблемы устойчивости они считают наиболее приоритетными.
НФ: С вашей точки зрения, какие наиболее важные проблемы устойчивости рабочих нагрузок SIG Apps пытается решить сегодня?
МШ: Проблемы жизненного цикла узлов неоднократно возникали в дискуссиях SIG Apps, SIG Node и SIG Autoscaling. DaemonSets и Jobs — это те области, где боль наиболее заметна, поскольку они наиболее тесно связаны с состоянием узла. Вместо того чтобы решать это по частям в рамках одной SIG, мы решили создать специальную рабочую группу по жизненному циклу узлов (Node Lifecycle Working Group), чтобы должным образом сосредоточиться на этом и, надеюсь, найти долгосрочные решения вместо разовых исправлений.
ДЖК: С точки зрения ИИ устойчивость критически важна. Когда вы запускаете масштабную распределенную задачу обучения LLM, охватывающую сотни графических процессоров, один сбой узла может остановить весь конвейер. Аналогично, если DaemonSet, который запускает ваш агент логирования или мониторинга GPU, застревает на неисправном узле, это влияет на здоровье всего кластера.
В дополнение к работе в рабочей группе по жизненному циклу узлов для устранения деградации на уровне инфраструктуры, SIG Apps решает эту проблему на уровне оркестрации с помощью подпроектов, таких как JobSet (для распределенного обучения) и LeaderWorkerSet (LWS) (для шардированного вывода LLM). Эти API вводят такие шаблоны, как обработка сбоев «все или ничего», где сбой одного пода или задачи инициирует скоординированный перезапуск на уровне группы для возобновления работы с последней чистой контрольной точки, вместо того чтобы позволять зависшим рабочим нагрузкам оставаться в несогласованном состоянии.
Реальное влияние
Работа, проводимая в рамках SIG Apps, выходит далеко за рамки реализации контроллеров и проектирования API. Мы хотели понять, что эти улучшения означают на практике для платформенных команд, эксплуатирующих кластеры Kubernetes в промышленной среде.
NF: Какие практические улучшения заметят платформенные команды, эксплуатирующие Kubernetes в продакшене, если текущие обсуждения по жизненному циклу узлов и устойчивости рабочих нагрузок будут успешно реализованы?
MS: Я в основном наблюдаю со стороны, люди из рабочей группы Node Lifecycle Working Group дали бы вам более точный ответ. Но с моей точки зрения, я надеюсь, что их работа приведет к сокращению количества ночных вызовов (пейджеров), которые заканчиваются тем, что «развертывание DaemonSet зависло, потому что узел X был нестабилен, и кому-то пришлось вручную выполнять cordon/delete/restart, чтобы сдвинуть дело с мертвой точки».
JK: Полностью согласен с Мацеем. Помимо сокращения ручного вмешательства, платформенные команды также увидят гораздо лучшую предсказуемость ресурсов и экономическую эффективность. Например, в задачах ИИ, где время простоя GPU стоит очень дорого, автоматическое обнаружение Kubernetes деградировавшего узла и перепланирование координатора обучения или агента до того, как задание завершится с ошибкой, означает меньше потраченных вычислительных ресурсов и более стабильное выполнение заданий.
Проблемы и компромиссы
Развитие API, от которых зависят миллионы рабочих нагрузок, требует тщательного проектирования и еще более осторожного принятия решений. Мы спросили руководителей SIG Apps о технических и операционных компромиссах, которые они учитывают при внесении изменений в основные контроллеры рабочих нагрузок Kubernetes.
NF: С какими самыми сложными техническими или операционными компромиссами сталкивается SIG Apps при развитии основных контроллеров рабочих нагрузок?
MS: Честно говоря, постоянно возникают несколько противоречий: насколько агрессивно контроллер должен отказываться от зависших подов и какие сигналы ему на самом деле нужны, чтобы принять такое решение правильно. В то же время мы всегда должны думать об обратной совместимости. Поведение Deployment, DaemonSet и Job используется уже десять лет [пользователями Kubernetes, инструментами, автоматизацией и контроллерами более высокого уровня], поэтому даже изменение, которое явно является «более правильным», может непреднамеренно сломать автоматизацию, которую люди выстроили вокруг старого поведения.
JK: Один из наших самых сложных компромиссов — это сопротивление желанию внести «элегантные» изменения в дизайн, которые нарушают обратную совместимость. Вместо этого мы должны проектировать функции с возможностью выбора (opt-in), которые позволяют пользователям использовать новое поведение, не навязывая его устаревшим рабочим нагрузкам. Когда нам нужно поддерживать совершенно новые парадигмы, мы предпочитаем сначала внедрять их как CRD, а не раздувать основные API, как мы делаем это с Agent Sandbox, JobSet и LWS.
Взгляд в будущее
Хотя большая часть работы SIG Apps сосредоточена на поддержании стабильности существующих API рабочих нагрузок, группа также формирует будущее Kubernetes с помощью новых улучшений и предложений. Мы завершили беседу вопросом об одном предложении, которое недавно вернулось к активной разработке, и о том, что оно означает для будущего управления рабочими нагрузками.
NF: SIG недавно обсудила возобновление KEP-4443 с целевым релизом Kubernetes 1.38. Какие возможности или проблемы призвано решить это предложение и почему сейчас самое время вернуться к нему?
KEP-4443 устраняет небольшой, но реальный пробел в Job API: PodFailurePolicy можно настроить так, чтобы добавить причину условия к состоянию JobFailed, но разные правила политики сбоев подов, нацеленные на разные коды выхода контейнеров, создают одну и ту же общую причину. Предложение простое: добавить необязательное поле Name в каждое правило PodFailurePolicyRule, которое будет добавляться к причине условия JobFailed, чтобы инструменты более высокого уровня, такие как JobSet, могли наконец реагировать по-разному в зависимости от того, какое правило вызвало сбой.
Что касается сроков, ответ так же прост, как и всегда в open source: мы потеряли первоначального участника, который продвигал это. Теперь у нас есть кто-то новый, заинтересованный в том, чтобы взяться за это, поэтому мы ориентируемся на следующий релиз.
Как принять участие
NF: Что бы вы порекомендовали человеку, заинтересованному в участии в SIG Apps, особенно если он еще не является мейнтейнером Kubernetes?
MS: Лучшее место для начала — это Slack-канал #sig-apps и наши регулярные встречи SIG Apps. Мы все начинали оттуда, и если это кажется пугающим или никто не отвечает сразу, это совершенно нормально. Все заняты. Это не личное.
JK: В дополнение к тому, что ответил Мацей, я бы посоветовал взглянуть на наши новые подпроекты и инициативы. Вклад в стабильные API, такие как Deployment или StatefulSet, может быть пугающим, потому что барьер для внесения изменений очень высок из-за обратной совместимости, и там гораздо меньше простых задач.
Если вы новичок в сообществе, такие проекты, как Agent Sandbox, являются фантастическими точками входа. Они активно развиваются, имеют дружелюбную группу мейнтейнеров и предлагают множество возможностей для разработки с нуля, где вы можете быстро оказать значительное влияние.
Резюме
SIG Apps формирует способы развертывания и эксплуатации приложений в Kubernetes с самых первых дней проекта. Хотя пользователи часто взаимодействуют с Deployments, StatefulSets, Jobs и DaemonSets, не задумываясь о контроллерах, стоящих за ними, работа внутри SIG Apps продолжает определять надежность и масштабируемость рабочих нагрузок во всей экосистеме Kubernetes.
От улучшения устойчивости рабочих нагрузок и поведения жизненного цикла узлов до внедрения новых паттернов для ИИ и распределенных вычислений, SIG развивает Kubernetes, оставаясь приверженной одному из основных принципов проекта: сохранению стабильности и обратной совместимости, от которых зависят пользователи. Независимо от того, интересуетесь ли вы основными API рабочих нагрузок, новыми проектами, такими как Agent Sandbox, или помощью в улучшении операционного опыта пользователей Kubernetes повсюду, SIG Apps предлагает множество возможностей для участия.
Это зеркало оригинальной статьи.
