Вийшла нова версія Kubernetes v1.35

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Команда Kubernetes представила нову версію 1.35 з низкою покращень.

Головні зміни

Окремі правила перезапуску для контейнерів

До v1.35 Kubernetes дозволяв керувати перезапуском лише на рівні Pod через restartPolicy. Це означало, що всі контейнери, і основні, і допоміжні, мусили жити за одними правилами. У простих сервісах це не було проблемою, але в складних Pod’ах швидко ставало обмеженням.

У Kubernetes v1.35 з’являється можливість задавати restartPolicy і restartPolicyRules на рівні конкретного контейнера. Це дозволяє перезапускати лише ті контейнери, які справді цього потребують, реагувати на конкретні exit-коди та уникати дорогого перепланування Pod через дрібні збої.

Функція перебуває в beta та вже увімкнена за замовчуванням, тож її можна використовувати без додаткових прапорців функцій.

Безпечніша передача ServiceAccount-токенів у CSI-драйверах

Раніше ServiceAccount-токени передавалися через volume_context, поле, яке не вважалося чутливим і часто логувалося драйверами або інструментами діагностики. У реальних кластерах це створювало ризик витоку токенів у логах.

У v1.35 Kubernetes додає opt-in-механізм, який дозволяє CSI-драйверам отримувати токени через поле secrets. Драйвер має явно задекларувати підтримку цього механізму у своєму об’єкті CSIDriver.

Це не ламає зворотну сумісність, але дає чіткий шлях до безпечнішої роботи з обліковими даними.

Краще розуміння стану Deployment під час оновлень

Під час розгортань і масштабування часто виникала ситуація, коли Deployment формально виглядав майже готовим, але частина Pod ще перебувала у стані завершення. Це ускладнювало автоматизацію й змушувало вручну перевіряти поди.

У Kubernetes v1.35 поле terminatingReplicas у статусі Deployment перейшло в beta. Воно показує кількість Pod, які вже отримали deletionTimestamp, але ще не завершили роботу.

Це дозволяє точніше оцінювати реальний стан Deployment, коректніше будувати логіку в CI/CD і autoscaling та простіше дебажити завислі розгортання.

Gang-планування для batch і AI-навантажень

Стандартний планувальник Kubernetes планує Pod по одному. Для web-сервісів це нормально, але для batch-задач і AI/ML-тренувань часто створює проблеми, бо частина Pod стартує, частина чекає ресурсів, і в результаті завдання або не стартує повністю, або даремно займає ресурси.

У v1.35 з’являється alpha-підтримка gang scheduling — механізму, який дозволяє планувати групу Pod як єдине ціле. Якщо ресурсів недостатньо для всіх Pod одразу, не запускається жоден.

Реалізація базується на новому Workload API та PodGroup. Поки що це alpha-функція, але вона показує напрямок розвитку Kubernetes у бік кращої підтримки паралельних і ресурсоємних задач без сторонніх планувальників.

Обмежене impersonation у RBAC

Механізм impersonation у Kubernetes довгий час був надто грубим. Якщо користувач мав право імперсонувати іншу ідентичність, то він отримував повний доступ цієї ролі.

У Kubernetes v1.35 з’являється alpha-функція constrained impersonation. Вона дозволяє обмежувати, які саме дії можна виконувати під час імперсонування. Наприклад, дати можливість підтримці виконувати дії від імені адміна лише для читання логів або статусів, без змін у кластері.

Інші зміни

Окрім ключових фіч, реліз містить низку менш помітних покращень:

• /flagz і /statusz для компонентів Kubernetes тепер підтримують JSON-вивід, що спрощує інтеграцію з інструментами observability та аудит конфігурацій.
• Job отримують alpha-підтримку змінюваних resource requests і limits без пересоздання, що корисно для довготривалих batch-задач.
• З’явилися розширені оператори toleration для порогового планування Pod (alpha).
• Cloud Controller Manager переходить на event-driven синхронізацію маршрутів, зменшуючи кількість зайвих API-викликів.
• Проведено дрібні оптимізації kubelet, scheduler та API-server, а також прибрано застарілі feature gates і поля.

Детальніше про оновлення читайте в офіційному блозі Kubernetes.