이 페이지에서는 containerd 컨테이너 런타임, Google Kubernetes Engine(GKE)에서 Docker 지원, containerd를 사용하는 노드 이미지로 마이그레이션해야 하는 간단한 이유에 대해 설명합니다. containerd 노드 이미지로 마이그레이션하는 방법은 Docker에서 containerd 노드 이미지로 마이그레이션을 참조하세요.
개요
Kubernetes 노드는 컨테이너 런타임을 사용해서 포드에서 실행 중인 컨테이너를 시작, 관리, 중지합니다. Kubernetes 프로젝트는 Kubernetes 버전 1.24 이상에서 Docker 런타임에 대한 기본 제공되는 지원을 삭제하고 있습니다. 이를 위해 Kubernetes는 dockershim이라는 구성요소를 삭제하고 있습니다. 이 구성요소는 Docker가 kubelet과 같은 Kubernetes 구성요소와 통신할 수 있게 해줍니다.
새 기본 런타임인 Containerd는 Kubernetes에서 지원되고 여러 프로젝트에서 자주 사용되는 업계 표준 컨테이너 런타임입니다. containerd 런타임은 GKE 기능을 확장할 수 있는 gVisor 및 이미지 스트리밍과 같은 다양한 기능을 구현할 수 있는 레이어 추상화를 제공합니다. 또한 런타임은 Docker 런타임보다 리소스 효율과 보안성이 높은 것으로 간주됩니다.
이러한 변경으로 인해 GKE는 GKE 버전 1.24 이상에서 Docker를 런타임으로 사용하는 노드 이미지를 지원하지 않습니다. 노드 풀에서 Docker 기반 노드 이미지를 사용하거나 Docker 기반 기본 노드 이미지 유형과 함께 노드 자동 프로비저닝을 사용하면 클러스터가 영향을 받습니다.
GKE 버전 1.23 지원 종료일인 2023년 7월 31일 이전에는 GKE는 자동 업그레이드를 일시중지하고 버전 1.24로의 수동 업그레이드를 방지합니다. 이 날짜 이전에 클러스터의 제어 영역을 GKE 버전 1.24 이상으로 업그레이드하려면 노드 자동 프로비저닝 구성과 모든 노드를 containerd 런타임으로 업데이트해야 합니다. 노드 풀을 업그레이드하려면 containerd 런타임을 사용하는 노드 이미지로 마이그레이션해야 합니다.
1.23이 지원 종료되면 GKE는 아직 마이그레이션이 완료되지 않은 클러스터에 대해 1.24로의 수동 제어 영역 업그레이드를 차단 해제하고 보안 및 호환성을 위해 클러스터를 점진적으로 업그레이드하기 시작합니다. GKE가 클러스터를 1.24로 업그레이드하는 방법과 Docker 노드 이미지에서 클러스터를 마이그레이션하기 위해 권장되는 조치에 대한 자세한 내용은 버전 1.23 지원 종료 시 자동 마이그레이션을 참조하세요.
Docker 및 containerd 노드 이미지
Containerd는 Linux의 경우 버전 1.19, Windows의 경우 버전 1.21부터 모든 새 GKE 노드의 기본 런타임으로 지정되었습니다. 하지만 GKE Standard 클러스터도 Docker를 런타임으로 사용하는 노드 이미지를 계속 지원했습니다. 다음 표에서는 GKE 버전 1.24 이상에서 지원되지 않는 Docker 기반 노드 이미지와 이와 상응하는 containerd 이미지를 보여줍니다.
| Docker 런타임 | containerd 런타임 |
|---|---|
Docker를 사용하는 Container-Optimized OS(cos) |
containerd를 사용하는 Container-Optimized OS(cos_containerd) |
Docker를 사용하는 Ubuntu(ubuntu) |
containerd를 사용하는 Ubuntu(ubuntu_containerd) |
Docker를 사용하는 Windows Server LTSC(windows_ltsc) |
containerd를 사용하는 Windows Server LTSC(windows_ltsc_containerd) |
Docker를 사용하는 Windows Server SAC( |
containerd를 사용하는 Windows Server SAC( |
타임라인 및 마일스톤
GKE 버전 1.23에서는 더 이상 다음을 수행할 수 없습니다.
- Docker 기반 노드 이미지를 사용하는 새 클러스터를 만듭니다.
- Docker 기반 노드 이미지가 포함된 새 노드 풀을 기존 클러스터에 추가합니다.
- Docker 기반 노드 이미지로 설정된
--autoprovisioning-image-type플래그를 사용해서 노드 자동 프로비저닝을 사용 설정합니다.
GKE 버전 1.23으로 업그레이드하는 경우 다음을 계속 사용할 수 있습니다.
- 업그레이드 전 생성된 Docker 기반 노드 이미지가 포함된 기존 노드 풀
- Docker 노드 이미지가 포함된 노드 풀에 있는 클러스터 자동 확장 처리
- 업그레이드 전 사용 설정된 경우 Docker 기반 노드 이미지로 설정된
--autoprovisioning-image-type플래그를 사용한 노드 자동 프로비저닝
GKE 버전 1.24에서는 더 이상 다음을 수행할 수 없습니다.
- 제어 영역이 버전 1.24를 실행하는 경우
--autoprovisioning-image-type플래그가 Docker 기반 노드 이미지로 설정된 상태에서 노드 자동 프로비저닝을 사용할 수 없습니다. - 노드 풀이 버전 1.24를 실행하는 경우 노드에서 Docker 기반 노드 이미지를 사용할 수 없습니다.
다음 표에서는 새로운 GKE 버전과 상호작용할 때 예상되는 변경사항을 요약해서 보여줍니다.
| 작업 | GKE 버전 1.23 | GKE 버전 1.24 |
|---|---|---|
| Docker를 사용하여 새 클러스터 만들기 | 아니요 | 아니요 |
| Docker를 사용하여 새 노드 풀 만들기 | 아니요 | 아니요 |
| Docker를 사용하여 노드 자동 프로비저닝 사용 설정 | 아니요 | 아니요 |
| 기존 Docker 노드 자동 프로비저닝 구성을 사용하여 이전 버전에서 업그레이드 | 예 | 아니요 |
| Docker 기반 노드 이미지 사용 | 예 | 아니요 |
버전 1.23 지원 종료 시 자동 마이그레이션
버전 1.23이 2023년 7월 31일에 지원 종료되기 전에 버전 1.24로 업그레이드하지 않고 containerd 노드 이미지로 마이그레이션하는 경우 GKE는 시간에 따라 다음을 수행합니다.
클러스터에서 Docker 기반 기본 노드 이미지 유형과 함께 노드 자동 프로비저닝을 사용하는 경우 GKE는 containerd 런타임을 사용하는 해당 노드 이미지를 사용하도록 구성을 업데이트합니다. 유지보수 제외로 이 작업을 차단할 수 없습니다. 워크로드에 부정적인 영향이 없는지 확인하려면 GKE에서 구성을 자동으로 업데이트하기 전에 노드 자동 프로비저닝 기본 이미지 유형을 containerd 기반 이미지로 수동 업데이트하는 것이 좋습니다.
GKE는 클러스터의 제어 영역을 버전 1.24로 업그레이드합니다.
GKE에서는 2023년 9월 1일부터 Docker를 사용하는 모든 노드 풀을 containerd 노드 이미지로 마이그레이션합니다. 이 날짜 전에 노드 이미지를 수동으로 마이그레이션하는 것이 좋습니다. 또는 GKE가 containerd 이미지를 사용하도록 클러스터를 마이그레이션하는 작업을 시작하도록 요청할 수 있습니다. 이 요청을 수행하려면 Cloud Customer Care에 문의하세요.
자동 마이그레이션을 일시적으로 차단하려면 클러스터를 버전 1.24 이상으로 업그레이드하고 유지보수 제외를 구성합니다. 이 유지보수 제외에 대한 자세한 내용은 containerd 노드 이미지로의 자동 마이그레이션 일시 지연을 참조하세요.
GKE는 클러스터 상태를 오픈소스 버전 차이 정책에 맞게 조정하기 위해 지원되지 않는 버전과 마찬가지로 버전 1.23의 노드 풀을 1.24로 업그레이드합니다. 자세한 내용은 GKE 부 버전 수명 주기를 참조하세요. 유지보수 제외를 사용하여 이 업그레이드를 일시적으로 차단할 수 있습니다.
containerd 노드 이미지로 자동 마이그레이션 일시 지연
클러스터의 제어 영역이 1.24 이상으로 업그레이드된 후 버전 1.25가 지원 종료될 경우 2024년 2월 29일까지 노드가 일시적으로 마이그레이션되지 않도록 유지보수 제외를 구성할 수 있습니다.
이 유지보수 제외를 사용하려면 클러스터를 출시 채널에 등록해야 합니다.
"마이너 또는 노드 업그레이드 없음" 범위로 유지보수 제외를 구성하고 --add-maintenance-exclusion-end 플래그를 2024-02-29T00:00:00Z 또는 이전으로 설정합니다. 가능한 한 빨리 마이그레이션을 차단 해제하고 노드가 버전 1.24로 업그레이드되도록 하는 것이 좋습니다. 지원 종료된 마이너 버전은 더 이상 보안 패치 및 버그 수정이 제공되지 않습니다.
Docker에서 containerd 노드 이미지로 마이그레이션
Docker 기반 노드 이미지를 사용하여 클러스터와 노드 풀을 식별하고 해당 노드 풀을 containerd 노드 이미지로 마이그레이션하려면 Docker에서 containerd 노드 이미지로 마이그레이션을 참조하세요.
GKE 공유 책임 모델의 일부로, 워크로드의 상태를 유지하는 것은 고객의 책임이고 지원되는 버전의 실행을 포함하여 클러스터가 계속 작동하도록 보장하는 것은 Google의 책임입니다. GKE가 자동으로 수행하기 전에 워크로드를 테스트하고 클러스터를 마이그레이션하는 것이 좋습니다.
1.23이 지원 종료되기 전에 GKE는 Docker 노드 이미지를 사용하는 노드 풀이 있는 클러스터에 대해 1.24로의 자동 또는 수동 업그레이드를 방지합니다. containerd 이미지만 사용하도록 클러스터를 마이그레이션한 후 GKE 출시 일정에 따라 하루 내에 자동 업그레이드를 재개하거나 클러스터를 수동으로 업그레이드할 수 있습니다.
1.23이 지원 종료되면 GKE는 1.24로의 자동 또는 수동 업그레이드를 차단 해제하고 자동 마이그레이션 프로세스를 따릅니다.
마이그레이션의 영향
containerd 노드 이미지로 마이그레이션할 때 기본 변경사항은 Docker가 더 이상 컨테이너 시작 및 중지 등의 수명 주기를 관리하지 않는다는 것입니다. 따라서 Docker 명령어 또는 Docker API를 사용해서 containerd 이미지를 사용하는 노드에서 실행되는 GKE 컨테이너를 보고 상호작용할 수 없습니다.
대부분의 사용자 워크로드에는 컨테이너 런타임에 대한 종속 항목이 없습니다. Docker 런타임은 또한 containerd를 구현하므로 워크로드가 containerd 노드 이미지에서 비슷하게 작동합니다.
다음 상황에 해당하는 경우 영향을 받을 수 있습니다.
- Docker 명령어를 수행하는 권한이 있는 포드를 실행합니다.
- Kubernetes 인프라 외부의 노드에서 스크립트를 실행합니다(문제 해결을 위한 ssh 사용 등).
- 비슷하게 권한이 있는 작업을 수행하는 타사 도구를 실행합니다.
- 일부 도구가 모니터링 시스템에서 Docker 관련 로그에 반응합니다.
- 외부 공급업체에서 제공되는 로깅, 모니터링, 보안, 지속적 통합 도구를 GKE 클러스터에 배포합니다. 영향을 확인하려면 해당 공급업체에 문의하세요.
다음 상황에서는 영향을 받지 않습니다.
- GKE 클러스터 외부에서 Docker를 사용해서 컨테이너 이미지를 빌드 및 푸시하는 빌드 파이프라인이 있습니다.
- GKE 클러스터에서
docker build및docker push명령어를 사용합니다. containerd를 사용하는 Linux 노드 이미지는 Docker 바이너리를 포함하고 이러한 명령어를 지원합니다.
권한이 있는 포드를 사용하여 Docker 액세스
사용자가 권한이 있는 포드를 사용해서 노드에 있는 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 노드에 대한 로그를 확인할 수 있습니다.
문제 해결
문제 해결을 위해서는 containerd 런타임 문제 해결을 참조하세요.