Docker 엔진은 어떻습니까?
"containerd로 전환하면 더 이상 Docker 엔진을 사용할 수 없습니까?" 우리는 이 질문을 많이 듣습니다. 짧은 대답은 NO입니다.
Docker 엔진은 containerd 위에 구축됩니다. Docker Community Edition(Docker CE) 의 다음 릴리스는 containerd 버전 1.1을 사용합니다. 물론 CRI 플러그인이 내장되어 있고 기본적으로 활성화되어 있습니다. 즉, 사용자는 Docker 사용자에게 일반적인 다른 용도로 Docker 엔진을 계속 사용할 수 있으며, 동일한 노드에서 Docker 엔진과 함께 제공되고 동시에 사용되고 있는 기본 컨테이너를 사용하도록 Kubernetes를 구성할 수도 있습니다. Docker Engine 및 Kubelet에서 사용되는 동일한 containerd를 보여주는 아래 아키텍처 그림을 참조하십시오.
Containerd는 Kubelet과 Docker Engine 모두에서 사용되기 때문에 containerd 통합을 선택하는 사용자는 새로운 Kubernetes 기능, 성능 및 안정성 향상을 얻을 뿐만 아니라 다른 사용 사례를 위해 Docker Engine을 유지하는 옵션도 갖게 됩니다.
Containerd 네임스페이스 메커니즘은 Kubelet과 Docker Engine이 서로 생성한 컨테이너와 이미지를 보거나 액세스할 수 없도록 보장하기 위해 사용됩니다. 이렇게 하면 서로 간섭하지 않습니다. 이것은 또한 다음을 의미합니다.
- 사용자는 docker ps 명령 을 사용하여 Kubernetes에서 만든 컨테이너를 볼 수 없습니다 . 대신 crictl ps 를 사용하십시오 . 그 반대의 경우도 마찬가지입니다. 사용자는 Kubernetes에서 또는 crictl ps 명령을 사용하여 Docker CLI가 생성한 컨테이너를 볼 수 없습니다. crictl create 및 crictl runp 명령은 문제 해결용입니다. 프로덕션 노드 에서 crictl 을 사용하여 포드 또는 컨테이너를 수동으로 시작하는 것은 권장되지 않습니다.
- 사용자는 docker images 명령 을 사용하여 Kubernetes에서 가져온 이미지를 볼 수 없습니다 . 대신 crictl 이미지 명령을 사용 하십시오 . 그 반대의 경우도 마찬가지입니다. Kubernetes는 docker pull , docker load 또는 docker build 명령으로 생성된 이미지를 볼 수 없습니다. 대신 crictl pull 명령을 사용 하고 이미지를 로드해야 하는 경우 ctr cri load 를 사용하십시오.
최신 Docker 설치는 컨테이너 관리를 담당하는 containerd와 나머지 모든 작업을 담당하는 dockerd의 두 가지 서비스로 나뉩니다 .
OCI 표준은 다양한 컨테이너 솔루션 간의 상호 운용성을 가져왔습니다. 결과적으로 한 시스템에 구축된 이미지는 다른 호환 스택에서 실행할 수 있습니다.
