Попередній огляд 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 використовує мітки вузлів, taint і toleration, щоб узгодити вимоги до робочого навантаження з можливостями вузлів. Однак керування сумісністю можливостей стає складним під час оновлення кластера через розбіжність версій між панеллю управління та вузлами. Це може призвести до планування 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ʼів або контейнерів. Раніше для таких модифікацій було потрібно перестворювати 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 надає токени ServiceAccount, вони призначені для автентифікації на API-сервері, а не для ідентичності робочих навантажень загального призначення.
До цього вдосконалення оператори мали покладатися на складні зовнішні проєкти, такі як SPIFFE/SPIRE або cert-manager, для надання та ротації сертифікатів для своїх робочих навантажень. Але що якби ви могли видавати унікальний сертифікат з коротким терміном дії для своїх Podʼів нативно і автоматично? KEP-4317 призначений для забезпечення такої нативної ідентичності робочих навантажень. Він відкриває різні можливості для захисту комунікації між Podʼами, дозволяючи kubelet запитувати і монтувати сертифікати для Podʼів через проєкційний том.
Це забезпечує вбудований механізм ідентичності робочих навантажень, доповнений автоматичною ротацією сертифікатів, що значно спрощує налаштування service mesh та інших політик мережі з нульовим рівнем довіри. Ця можливість була представлена в альфа-версії v1.34 і планується до випуску в бета-версії v1.35.
Більше інформації ви можете знайти в KEP-4317: Pod Certificates
Числові значення для taints
Kubernetes вдосконалює taint і toleration шляхом додавання числових операторів порівняння, таких як Gt (більше ніж) та Lt (менше ніж).
Раніше toleration підтримували лише точні (Equal) або збіги існування (Exists), що не підходило для числових властивостей, таких як SLA надійності.
Завдяки цій зміні Pod може використовувати toleration для «підключення» до вузлів, які відповідають певному числовому порогу. Наприклад, Pod може вимагати вузол зі значенням taint SLA більше 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-моделі за допомогою стандартних інструментів реєстру, повністю відокремлюючи дані від образу контейнера та усуваючи необхідність у складних init-контейнерах або скриптах запуску. Цей тип тому перебуває в бета-версії з 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