У міру наближення дати випуску Kubernetes v1.37 (проєкт розвивається та вдосконалюється) деякі функції можуть бути визнані застарілими, видаленими або замінені кращими з метою забезпечення загального стабільного функціонування проєкту. У цьому дописі міститься опис деяких запланованих змін у версії Kubernetes v1.37, про які, на думку команди з випуску, вам слід знати для подальшого обслуговування вашого середовища Kubernetes та щоб бути в курсі останніх змін. Наведена нижче інформація показує поточний стан версії v1.37 і може змінитися до фактичної дати випуску.
kubectl run --filename/-f буде визнано застарілимПрапорець --filename (або -f) для kubectl run буде визнано застарілим, оскільки згенерований Pod завжди будується виключно з CLI-аргументів, таких як NAME і --image.
Див. kubernetes/kubernetes#138671 для ознайомлення з оригінальною проблемою та обговорення.
Статичні Podʼи ніколи не були призначені для прямого читання API-ресурсів, оскільки вони не створюються через API-сервер, але помилка дозволяла їм посилатися на Секрети чи ConfigMap через такі поля, як configMapRef або secretRef. Ця помилка тепер виправлена: починаючи з v1.37 такі посилання суворо заборонені, а функціональну можливість PreventStaticPodAPIReferences, яка раніше дозволяла вам відмовитися від обмеження, було видалено.
Див. kubernetes/kubernetes#140226 для ознайомлення з оригінальною проблемою та обговорення.
ipvs режиму в kube-proxyПідтримка ipvs режиму в kube-proxy була введена в v1.8 для вирішення проблем продуктивності iptables. Однак, оскільки API ipvs ядра сам по собі не може повністю реалізувати Kubernetes Services, ipvs режим продовжує використовувати iptables під капотом (KEP-3866, "The ipvs mode of kube-proxy will not save us").
Кластери, в яких kube-proxy працює в ipvs режимі (або mode: ipvs в KubeProxyConfiguration), тепер логують попередження про застарівання під час запуску. Термін застарівання виглядає так:
ipvs режим для kube-proxy очікується, що буде стандартно вимкненим (але його все ще можна вибрати через функціональну можливість)ipvs режиму буде повністю видалена KEP-5495, Graduation Criteria.Щоб перевірити , який режим ви зараз використовуєте, скористайтеся:
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
Щоб зрозуміти обґрунтування цього застарівання, див. KEP-5495: Deprecate ipvs mode in kube-proxy.
Оскільки сучасні дистрибутиви Linux та рушій виконання контейнерів стандартно використовують cgroup v2, підтримка застарілої cgroup v1 офіційно поступово припиняється. Починаючи з випуску v1.35, налаштування failCgroupV1 зазвичай встановлено true. Як наслідок, kubelet не зможе ініціалізуватися на будь-яких вузлах, що все ще покладаються на cgroup v1, якщо не буде застосовано явне налаштування заміни.
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # тимчасове перевизначення
Використання цього перевизначення слід вважати короткостроковим виправленням. Розширені можливості керування ресурсами, такі як In-Place Pod Resizing та Tiered Memory Protection, повністю залежать від cgroup v2. Хоча перевизначення залишається доступним у Kubernetes v1.37, користувачам рекомендується мігрувати до cgroup v2, оскільки підтримка cgroup v1 планується бути видаленою в майбутньому випуску.
Щоб дізнатися більше про це застарівання, зверніться до KEP-5573: Remove cgroup v1 support.
SELinuxMount очікується, що досягне GA та буде стандартно увімкненим у v1.37. Томи будуть монтуватися з -o context=<label> (опція монтування зі стандартними значеннями) замість рекурсивного переназначення міток, але лише коли CSI драйвер тома погодиться на це через CSIDriver, що встановлює .spec seLinuxMount: true.
Оскільки одне монтування може містити лише один контекст SELinux, поди, що мають різні мітки SELinux і спільно використовують том на одному вузлі (які раніше могли співіснувати завдяки рекурсивній зміні міток), тепер можуть не запускатися. Щоб зберегти попередню рекурсивну поведінку для конкретного робочого навантаження, вкажіть у специфікації Podʼів значення seLinuxChangePolicy: Recursive.
У кластерах, де SELinux не ввімкнено, жодних змін не спостерігається. Щоб дізнатися більше, перегляньте SELinux Volume Label Changes goes GA (and likely implications in v1.37)
Очікується, що API metrics.k8s.io досягне рівня Stable (GA) у Kubernetes v1.37 після майже девʼяти років перебування в Beta. API забезпечує стандартний спосіб отримання даних про використання CPU та памʼяті для Podʼів та вузлів, підтримуючи роботу таких широко використовуваних функцій Kubernetes, як Horizontal Pod Autoscaler (HPA) та команд на кшталт kubectl top.
Цей перехід до стабільної версії визнає стабільність API та його широке впровадження, без очікуваних функціональних змін. Обидва типи v1 та v1beta1 залишаться робочими під час переходу, дозволяючи розробникам прийняти стабільний API у власному темпі без внесення суттєвих змін в наявні робочі процеси.
Щоб дізнатися більше про це покращення, зверніться до KEP-5207: metrics.k8s.io API definition.
Традиційно, компоненти вузла Kubernetes, такі як kubelet, працюють з привілеями root на хості. Хоча це необхідно для багатьох розгортань, це також означає, що вразливість в одному з цих компонентів могла б потенційно мати більший вплив на базову систему.
У Kubernetes v1.37 очікується, що kubelet у User Namespace (Rootless Mode) досягне Beta. Це покращення дозволяє Kubernetes компонентам вузла працювати всередині Linux user namespace як непривілейованому користувачу на хості, але все одно поводитися як root всередині namespace. Зменшуючи потребу в привілеях root на рівні хосту, воно додає додатковий шар ізоляції та допомагає обмежити вплив потенційних вразливостей, що впливають на компоненти вузла.
Щоб дізнатися більше про це покращення, зверніться до KEP-2033: Kubelet in UserNS(aka Rootless Mode).
Історично в Kubernetes не було API, за допомогою якого драйвери CSI могли б повідомляти про збої в роботі систем зберігання даних, які виявлялися лише через невдалі монтування або зависання операцій вводу-виводу. Оскільки контролери усунення несправностей не мали жодних даних у машиночитаному форматі, на основі яких можна було б вжити заходів, єдиним способом зʼясувати першопричину такого збою було зіставлення обʼєктів Kubernetes із даними на зовнішніх інформаційних панелях постачальників.
У Kubernetes v1.37 цей KEP повертає статус Graduation до рівня Alpha після початкової реалізації у версії v1.21 та впроваджує чотири нові RPC-інтерфейси CSI. Втулок контролера повідомляє про стан томів сховища за допомогою ControllerListVolumeHealth (виводить список томів, що не працюють належним чином) та ControllerGetVolumeHealth (перевіряє стан конкретного тому). Монітор працездатності на стороні контролера опитує ці контролери CSI та зберігає результати у PersistentVolumeClaim.status.healthStatus.
На боці вузла, kubelet викликає NodeGetVolumeHealth, щоб отримати стан окремих томів на цьому вузлі та записує його в Pod.status.volumeHealth, тоді як NodeGetStorageHealth повідомляє про стан драйверів, зареєстрованих на вузлі, в CSINode.status.storageHealth.
Набір помилок тримається простим, розширюваним та машиннозчитуваним (Inaccessible, Degraded тощо), з подальшим деталізованим описом від драйвера через reason та message. Нарешті, звіти на боці контролера та на боці вузла тримаються незалежними та, отже, відображаються окремо, забезпечуючи більш цілісний огляд стану сховища споживачам.
Щоб дізнатися більше про це покращення, зверніться до KEP-1432: Volume Health Monitor.
Нові функції та функції, що виводяться з експлуатації, також оголошуються в нотатках до випуску Kubernetes. Ми офіційно оголосимо, що нового в Kubernetes v1.37 у рамках CHANGELOG для цього випуску.
Випуск Kubernetes v1.37 заплановано на середу, 26 серпня 2026 року. Слідкуйте за оновленнями!
Ви також можете переглянути оголошення про зміни в нотатках до випуску для:
Найпростіший спосіб долучитися до проєкту Kubernetes — приєднатися до однієї з багатьох Special Interest Groups (SIG), які відповідають вашим інтересам.
Якщо ви не знаєте, з чого почати, долучайтеся до наших щомісячних сесій для нових учасників, де ми розповідаємо спільноті, як влаштований проєкт, і допоможемо вам зробити свій перший внесок.