이 페이지에서는 Google Kubernetes Engine(GKE) 노드에서 containerd를 컨테이너 런타임으로 사용하는 노드 이미지에 대한 정보를 제공합니다.
containerd 정보
컨테이너 런타임은 컨테이너를 실행할 책임이 있는 소프트웨어이며 Kubernetes의 컨테이너 관리를 추상화합니다. 컨테이너 런타임은 여러 가지가 있습니다.
containerd 런타임은 Kubernetes에서 지원되고 여러 프로젝트에서 자주 사용되는 업계 표준 컨테이너 런타임입니다. containerd 런타임은 GKE 기능을 확장할 수 있는 gVisor 및 이미지 스트리밍과 같은 다양한 기능을 구현할 수 있는 레이어 추상화를 제공합니다.
containerd 런타임은 Docker 런타임보다 리소스 효율과 보안성이 높은 것으로 간주됩니다.
GKE 클러스터에서 containerd 이미지 사용
새 GKE 클러스터 또는 기존 클러스터에 새 노드 풀을 만들거나 기존 클러스터를 업그레이드할 때 containerd 노드 이미지를 사용하도록 선택할 수 있습니다. GKE Autopilot 클러스터는 항상 containerd를 포함한 Container-Optimized OS를 사용합니다.
다음 표에서는 클러스터 모드 및 노드 풀 OS에 따라 지원되는 containerd 노드 이미지를 보여줍니다.
사용자가 권한이 있는 포드를 사용해서 노드에 있는 Docker Engine에 액세스하는 경우 Docker에서 직접 의존하지 않도록 해당 워크로드를 업데이트해야 합니다. 예를 들어 Docker Engine에서 GKE 시스템 부가기능으로 로깅 및 모니터링 추출 프로세스를 마이그레이션할 수 있습니다.
containerd를 사용하여 컨테이너 이미지 빌드
containerd를 사용해서 컨테이너 이미지를 빌드할 수는 없습니다. containerd가 있는 Linux 이미지에는 Docker 바이너리가 포함되므로 Docker를 사용해서 이미지를 빌드하고 푸시할 수 있습니다. 하지만 개별 컨테이너 및 로컬 노드를 사용해서 이미지 빌드 명령어를 실행하는 것은 권장되지 않습니다.
Kubernetes는 Kubernetes 범위 외부의 로컬 프로세스에서 사용되는 시스템 리소스를 인식하지 않으며, 리소스를 할당할 때 Kubernetes 컨트롤 플레인이 이러한 프로세스를 고려할 수 없습니다. 그 결과 GKE 워크로드에 리소스가 부족해지거나 노드가 불안정해질 수 있습니다.
개별 컨테이너 범위를 벗어난 다른 서비스(예: Cloud Build)를 사용하거나 kaniko와 같은 도구로 이미지를 Kubernetes 워크로드로 빌드하여 이러한 작업을 수행하는 것이 좋습니다.
이러한 대안이 사례에 맞지 않고 위험 요소를 이해하고 있을 경우에는 로컬 노드에서 Docker를 계속 사용하여 이미지를 빌드할 수 있습니다. GKE 클러스터에서 사용할 수 있으려면 먼저 레지스트리에 이미지를 푸시해야 합니다.
containerd가 있는 Kubernetes에는 Docker를 사용하여 로컬로 빌드된 이미지가 인식되지 않습니다.
containerd 노드에서 컨테이너 디버깅
Linux 노드에서 디버깅 또는 문제 해결을 위해 개발자는 Kubernetes 컨테이너 런타임용으로 빌드된 간이 명령줄 도구인 crictl을 사용하여 containerd와 상호작용할 수 있습니다. crictl은 컨테이너 및 이미지 보기, 로그 읽기, 컨테이너에서 명령어 실행을 수행하는 일반 기능을 지원합니다. 지원되는 전체 기능 및 사용 정보는 crictl 사용자 가이드를 참조하세요.
Windows Server 노드의 경우 containerd 데몬이 containerd라는 이름의 Windows 서비스로 실행됩니다.
로그가 다음과 같이 제공됩니다.
Windows: C:\etc\kubernetes\logs\containerd.log
Linux: journalctl -u containerd 실행
또한 LOG NAME: "container-runtime" 아래의 로그 탐색기에서 Windows 및 Linux 노드에 대한 로그를 확인할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-01(UTC)"],[],[],null,["# Containerd node images\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page provides information about node images that use [containerd](https://containerd.io/)\nas the container runtime in your Google Kubernetes Engine (GKE) nodes.\n| **Note:** In GKE version 1.19 and later, the default node image for Linux nodes is Container-Optimized OS with containerd (`cos_containerd`). If you use a Docker node image type, [migrate to the containerd runtime](/kubernetes-engine/docs/how-to/migrate-containerd).\n\nAbout containerd\n----------------\n\nThe [container runtime](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)\nis software that is responsible for running containers, and abstracts\ncontainer management for Kubernetes. There are a few different container\nruntimes.\n\nThe [containerd](http://containerd.io) runtime is an industry-standard\ncontainer runtime that's supported by Kubernetes, and used by many\nother projects. The containerd runtime provides the layering abstraction that\nallows for the implementation of a rich set of features like\n[gVisor](https://gvisor.dev/) and [Image streaming](/kubernetes-engine/docs/how-to/image-streaming)\nto extend GKE functionality.\n\nThe containerd runtime is considered more resource efficient and secure than the\nDocker runtime.\n\nUsing containerd images in GKE clusters\n---------------------------------------\n\nWhen you create a new GKE cluster, a new node pool in an existing\ncluster, or when you upgrade an existing cluster, you can choose to use a\ncontainerd node image. GKE Autopilot clusters always use\nContainer-Optimized OS with containerd.\n\nThe following table describes the supported containerd node images based on your\n[cluster mode](/kubernetes-engine/docs/concepts/types-of-clusters#modes) and node\npool OS:\n\nUsing privileged Pods to access Docker\n--------------------------------------\n\nIf your users access Docker Engine on a node using a privileged Pod, you should\nupdate those workloads so that there's no direct reliance on Docker. For\nexample, consider migrating your logging and monitoring extraction process from\nDocker Engine to GKE system add-ons.\n\nBuilding container images with containerd\n-----------------------------------------\n\nYou **cannot** use containerd to build container images. Linux images with\ncontainerd include the Docker binary so that you can use Docker to build and\npush images. However, we don't recommend using individual containers and local\nnodes to run commands to build images.\n\nKubernetes is not aware of system resources used by local processes outside the\nscope of Kubernetes, and the Kubernetes control plane cannot account for those\nprocesses when allocating resources. This can starve your GKE\nworkloads of resources or cause instability on the node.\n\nConsider accomplishing these tasks using other services outside the scope of the\nindividual container, such as [Cloud Build](/build), or use a tool such as\n[kaniko](/blog/products/containers-kubernetes/introducing-kaniko-build-container-images-in-kubernetes-and-google-container-builder-even-without-root-access)\nto build images as a Kubernetes workload.\n\nIf none of these suggestions work for you, and you understand the risks, you can\ncontinue using Docker on the local node to build images. You must push the\nimages to a registry before you can use them in a GKE cluster.\nKubernetes with containerd is unaware of images locally-built using Docker.\n\nDebugging containers on containerd nodes\n----------------------------------------\n\nFor debugging or troubleshooting on Linux nodes, you can interact with\ncontainerd using the portable command-line tool built for Kubernetes container\nruntimes: `crictl`. `crictl` supports common functionalities to view containers\nand images, read logs, and execute commands in the containers. Refer to the\n[crictl user guide](https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl)\nfor the complete set of supported features and usage information.\n\nFor Windows Server nodes, the containerd daemon runs as a Windows service\nnamed `containerd`.\n\nLogs are available as follows:\n\n- Windows: `C:\\etc\\kubernetes\\logs\\containerd.log`\n- Linux: run `journalctl -u containerd`\n\nYou can also view logs for Windows and Linux nodes in [Logs Explorer](/logging/docs/view/logs-explorer-interface)\nunder `LOG NAME: \"container-runtime\"`.\n\nKnown issues and troubleshooting\n--------------------------------\n\nFor troubleshooting and for known issues with workarounds, refer to\n[Troubleshooting the container runtime](/kubernetes-engine/docs/troubleshooting/container-runtime).\n\nWhat's next\n-----------\n\n- Learn more about the containerd integration in the [Kubernetes 1.11 announcement](https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/). For even more information, visit the documentation for [containerd](https://github.com/containerd/containerd) and the [CRI plugins](https://github.com/containerd/containerd/blob/master/docs/PLUGINS.md).\n- Review the migration from Dockershim information on [kubernetes.io](https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/).\n- Read about [Dockershim deprecation by Kubernetes](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2221-remove-dockershim/README.md).\n- Learn how you can secure your apps with [gVisor](/blog/products/containers-kubernetes/how-gvisor-protects-google-cloud-services-from-cve-2020-14386) on containerd.\n- Read about the benefits of using [Cloud Build](/build) to build images securely and reliably on Google Cloud to replace a custom solution that might require Docker.\n- [Customize your containerd configuration in GKE nodes](/kubernetes-engine/docs/how-to/customize-containerd-configuration)."]]
