Dockershim: почему Kubernetes отказался от поддержки Docker Engine — полный мастер-класс

Представляем вашему вниманию материалы от DevXOps — https://devxops.tech Вы запускаете команду `kubectl apply`, и запускается Pod. В течение многих лет Kubernetes взаимодействовал с Docker Engine для этого, но Docker никогда не говорил на языке Kubernetes. Поэтому Kubernetes создал мост: `dockershim`. Это был слой совместимости внутри `kubelet`, который преобразовывал вызовы CRI в вызовы API Docker. Он был необходим во время расцвета Kubernetes. Затем он был объявлен устаревшим в версии 1.20 и удален в версии 1.24. Что пришло ему на смену? Как осуществить миграцию? Работают ли образы Docker по-прежнему? В этом 15-минутном мастер-классе мы рассмотрим все, что вам нужно знать о dockershim: что это было, зачем он был нужен, как он работал внутри, архитектура, историческая хронология, почему он был признан устаревшим и удален, что его заменило (containerd, CRI-O, cri-dockerd), сравнение с другими инструментами, влияние на реальные операции, стратегия миграции, распространенные заблуждения, текущее состояние и матрица принятия решений, а также подведем итоги. Что вы узнаете: Что такое dockershim (транслятор между kubelet и Docker Engine) Почему он существовал (Docker не реализовывал CRI напрямую) Как он работал: kubelet → dockershim → Docker Engine → containerd → runc Почему Kubernetes отказался от него (бремя обслуживания, чистота архитектуры, зрелость экосистемы) Что его заменило: containerd, CRI-O, cri-dockerd Образы Docker по-прежнему работают — формат, совместимый с OCI Влияние на реальный мир: docker.sock, docker ps против crictl, агенты безопасности, сценарии выполнения Стратегия миграции: обнаружение среды выполнения, инвентаризация зависимостей, выбор цели, проверка инструментов, обновление сценариев выполнения Распространенные заблуждения: образы Docker против среды выполнения Docker Engine Матрица принятия решений: когда использовать containerd, CRI-O или cri-dockerd Для кого это видео: SRE-специалисты и инженеры платформы, управляющие Kubernetes кластеры DevOps-инженеры планируют миграцию среды выполнения с Dockershim Операторы Kubernetes обновляются до версии 1.24 или выше Все, кто слышал «Docker устарел в Kubernetes» и хочет получить разъяснения Инженеры отлаживают проблемы среды выполнения контейнеров Команды с зависимостями от сокетов Docker (агенты безопасности, мониторинг) Ключевой вывод: Dockershim был мостом совместимости, а не самой средой выполнения контейнеров. Kubernetes отказался от него, чтобы полагаться на среды выполнения, нативные для CRI. Образы Docker по-прежнему работают. Используйте containerd или CRI-O на узлах. Собирайте с помощью Docker, если хотите. Запускайте с помощью сред выполнения, нативных для CRI. Хронология: 0:00 Хук: Kubernetes и Docker Engine 0:45 Что такое Dockershim (транслятор, мост CRI) 1:50 Почему он был необходим (совместимость, внедрение) 2:50 Как он работал внутри (полный стек) 4:05 Подробный анализ архитектуры (уровень интеграции с узлами) 5:15 Историческая хронология (2014-2026, устаревание, удаление) 6:20 Почему он был устаревшим и удаленным (пять причин) 7:35 Что заменило Dockershim (containerd, CRI-O, cri-dockerd) 8:45 Большое сравнение (Docker, dockershim, containerd, CRI-O, cri-dockerd, runc) 9:55 Влияние на реальный мир (docker.sock, crictl, операционный связующий компонент) 11:00 Стратегия миграции (пять шагов, замена узлов) 12:00 Общие Заблуждения (образы Docker по-прежнему работают) 12:55 Текущее состояние и матрица решений 13:50 Итоги 14:40 Спасибо Подписывайтесь, чтобы получать больше анимированных обзоров DevOps и Kubernetes. DevXOps — https://devxops.tech Упрощение сложных систем с помощью анимации. #dockershim #Kubernetes #Docker #CRI #containerd #CRIO #cridockerd #DevOps #SRE