Розробники 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.
19 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівKubernetes Crash Course for Absolute Beginners by TechWorld with Nana
Не знаю в яку тему... але твітнути тут хочеться. В мене зараз не завантажується YouTube. А у вас?
норм
О, і у мене ожив.
kubernetes.io/...y-for-dockershim-removal
Лінк на оригінал
Вже рік хочу одну зі статей про 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 ще ж не релізили :) та й після релізу мало що зміниться
Не, я про те що вже давним давно)), сидимо не на докері