Kubernetes 1.34: Автоконфігурація для драйвера Node Cgroup переходить у стадію загальної доступності (GA)
Історично, налаштування правильного драйвера cgroup було болючою точкою для користувачів, які запускали нові кластери Kubernetes. В системах Linux існують два різні драйвери cgroup: cgroupfs і systemd. У минулому як kubelet, так і реалізація CRI (така як CRI-O або containerd) повинні були бути налаштовані на використання одного й того ж драйвера cgroup, інакше kubelet поводився б неправильно без жодного явного повідомлення про помилку. Це було джерелом головного болю для багатьох адміністраторів кластерів. Тепер ми (майже) поклали край цьому головному болю.
Автоматичне виявлення драйвера cgroup
У v1.28.0 спільнота SIG Node представила функціональну можливість KubeletCgroupDriverFromCRI, яка вказує kubelet запитувати у реалізації CRI, який драйвер cgroup використовувати. Ви можете прочитати більше тут. Після багатьох випусків очікування, поки кожна реалізація CRI випустить основні версії та упакує їх у основні операційні системи, ця функція стала загальнодоступною (GA) з Kubernetes 1.34.0.
На додачу до налаштування функціональної можливості, адміністратори кластерів повинні переконатися, що їх реалізації CRI є достатньо новими:
- containerd: Підтримка була додана в v2.0.0
- CRI-O: Підтримка була додана в v1.28.0
Оголошення: Kubernetes припиняє підтримку containerd v1.y
Хоча CRI-O випускає версії, які відповідають версіям Kubernetes, і, отже, версії CRI-O без цієї поведінки більше не підтримуються, containerd підтримує свій власний цикл випуску. Підтримка containerd для цієї функції доступна лише в v2.0 і пізніших версіях, але Kubernetes 1.34 все ще підтримує containerd 1.7 та інші LTS випуски containerd.
Спільнота Kubernetes SIG Node формально погодилася на остаточний графік підтримки для containerd v1.y. Останній випуск Kubernetes, який запропонує цю підтримку, буде останньою випущеною версією v1.35, а підтримка буде припинена у v1.36.0. Щоб допомогти адміністраторам у керуванні цією майбутньою трансформацією, доступний новий механізм виявлення. Ви можете моніторити метрику kubelet_cri_losing_support, щоб визначити, чи використовують будь-які вузли у вашому кластері версію containerd, яка незабаром стане застарілою. Наявність цієї метрики з міткою версії 1.36.0 вказуватиме на те, що рушій виконання контейнерів вузла недостатньо новий для майбутніх вимог. Відповідно, адміністратору потрібно буде оновити containerd до v2.0 або пізнішої версії до або одночасно з оновленням kubelet до v1.36.0.