containerd를 포함한 컨테이너 최적화 OS 사용

이 페이지에서는 Google Kubernetes Engine(GKE) 노드에서 containerd가 포함된 컨테이너 최적화 OS(cos_containerd) 사용에 대한 추가 정보를 제공합니다. cos_containerd 이미지는 containerd CRI 런타임 환경에 대한 액세스 권한을 제공합니다.

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

cos_containerd OS 이미지는 GKE v1.11 이상에서 베타 기능으로 제공됩니다. 새 GKE 클러스터를 만들 때, 기존 클러스터에서 새 노드 풀을 만들 때 또는 기존 GKE 클러스터를 v1.11 이상으로 업그레이드할 때 cos_containerd를 이미지 유형으로 선택할 수 있습니다.

베타 기간 동안 고객의 의견을 수집하고 있습니다.

현재까지는 cos_containerd는 COS(Container-Optimized OS) 이미지에만 사용할 수 있습니다.

GKE 노드에서 docker 명령어 실행

GKE v1.11 이상에서는 각 노드에서 Docker를 사용할 수 있지만, containerd가 기본 런타임입니다. 하지만 Docker는 노드에서 Kubernetes 컨테이너를 관리하지 않으므로, Docker 명령어 또는 Docker API를 사용하여 컨테이너를 보거나 상호작용할 수 없습니다.

GKE 노드에서 컨테이너 문제해결

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

권한 있는 포드에서 Docker Engine 액세스

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

이미지 빌드

이미지 빌드는 Kubernetes 자체에서 지원되지 않기 때문에 containerd에서 지원되지 않습니다.

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

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

다음 단계

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

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Kubernetes Engine 문서