Попередній огляд Kubernetes v1.37

Автор Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor | Перекладач(і) Андрій Головін |

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

Застарівання та видалення у Kubernetes v1.37

Kubectl: kubectl run --filename/-f буде визнано застарілим

Прапорець --filename (або -f) для kubectl run буде визнано застарілим, оскільки згенерований Pod завжди будується виключно з CLI-аргументів, таких як NAME і --image.

Див. kubernetes/kubernetes#138671 для ознайомлення з оригінальною проблемою та обговорення.

Kubelet: Статичні Podʼи більше не можуть посилатися на Secret чи ConfigMap

Статичні Podʼи ніколи не були призначені для прямого читання API-ресурсів, оскільки вони не створюються через API-сервер, але помилка дозволяла їм посилатися на Secret чи ConfigMap через такі поля, як configMapRef або secretRef. Ця помилка тепер виправлена: починаючи з v1.37 такі посилання суворо заборонені, а функціональну можливість PreventStaticPodAPIReferences, яка раніше дозволяла вам відмовитися від обмеження, було видалено.

Див. kubernetes/kubernetes#140226 для ознайомлення з оригінальною проблемою та обговорення.

Застарівання підтримки режиму ipvs в kube-proxy

Підтримка режиму ipvs в kube-proxy була введена в v1.8 для вирішення проблем продуктивності iptables. Однак, оскільки API ipvs ядра сам по собі не може повністю реалізувати Service Kubernetes, режим ipvs продовжує використовувати iptables під капотом (KEP-3866, "The ipvs mode of kube-proxy will not save us").

Кластери, в яких kube-proxy працює в режимі ipvs (або mode: ipvs у KubeProxyConfiguration), тепер логують попередження про застарівання під час запуску. Графік застарівання виглядає так:

  • До v1.40 режим ipvs для kube-proxy, як очікується, буде типово вимкнено (але його все ще можна вибрати через функціональну можливість)
  • До v1.43 підтримку режиму 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.

Майбутні великі зміни

Майбутнє видалення підтримки cgroup v1

Оскільки сучасні дистрибутиви 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.

Кардинальні зміни у Kubernetes v1.37

Зміна міток томів SELinux ("SELinuxMount") переходить до GA

Очікується, що SELinuxMount досягне GA і буде типово увімкнений у v1.37. Томи будуть монтуватися з -o context=<label> (типова опція монтування) замість рекурсивного переназначення міток, але лише коли драйвер CSI тома погодиться на це через CSIDriver, що встановлює .spec seLinuxMount: true.

Оскільки одне монтування може містити лише один контекст SELinux, Podʼи, що мають різні мітки SELinux і спільно використовують том на одному вузлі (які раніше могли співіснувати завдяки рекурсивній зміні міток), тепер можуть не запускатися. Щоб зберегти попередню рекурсивну поведінку для конкретного робочого навантаження, вкажіть у специфікації Podʼа значення seLinuxChangePolicy: Recursive.

У кластерах, де SELinux не ввімкнено, жодних змін не спостерігається. Щоб дізнатися більше, перегляньте SELinux Volume Label Changes goes GA (and likely implications in v1.37)

Metrics API переходить до GA

Очікується, що 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.

Kubelet у UserNS, також відомий як Rootless Mode

Традиційно, компоненти вузла 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 повертає рівень зрілості до 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

Найпростіший спосіб долучитися до проєкту Kubernetes — приєднатися до однієї з багатьох Special Interest Groups (SIG), які відповідають вашим інтересам.

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

Змінено November 03, 2026 at 6:59 PM PST: [uk] Add blog posts mutable-pv-affinity-alpha, jobs-podreplacementpolicy-goes-ga and kubernetes-v1-37-sneak-peek (b819a8fa48)