containerd 이미지

이 페이지에서는 Google Kubernetes Engine(GKE) 노드에서 containerd가 포함된 컨테이너 최적화 OS(cos_containerd)containerd가 포함된 Ubuntu(ubuntu_containerd) 사용에 대한 추가 정보를 제공합니다. cos_containerdubuntu_containerd 이미지를 통해 containerd를 GKE 클러스터의 컨테이너 런타임으로 사용할 수 있습니다.

GKE 클러스터에서 containerd 이미지 사용

새 GKE 클러스터를 만들거나 기존 클러스터에 새 노드 풀을 만들거나 기존 GKE 클러스터를 업그레이드할 때 이미지 유형으로 cos_containerd 또는 ubuntu_containerd를 선택할 수 있습니다. 두 containerd 이미지를 사용하려면 v1.14.3 이상이 필요합니다.

containerd 노드에서 docker 명령어 실행

Docker는 각 containerd 노드에서 계속 사용할 수 있지만 Kubernetes는 컨테이너 런타임으로 containerd를 사용합니다. Docker는 노드에서 Kubernetes 컨테이너를 관리하지 않으므로 Docker 명령 또는 Docker API를 사용하여 컨테이너를 보거나 상호작용할 수 없습니다.

containerd 노드의 컨테이너 문제해결

컨테이너를 조사하거나 문제를 해결하려면 사전 설치된 crictl을 대신 사용합니다. crictl은 CRI(컨테이너 런타임 인터페이스) 사양을 준수하는 모든 런타임 간에 이동할 수 있습니다. crictlcontainerd 및 Docker Engine과 상호작용할 때 권장되는 도구입니다. 자세한 내용은 crictl 사용자 가이드를 참조하세요.

권한 있는 Pod에서 Docker Engine 액세스

일부 사용자는 현재 권한 있는 포드 내의 노드에서 Docker Engine에 액세스할 수 있습니다. Docker에 직접 의존하지 않도록 작업 부하를 업데이트하는 것이 좋습니다. 예를 들어 현재 Docker Engine에서 애플리케이션 로그 또는 모니터링 데이터를 추출할 경우, GKE 시스템 부가기능을 로깅 및 모니터링용으로 대신 사용하는 것이 좋습니다.

이미지 빌드

containerd는 이미지 빌드를 지원하지 않습니다. Kubernetes에서는 이 기능이 지원되지 않기 때문입니다.

Kubernetes는 Kubernetes 범위 외부의 로컬 프로세스에서 사용되는 시스템 리소스를 인식하지 않으며, 리소스를 할당할 때 Kubernetes 제어 영역이 이러한 프로세스를 고려할 수 없습니다. 그 결과 GKE 워크로드에 리소스가 부족해지거나 노드가 불안정해질 수 있습니다. 따라서 로컬 노드에서 명령어를 실행하지 않는 것이 좋습니다. 대신 개별 컨테이너 범위를 벗어난 다른 서비스(예: Cloud Build)를 사용하거나 kaniko와 같은 도구로 이미지를 Kubernetes 워크로드로 빌드하여 이러한 작업을 수행하는 것이 좋습니다.

이러한 대안이 사례에 맞지 않고 위험 요소를 이해하고 있을 경우에는 Docker를 계속 사용하여 이미지를 빌드할 수 있습니다. GKE 클러스터에서 이미지를 사용하려면 먼저 레지스트리에 푸시해야 합니다. Kubernetes는 로컬로 빌드된 이미지를 인식하지 않습니다.

다음 단계

containerd 통합에 대한 자세한 내용은 Kubernetes 1.11 발표를 참조하세요. 그 외 자세한 내용은 containerdCRI 플러그인 문서를 참조하세요.