Попередній огляд Kubernetes v1.35
З наближенням випуску Kubernetes v1.35 проєкт Kubernetes продовжує розвиватися. Функції можуть визнаватись застарілими, видаленими або заміненими для поліпшення загального стану проєкту. У цьому дописі в блозі описано заплановані зміни для випуску v1.35, про які, на думку команди випуску, вам слід знати, щоб забезпечити безперебійну роботу ваших кластерів Kubernetes та бути в курсі останніх розробок. Наведена нижче інформація базується на поточному стані версії v1.35 і може бути змінена до дати остаточного випуску.
Застарівання та видалення у версії Kubernetes v1.35
Підтримка cgroup v1
На вузлах Linux середовища виконання контейнерів зазвичай покладаються на cgroups (скорочення від «control groups», групи контролю). Підтримка використання cgroup v2 є стабільною в Kubernetes з версії v1.25, надаючи альтернативу оригінальній підтримці cgroup v1. Хоча cgroup v1 забезпечувала початковий механізм контролю ресурсів, вона мала відомі невідповідності та обмеження. Додавання підтримки cgroup v2 дозволило використовувати уніфіковану ієрархію контрольних груп, поліпшило ізоляцію ресурсів і стало основою для сучасних функцій, що зробило підтримку застарілої cgroup v1 готовою до видалення. Видалення підтримки cgroup v1 вплине лише на адміністраторів кластерів, які використовують вузли на старих дистрибутивах Linux, що не підтримують cgroup v2; на цих вузлах kubelet не зможе запуститися. Адміністратори повинні перенести свої вузли на системи з увімкненим cgroup v2. Більш детальна інформація про вимоги до сумісності буде доступна в блозі незабаром після випуску версії v1.35.
Щоб дізнатися більше, прочитайте про cgroup v2; ви також можете стежити за роботою з переходу в KEP-5573: Remove cgroup v1 support.
Визнання застарілим режиму ipvs в kube-proxy
Багато версій тому проєкт Kubernetes реалізував режим ipvs в kube-proxy. Він був прийнятий як спосіб забезпечення високоефективного балансування навантаження сервісів, з кращою продуктивністю, ніж наявний режим iptables. Однак підтримка функціональної рівності між ipvs та іншими режимами kube-proxy стала складною через технічну складність та розбіжності у вимогах. Це створило значний технічний борг і зробило бекенд ipvs непрактичним для підтримки поряд з новими мережевими можливостями.
Проєкт Kubernetes має намір відмовитися від режиму kube-proxy ipvs у версії v1.35, щоб оптимізувати кодову базу kube-proxy. Для вузлів Linux рекомендованим режимом kube-proxy вже є nftables.
Більше інформації можна знайти в KEP-5495: Deprecate ipvs mode in kube-proxy.
Kubernetes припиняє підтримку containerd v1.y
Хоча Kubernetes v1.35 все ще підтримує containerd 1.7 та інші LTS-версії containerd, внаслідок автоматичного виявлення драйвера cgroup спільнота Kubernetes SIG Node офіційно погодила остаточний графік підтримки containerd v1.X. Kubernetes v1.35 є останньою версією, яка пропонує цю підтримку (відповідно до EOL containerd 1.7).
Це останнє попередження про те, що якщо ви використовуєте containerd 1.X, ви повинні перейти на 2.0 або пізнішу версію перед оновленням Kubernetes до наступної версії. Ви можете відстежувати метрику kubelet_cri_losing_support, щоб визначити, чи використовують якісь вузли у вашому кластері версію containerd, яка незабаром перестане підтримуватися.
Більше інформації ви можете знайти в офіційному блозі або в KEP-4033: Discover cgroup driver from CRI
Основні вдосконалення Kubernetes v1.35
Наступні вдосконалення є одними з тих, які, ймовірно, будуть включені до версії v1.35. Це не є зобовʼязанням, і зміст версії може бути змінений.
Можливості, оголошені вузлами
Під час планування Podʼів Kubernetes використовує мітки вузлів, позначки taints та толерантності, щоб узгодити вимоги до робочого навантаження з можливостями вузлів. Однак управління сумісністю можливостей стає складним під час оновлення кластера через розбіжність версій між панеллю управління та вузлами. Це може призвести до планування Podʼів на вузлах, які не мають необхідних можливостей, що спричинить збої під час виконання.
Фреймворк node declared features запровадить стандартний механізм для вузлів, щоб вони могли оголошувати свої підтримувані функції в Kubernetes. З увімкненою новою альфа-функцією вузол повідомляє про функції, які він може підтримувати, публікуючи цю інформацію у панелі управління через нове поле .status.declaredFeatures. Потім kube-scheduler, контролери допуску та сторонні компоненти можуть використовувати ці оголошення. Наприклад, ви можете застосувати обмеження планування та перевірки API, гарантуючи, що Podʼи працюють тільки на сумісних вузлах.
Цей підхід зменшує ручне маркування вузлів, покращує точність планування та запобігає розміщенню несумісних podʼів. Він також інтегрується з Cluster Autoscaler для обґрунтованих рішень щодо масштабування. Декларації функцій є тимчасовими та повʼязані з функціональними можливостями Kubernetes, що забезпечує безпечне впровадження та очищення.
Орієнтуючись на альфа-версію в v1.35, node declared features має на меті вирішити проблеми планування версій, зробивши можливості вузлів явними, підвищивши надійність і стабільність кластера в гетерогенних версійних середовищах.
Щоб дізнатися більше про це до опублікування офіційної документації, ви можете прочитати KEP-5328.
Оновлення ресурсів Podʼів на місці
Kubernetes переводить оновлення ресурсів Podʼів на місці в статус загальної доступності (GA). Ця функція дозволяє користувачам налаштовувати ресурси cpu та memory без перезапуску Podʼів або Containerʼів. Раніше для таких модифікацій було потрібно перестворювати Podʼи, що могло порушити робочі навантаження, особливо для застосунків зі збереженням стану або пакетних застосунків. Попередні версії Kubernetes вже дозволяли змінювати налаштування ресурсів інфраструктури (запити та обмеження) для наявних Podʼів. Це забезпечує більш плавне вертикальне масштабування, підвищує ефективність, а також може спростити розробку рішень.
Також було вдосконалено інтерфейс Container Runtime Interface (CRI), розширивши API UpdateContainerResources для Windows і майбутніх середовищ виконання, а також дозволивши ContainerStatus повідомляти про конфігурації ресурсів у реальному часі. У сукупності ці зміни роблять масштабування в Kubernetes швидшим, гнучкішим і безперебійним. Ця функція була представлена в альфа-версії v1.27, перейшла в бета-версію v1.33 і планується до випуску в стабільній версії v1.35.
Більше інформації ви можете знайти в KEP-1287: In-place Update of Pod Resources
Сертифікати Podʼів
Під час виконання мікросервісів Podʼи часто потребують надійної криптографічної ідентифікації для взаємної автентифікації за допомогою mutual TLS (mTLS). Хоча Kubernetes надає токени Service Account, вони призначені для автентифікації на сервері API, а не для загальної ідентифікації робочих навантажень.
До цього вдосконалення оператори мали покладатися на складні зовнішні проєкти, такі як SPIFFE/SPIRE або cert-manager, для надання та ротації сертифікатів для своїх робочих навантажень. Але що якби ви могли видавати унікальний сертифікат з коротким терміном дії для своїх Podʼів нативно і автоматично? KEP-4317 призначений для забезпечення такої нативної ідентифікації робочих навантажень. Він відкриває різні можливості для захисту комунікації між Podʼами, дозволяючи kubelet запитувати і монтувати сертифікати для Podʼів через спроєцьований том.
Це забезпечує вбудований механізм ідентифікації робочих навантажень, доповнений автоматичною ротацією сертифікатів, що значно спрощує налаштування сервісних мереж та інших політик мережі з нульовим рівнем довіри. Ця функція була представлена в альфа-версії v1.34 і планується до випуску в бета-версії v1.35.
Більше інформації ви можете знайти в KEP-4317: Pod Certificates
Числові значення для taints
Kubernetes вдосконалює позначки taint та толерантності шляхом додавання числових операторів порівняння, таких як Gt (більше ніж) та Lt (менше ніж).
Раніше толерантності підтримували лише точні (Equal) або збіги існування (Exists), що не підходило для числових властивостей, таких як SLA надійності.
Завдяки цій зміні Pod може використовувати толерантність для «підключення» до вузлів, які відповідають певному числовому порогу. Наприклад, Pod може вимагати Node з значенням SLA taint більше 950 (operator: Gt, value: "950").
Цей підхід є більш потужним, ніж Node Affinity, оскільки він підтримує ефект NoExecute, що дозволяє автоматично вилучати Pod, якщо числове значення вузла падає нижче допустимого порогу.
Більше інформації ви можете знайти в KEP-5471: Enable SLA-based Scheduling
Простори імен користувачів
Під час запуску Podʼів ви можете використовувати securityContext для скасування привілеїв, але контейнери всередині podʼів часто все одно працюють як root (UID 0). Ця простота створює значну проблему, оскільки UID 0 контейнера безпосередньо відповідає користувачеві root хоста.
До цього вдосконалення вразливість контейнера могла надати зловмиснику повний root-доступ до вузла. А що, якби ви могли динамічно перепризначити root-користувача контейнера на безпечного користувача без привілеїв на хості? KEP-127 спеціально дозволяє таку вбудовану підтримку для просторів імен користувачів Linux. Це відкриває різні можливості для безпеки podʼів, ізолюючи ідентифікатори користувачів/груп контейнера та хоста. Це дозволяє процесу мати привілеї root (UID 0) у своєму просторі імен, працюючи як непривілейований UID з високим номером на хості.
Випущена в альфа-версії v1.25 і бета-версії v1.30, ця функція продовжує розвиватися в бета-версії, прокладаючи шлях для справді "rootless" контейнерів, які різко зменшують площу атаки для цілого класу вразливостей безпеки.
Більше інформації ви можете знайти в KEP-127: User Namespaces
Підтримка монтування образів OCI як томів
Під час провізування Podʼів часто потрібно обʼєднувати дані, бінарні файли або файли конфігурації для контейнерів. До цього вдосконалення такі дані часто включали безпосередньо в основний образ контейнера або вимагали спеціального контейнера init для завантаження та розпакування файлів у emptyDir. Звичайно, ви все ще можете використовувати будь-який з цих підходів.
Але що, якби ви могли заповнити том безпосередньо з артефакту, що містить тільки дані, в реєстрі OCI, так само, як ви завантажуєте образ контейнера? У Kubernetes v1.31 додано підтримку типу тому image, що дозволяє Podʼам завантажувати та розпаковувати артефакти образів контейнерів OCI в том декларативно.
Це дозволяє безперешкодно розподіляти дані, бінарні файли або ML-моделі за допомогою стандартних інструментів реєстру, повністю відокремлюючи дані від образу контейнера та усуваючи необхідність у складних контейнерах ініціалізації або скриптах запуску. Цей тип тому перебуває в бета-версії з v1.33 і, ймовірно, буде стандартно ввімкнений у v1.35.
Ви можете спробувати бета-версію томів image або дізнатися більше про плани з KEP-4639: OCI Volume Source.
Хочете дізнатися більше?
Нові функції та застарівання функції також оголошуються в примітках до випуску Kubernetes. Ми офіційно оголосимо про нововведення в Kubernetes v1.35 у рамках CHANGELOG для цього випуску.
Випуск Kubernetes v1.35 заплановано на 17 грудня 2025 року. Слідкуйте за оновленнями!
Ви також можете переглянути оголошення про зміни в примітках до випуску для:
Долучайтеся до спільноти
Найпростіший спосіб долучитися до Kubernetes — приєднатися до однієї з численних спеціальних груп за інтересами (SIG), яка відповідає вашим інтересам. Хочете поділитися чимось із спільнотою Kubernetes? Висловіть свою думку на нашому щотижневому зібранні спільноти та у наведених нижче каналах. Дякуємо за ваші відгуки та підтримку.
- Слідкуйте за нами у Bluesky @kubernetes.io, щоб отримувати останні оновлення
- Приєднуйтесь до обговорення на Discuss
- Приєднуйтесь до спільноти в Slack
- Публікуйте питання (або відповідайте на питання) на Server Fault або Stack Overflow
- Поділіться своєю історією про Kubernetes
- Дізнайтеся більше про те, що відбувається в Kubernetes, у блозі
- Дізнайтеся більше про команду випуску Kubernetes