# У фокусі: SIG Apps

LLMS index: [llms.txt](/llms.txt)

---

Зі зростанням впровадження Kubernetes розмова змістилася з простого запуску контейнерів до керування дедалі складнішими життєвими циклами застосунків. Сучасні платформи підтримують вебсервіси без стану, бази даних зі станом, пакетну обробку, AI-навантаження та платформні сервіси. Водночас вони мають залишатися надійними під час оновлень, подій масштабування та збоїв інфраструктури.

Кожен користувач Kubernetes покладається на SIG Apps, усвідомлює він це чи ні. Deployments, StatefulSets, DaemonSets, Jobs та CronJobs є фундаментом того, як застосунки розгортаються, оновлюються, масштабуються та експлуатуються в екосистемі Kubernetes.

SIG Apps зосереджена на підвищенні стійкості навантажень, удосконаленні керування життєвим циклом застосунків та розвʼязанні операційних викликів, які виникають, коли застосунки стикаються з відмовами вузлів, збоями rolloutʼів та дедалі складнішими інфраструктурними середовищами.

У цьому випуску ми поговорили з двома з трьох голів SIG Apps — [**Janet Kuo**](https://github.com/janetkuo) та [**Maciej Szulik**](https://github.com/soltysh) — про еволюцію керування навантаженнями Kubernetes, виклики балансування між надійністю застосунків та операційною простотою, а також про майбутнє керування життєвим циклом застосунків в одній з найвпливовіших Special Interest Group Kubernetes.

## Знайомство з SIG Apps {#introducing-sig-apps}

**Natalie Fisher: Розкажіть про себе, свою роль та як ви потрапили в SIG Apps?**

Janet Kuo: Я старший штатний інженер-програміст у Google і підтримую Kubernetes з 2015 року, приєднавшись до спільноти саме тоді, коли ми мчали до запуску версії 1.0. У ті ранні дні я зосередилася на побудові основного Workloads API, зокрема на розробці контролерів Deployment, ReplicaSet, StatefulSet та DaemonSet, визначенні їхньої поведінки rolloutʼу та доведенні їх від початкових проєктів до GA. Ця практична робота стала моєю точкою входу в SIG Apps.

Відтоді я глибоко залучена як до технічної, так і до спільнотної сторони Kubernetes. Я очолюю SIG Apps як співголова та технічний лідер з 2019 року. Нині, окрім підтримки Workloads API, я веду нові підпроєкти, як-от [Agent Sandbox](https://github.com/kubernetes-sigs/agent-sandbox), щоб Kubernetes був готовий до наступного покоління агентних та AI-навантажень.

Maciej Szulik: Я почав робити внесок у Kubernetes аж [у 2014 році](https://github.com/kubernetes/kubernetes/pull/3065). Відтоді я працював у різних сферах проєкту: контролери, kubectl та apimachinery, що зрештою привело мене до ролі одного з голів і технічних лідерів SIG Apps. Моє поточне завдання — забезпечення надійності контролерів навантажень під егідою SIG Apps, а також стабільність і зручність kubectl у межах моєї ролі технічного лідера SIG CLI. Я також дбаю про загальний стан та зростання спільноти в межах своєї ролі в Steering Committee. Поза Kubernetes я працюю штатним платформним інженером у Defense Unicorns, де допомагаю робити Kubernetes більш airgap-native за допомогою проєкту під назвою [zarf](https://zarf.dev/).

## Проблема та рішення {#the-problem-and-the-solution}

SIG Apps відповідає за основні workload API, на яких тримається робота застосунків у Kubernetes. Від Deployment та StatefulSet до Job та CronJob — ці контролери визначають, як навантаження створюються, оновлюються, масштабуються та відновлюються, коли щось іде не так.

Оскільки Kubernetes розширюється, щоб підтримувати дедалі різноманітніші навантаження, зокрема AI, пакетну обробку та великомасштабні розподілені застосунки, SIG Apps продовжує розвивати ці API, збалансовуючи надійність, зворотну сумісність та операційну простоту.

**NF: Для читачів, які можуть бути незнайомі з темою: що таке SIG Apps і яку роль вона відіграє в ширшій екосистемі Kubernetes?**

MS: SIG Apps — це Special Interest Group Kubernetes, відповідальна за workloads API. CronJob та Job допомагають запускати пакетні навантаження, тоді як DaemonSet, Deployment, ReplicaSet та StatefulSet обслуговують більшість інших застосунків. Ширше кажучи, SIG Apps володіє шаром, з яким щодня працює більшість розробників: контролерами, які перетворюють специфікацію навантаження на запущені самовідновлювані Podʼи. Саме ця група вирішує, як Deployment роблять rollout, як Job повторюють спроби, як DaemonSet розміщують Podʼи на кожному вузлі.

JK: Додаючи до сказаного Maciej: зі зміною індустрії ми бачимо величезний попит на запуск складних, нетрадиційних навантажень, як-от розподілене AI-навчання, пакетні обчислення та динамічні агентні середовища. Наша роль розширюється: ми не просто підтримуємо класичний workloads API, а активно його розвиваємо та створюємо нові патерни (як-от [Agent Sandbox](https://github.com/kubernetes-sigs/agent-sandbox)), щоб Kubernetes залишався найкращою платформою для наступного покоління навантажень, зокрема AI.

**NF: Розглядаючи workload API, якими володіє SIG Apps (Deployments, StatefulSets, DaemonSets, Jobs та CronJobs), які сфери отримують найбільше уваги від мейнтейнерів і контрибʼюторів?**

MS: Після тривалого періоду, зосередженого на безперебійній роботі пакетних навантажень у Kubernetes, ми змістили увагу на те, щоб обслуговуючі навантаження (DaemonSets, StatefulSets тощо) не залишалися осторонь. Це означає покращення продуктивності та роботи на великих масштабах для rolloutʼу та масштабування, а також опрацювання нашого беклогу проблем, про які повідомляють користувачі, з пріоритетом тих, що мають найсильнішу підтримку користувацької бази.

## Поточні сфери уваги {#current-focus-areas}

Зі зростанням масштабу та складності навантажень Kubernetes змінюються й виклики, що стоять перед контролерами навантажень. Ми запитали голів SIG Apps, на чому сьогодні зосереджують зусилля контрибʼютори та які проблеми стійкості вони вважають найпріоритетнішими.

**NF: На вашу думку, які найважливіші проблеми стійкості навантажень SIG Apps намагається розвʼязати сьогодні?**

MS: Виклики життєвого циклу вузлів неодноразово спливали в дискусіях SIG Apps, SIG Node та SIG Autoscaling. DaemonSets і Jobs — просто місця, де біль найпомітніший, оскільки це навантаження, найбільш безпосередньо привʼязані до стану вузла. Замість того, щоб розвʼязувати це частинами в межах однієї SIG, ми вирішили створити окрему [робочу групу Node Lifecycle](https://github.com/kubernetes/community/blob/main/wg-node-lifecycle/README.md), щоб належно зосередитися на цьому і, сподіваємося, впровадити довгострокові рішення замість разових патчів.

JK: З погляду AI стійкість критично важлива. Коли ви запускаєте велике розподілене навчання LLM, що охоплює сотні GPU, відмова одного вузла може зупинити весь конвеєр. Так само, якщо DaemonSet, що запускає вашого агента логування чи моніторингу GPU, застрягне на поганому вузлі, це вплине на стан всього кластера.

Окрім роботи в Node Lifecycle WG над деградацією на рівні інфраструктури, SIG Apps розвʼязує це на рівні оркестрації через такі підпроєкти, як [JobSet](https://github.com/kubernetes-sigs/jobset/) (для розподіленого навчання) та [LeaderWorkerSet (LWS)](https://github.com/kubernetes-sigs/lws/) (для сегментованого LLM-інференсу). Ці API впроваджують патерни на кшталт обробки відмов "все або нічого", коли збій одного Podʼа чи Jobʼа запускає скоординований перезапуск групи, щоб відновитися з останньої чистої контрольної точки, а не дає застряглим навантаженням зависнути в неузгодженому стані.

## Реальний вплив {#real-world-impact}

Робота, що відбувається в межах SIG Apps, виходить далеко за межі реалізації контролерів та проєктування API. Ми хотіли зрозуміти, що ці покращення означають на практиці для платформних команд, які експлуатують кластери Kubernetes у промисловому середовищі.

**NF: Для платформних команд, які експлуатують Kubernetes у промисловому середовищі, які практичні покращення вони помітили б, якби роботу над життєвим циклом вузлів та стійкістю навантажень, що зараз обговорюється, було успішно реалізовано?**

MS: Я здебільшого спостерігаю збоку, люди з [робочої групи Node Lifecycle](https://github.com/kubernetes/community/blob/main/wg-node-lifecycle/README.md) дали б вам точнішу відповідь. Але з того, що я бачу, сподіваюся, що їхня робота перетвориться на менше дзвінків о 3-й ночі, що виявляються "rollout DaemonSet застряг, бо вузол X був нестабільним, і комусь довелося вручну зробити cordon/delete/restart, щоб розблокувати його".

JK: Плюс один до слів Maciej, і окрім зменшення ручного втручання, платформні команди також побачать набагато кращу передбачуваність ресурсів та економічну ефективність. Наприклад, у AI-навантаженнях, де простій GPU надзвичайно дорогий, автоматичне виявлення Kubernetes деградації вузла та перепланування координатора навчання чи агента до збою Jobʼа означає менше витрачених обчислень і стабільніше виконання робіт.

## Виклики та компроміси {#challenges-and-trade-offs}

Розвиток API, на які покладаються мільйони навантажень, потребує ретельної інженерії та ще ретельніших рішень. Ми запитали голів SIG Apps про технічні та операційні компроміси, які вони зважують, вносячи зміни до основних контролерів навантажень Kubernetes.

**NF: Які найважчі технічні чи операційні компроміси зустрічає SIG Apps під час розвитку основних контролерів навантажень?**

MS: Чесно кажучи, постійно спливає кілька напружень: наскільки агресивно контролер має відмовлятися від застряглих Podʼів і які сигнали йому насправді потрібні, щоб ухвалити це рішення правильно. Водночас ми завжди маємо думати про зворотну сумісність. Поведінка Deployment, DaemonSet та Job залежить від них уже десятиліття \[від користувачів Kubernetes, інструментів, автоматизації та контролерів вищого рівня\], тому навіть зміна, яка явно "правильніша", може ненавмисно зламати автоматизацію, побудовану навколо старої поведінки.

JK: Один з наших найважчих компромісів — опір бажанню вносити "елегантні" дизайнерські зміни, що ламають зворотну сумісність. Натомість ми маємо проєктувати опційні функції, які дозволяють користувачам впроваджувати нову поведінку, не навʼязуючи її застарілим навантаженням. Коли потрібно підтримати повністю нові парадигми, ми надаємо перевагу впровадженню їх спочатку як CRD, а не роздуванню основних API, як ми робимо з Agent Sandbox, JobSet та LWS.

## Погляд у майбутнє {#looking-ahead}

Хоча значна частина роботи SIG Apps зосереджена на підтриманні стабільності наявних workload API, група також формує майбутнє Kubernetes через нові покращення та пропозиції. На завершення ми запитали про одну пропозицію, яка нещодавно повернулася до активної розробки, і про те, що вона означає для майбутнього керування навантаженнями.

**NF: Нещодавно SIG обговорювала відновлення KEP-4443 з цільовим релізом Kubernetes 1.38. Які можливості чи виклики покликана розвʼязати ця пропозиція і чому зараз правильний час повернутися до неї?**

[KEP-4443](https://www.kubernetes.dev/resources/keps/4443/) розвʼязує невеликий, але реальний пробіл у Job API: [PodFailurePolicy](https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-failure-policy) можна налаштувати так, щоб додавати причину стану до умови JobFailed, але різні правила політики відмов Podʼів, націлені на різні коди виходу контейнера, усі продукують цю саму узагальнену причину. Пропозиція проста: опційне поле Name у кожному PodFailurePolicyRule, яке додається до причини стану JobFailed, щоб інструменти вищого рівня, як-от JobSet, нарешті могли реагувати по-різному залежно від того, яке правило спричинило відмову.

Щодо строків, відповідь така сама проста, як завжди у відкритому коді: ми втратили початкового контрибʼютора, який вів цю роботу. Тепер знайшлася нова людина, зацікавлена її продовжити, тому ми й націлюємося на наступний реліз.

## Як долучитися {#getting-involved}

**NF: Для людини, зацікавленої у внеску в SIG Apps, з чого ви б порадили почати, особливо якщо вона ще не є мейнтейнером Kubernetes?**

MS: Найкраще місце для старту — Slack-канал [\#sig-apps](https://www.kubernetes.dev/community/community-groups/sigs/apps/) та наші регулярні [зустрічі SIG Apps](https://github.com/kubernetes/community/blob/main/sig-apps/README.md#meetings). Ми всі починали саме там, і якщо це здається лячним або ніхто не відповідає одразу — це абсолютно нормально. Усі зайняті. Це не особисте.

JK: Додаючи до відповіді Maciej, я б порадила подивитися на наші новіші підпроєкти та ініціативи. Внесок у стабільні API, як-от Deployment чи StatefulSet, може бути складним, бо поріг для змін дуже високий через зворотну сумісність, а низько висячих плодів набагато менше.

Якщо ви новачок у спільноті, такі проєкти, як [Agent Sandbox](https://github.com/kubernetes-sigs/agent-sandbox), є чудовими точками входу. Вони активно розвиваються, мають дружню групу мейнтейнерів і пропонують багато можливостей для розробки з чистого аркуша, де ви можете швидко досягти значного впливу.

## Підсумки {#summary}

SIG Apps формує те, як застосунки Kubernetes розгортаються та експлуатуються, з найраніших днів проєкту. Хоча користувачі часто взаємодіють з Deployment, StatefulSet, Job та DaemonSet, не замислюючись про контролери за ними, робота в межах SIG Apps продовжує формувати надійність та масштабованість навантажень у всій екосистемі Kubernetes.

Від покращення стійкості навантажень та поведінки життєвого циклу вузлів до впровадження нових патернів для AI та розподілених обчислень SIG розвиває Kubernetes, залишаючись відданою одному з ключових принципів проєкту: збереженню стабільності та зворотної сумісності, на які покладаються користувачі. Чи цікавлять вас основні workload API, нові проєкти на кшталт Agent Sandbox, чи допомога у покращенні операційного досвіду користувачів Kubernetes по всьому світу — SIG Apps пропонує багато можливостей долучитися.