Розробники Kubernetes влаштували опитування, чи готові користувачі до видалення Dockershim

Розробники Kubernetes — відкритої системи автоматичного розгортання, масштабування та управління застосунками у контейнерах від компанії Google, вирішили з’ясувати, наскільки користувачі готові до видалення компонента dockershim. Його створювали для того, аби Docker міг працювати з CRI.

Автори закликали всіх бажаючих взяти участь в опитуванні на цю тему.

Про що йдеться

У 2020 році стало відомо, що Kubernetes відмовляється від dockershim на користь containerd та CRI-O. Очікується, що компонент dockershim, відповідальний за взаємодію з Docker, буде видалено з кодової бази Kubernetes у релізі v1.24 (квітень 2022 року).

При цьому рішення позиціонується як черговий крок порятунку від функцій, які вічно перебувають у бета-версії, й одночасно як можливість дати користувачам більше гарантій стабільності та сумісності.

Проте, розуміючи важливість цієї зміни, розробники K8s організували опитування з метою з’ясувати, чи готові користувачі до видалення dockershim.

За словами авторів опитування, хоча дані деяких досліджень (Datadog, Sysdig) і показують, що перехід на containerd набирає обертів, dockershim, як і раніше, дуже популярний. Не готові до міграції також багато постачальників сторонніх рішень, зокрема для телеметрії (логування) та безпеки.

У чому складність переходу

Автори системи хочуть зрозуміти, чому користувачам непросто відмовитися від dockershim.

Судячи з перших двох питань, у спільноті не впевнені, що користувачі повною мірою поінформовані:

  • «Ви знаєте, що підтримка dockershim припиниться в K8s 1.24?»;
  • «Чи вважаєте, що у вас достатньо інформації про варіанти міграції, і чи готові ви до видалення dockershim?».

Водночас розробники K8s уже підготували низку документів для спрощення переходу:

  • посібник із міграції з dockershim, з якого можна дізнатися, який CRI використовується на вузлах зараз, як вплине відмова від dockershim на застосунки тощо;
  • інструкція з використання containerd та CRI-O у документації K8s;
  • FAQ з відповідями на популярні питання про відмову від dockershim і про можливі наслідки.


Радимо почитати наші технічні статті, пов’язані з системою Kubernetes:

Підхід GitOps як сучасна практика для CD з Kubernetes.

Масштабируем автоматизацию тестирования с помощью Kubernetes.

Как удовлетворить все non functional requirements c помощью K8S.

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Не знаю в яку тему... але твітнути тут хочеться. В мене зараз не завантажується YouTube. А у вас?

О, і у мене ожив.

Вже рік хочу одну зі статей про gRPC оновити до нових технологій, тепер ще й Docker на Kubernetes замінювати.

Якщо ще рік зачекаю то й gRPC застаріє.

Вже 4 роки як є хороше відео про gRPC з Kubernetes youtu.be/XaMr—wAuSI, а в проектах з Go й досі продовжують писати через REST та Docker, інколи навіть без OpenAPI

Так помирав хабр... там теж все почалось з жовтих заголовків.

чего-то не хватает... А! Раздела Здоровье!

Ну, якщо так, то доу був зразу мертвонароджений. Доу як технічний ресурс — ніякий, як соціальний — одна жовтизна.

Так, перепрошуємо. Вже поправили.

Войтішні реалії: не встиг чергову подєлку освоїти як її вже закопують.

Сидимо на березi й дивимось як по течiї пливе ото все.

С другой стороны разработчики матерятся когда легаси говно из релиза в релиз тянут десятилетиями.

Потрібно знайти баланс, як і усюди

Давайте чесно: ніхто не закопує Docker чи сам Kubernetes. Просто в «кубі» і так реалізовано можливості, які надає Docker/Docker Swarm (мережі, комунікація між контейнерами тощо).

Резонний крок у напрямку оптимізації: прийшов час випиляти те, що було створено для полегшення міграції на «куб».

Обидві технології залишаються «в строю». Більше того, розробники «куба» надають можливість позбавитись дещо заважкого Docker, коли мова йде лише про побудову «знімків» (images) та запуск контейнерів з них. Той самий Docker давно використовує containerd під капотом. Тому знімки можна будувати як через Docker, так і через Buildah — обидва варіанти повністю відповідають специфікації OCI — Open Container Initiative.

Відомий Docker Captain Bret Fisher одразу випустив подкаст після анонсу від команди Kubernetes, щоби заспокоїти спільноту. Те саме зробила команда «куба», випустивши статтю, що саме буде видалено.

для кубернетисчиків нічого не мінятеся, microk8s на containerd працює без ніяких проблем все теж саме

Ну, тому що 1.24 ще ж не релізили :) та й після релізу мало що зміниться

Не, я про те що вже давним давно)), сидимо не на докері

Підписатись на коментарі