이 글은 아래 자료를 참고하여 작성되었습니다.
Udemy [Certified Kubernetes Administrator (CKA) with Practice Tests]
1. Kubernetes History
1-1. Docker와 Kubernetes의 초기 관계
- Docker는 초기 컨테이너 도구로, 간단한 사용자 경험 덕분에 시장을 지배하게 되었다.
- Kubernetes는 Docker의 컨테이너를 오케스트레이션하기 위해 설계되었으며, 초기에는 Docker와 강하게 결합되어 작동했다.
1-2. Kubernetes와 CRI(Container Runtime Interface)
- Kubernetes가 성장하면서 Docker 외에도 다양한 컨테이너 런타임을 지원할 필요성이 대두되었다.
- 이를 위해 Kubernetes는 CRI(Container Runtime Interface)를 도입하여 OCI(Open Container Initiative) 표준을 준수하는 다양한 컨테이너 런타임을 지원할 수 있게 되었다.
1-3. Docker의 역할 변화와 Containerd의 등장
- Docker는 CRI 표준 이전에 개발되었으므로 CRI를 지원하지 않았다. 이를 해결하기 위해 Kubernetes는 Docker를 지원하기 위한 임시 해결책으로 dockershim을 도입했다.
- Docker는 Docker CLI, DockerAPI, Build Tools, Volume, Auth & Security, Container Runtime(runC), Container Runtime Daemon(containerd)이 모두 결합된 종합적인 툴셋인데, 이 중 containerd가 독립적인 프로젝트로 분리되어 CRI 호환 가능한 런타임으로 발전했다.
- Kubernetes 1.24 버전에서 dockershim이 제거되었고, Docker는 Kubernetes의 공식 런타임으로서 지원이 종료되었다. 그러나 Docker 이미지 자체는 여전히 OCI 표준을 준수하기 때문에 Containerd에서 계속 사용할 수 있다.
2. OCI와 Container Runtime
2-1. OCI란?
OCI는 컨테이너 기술의 표준을 정의하는 오픈 소스 프로젝트로, 다양한 컨테이너 플랫폼이 일관된 방식으로 컨테이너를 빌드, 실행, 배포할 수 있도록 표준을 제공한다. Docker가 컨테이너 기술의 대중화를 이끌면서, 이 기술을 표준화하여 호환성을 높이기 위해 2015년에 시작되었다.
2-2. OCI의 주요 구성 요소
- OCI 이미지 사양 (OCI Image Specification):
- 컨테이너 이미지 형식에 대한 표준
- Docker 이미지와 같은 컨테이너 이미지를 다양한 런타임에서 동일하게 사용할 수 있도록 규격을 정의한다.
- 이를 통해 하나의 이미지가 여러 플랫폼에서 호환되어 실행될 수 있다.
- OCI 런타임 사양 (OCI Runtime Specification):
- 컨테이너 실행을 위한 표준
- 컨테이너를 시작하고, 격리하고, 자원을 관리하는 방법을 정의
- 이 규격을 준수하는 저수준 런타임은 컨테이너의 시작, 중지, 리소스 격리 등을 처리한다.
2-3. 저수준 런타임과 OCI 표준
- runC는 OCI 표준을 준수하는 대표적인 저수준 컨테이너 런타임. runC는 컨테이너의 실제 실행을 담당하며, 리눅스 커널의 네임스페이스와 cgroups 같은 기능을 사용해 프로세스 격리와 자원 관리를 처리한다.
- 기타 저수준 런타임: Kata Containers, gVisor, Firecracker 같은 다른 저수준 런타임들도 OCI 런타임 사양을 준수하도록 설계되었다. 이러한 런타임들은 각기 다른 방식으로 컨테이너를 실행하고 격리하지만, 모두 OCI 표준을 따르기 때문에 Kubernetes나 containerd 같은 고수준 시스템과 함께 작동할 수 있다.
2-4. 고수준 런타임과 OCI 표준
- 고수준 런타임(예: containerd, CRI-O)은 OCI 표준을 직접적으로 준수하지 않더라도, 이 표준을 따르는 저수준 런타임과 연동하여 컨테이너 전체 라이프사이클을 관리한다.
- 고수준 런타임의 역할: 고수준 런타임은 컨테이너 생성, 네트워킹 설정, 스토리지 관리, 이미지 풀링 등의 작업을 수행하며, 저수준 런타임을 호출하여 실제 컨테이너 실행을 처리한다.
- OCI 준수의 간접적 역할: 고수준 런타임은 자체적으로 OCI 표준을 따르지 않더라도, OCI 표준을 준수하는 저수준 런타임(runC 등)을 호출하여 컨테이너를 실행한다. 이를 통해 고수준 런타임도 결과적으로 OCI 표준에 따라 컨테이너를 관리할 수 있게 된다.
3. CLI 도구들: ctr, nerdctl, crictl
ctr | nedrctl | crictl | |
Purpose | Debugging | General Purpose | Debugging |
Community | ContainerD | ContainerD | Kubernetes |
Works With | ContainerD | ContainerD | All CRI Compatible Runtimes |
- ctr: Containerd에 포함된 기본 CLI 도구로, 주로 디버깅을 목적으로 만들어졌다. 사용하기에 친화적이지 않고, 제한된 기능만 제공됩니다. 사용자 친화적이지 않으며, 프로덕션 환경에서 컨테이너를 실행하고 관리하는 데는 적합하지 않다.
- nerdctl: Docker와 유사한 CLI 도구로, Containerd를 사용해 컨테이너를 더 쉽게 관리할 수 있도록 설계되었다. 대부분의 Docker 명령어를 대체할 수 있으며, 최신 Containerd 기능에 접근할 수 있다.
- crictl: Kubernetes에서 사용되는 CRI 호환 런타임과 상호작용하기 위한 CLI 도구. Kubernetes 환경에서 디버깅을 위한 용도로 사용된다.
- 주의점
- kubelet은 Kubernetes 클러스터에서 컨테이너와 Pod의 전체 상태를 관리하는 주요 컴포넌트로, 각 노드에서 Pod의 상태와 컨테이너의 라이프사이클을 책임지며 컨테이너가 특정 상태에 있지 않거나 kubelet이 생성하지 않은 컨테이너가 발견되면 이를 제거하거나 재시작하는 등의 작업을 수행한다.
- Kubernetes는 상태 선언적(Declarative) 방식으로 Pod 및 컨테이너를 관리한다. kubelet은 Kubernetes API 서버로부터 받은 지시사항에 따라 컨테이너를 생성하고 관리하는데, crictl을 사용하면 이 상태 관리 흐름을 우회하게 된다. crictl을 사용하여 컨테이너를 생성하거나 조작하면 Kubernetes API 서버 및 kubelet과의 상호작용이 일어나지 않기 때문에, Kubernetes는 해당 컨테이너의 상태를 모르게 되고, 결과적으로 Kubernetes의 상태 관리와 충돌할 수 있으며 kubelet이 해당 컨테이너를 정리하거나 무시할 수 있다.
- 따라서 crictl은 디버깅 목적으로만 사용해야 하며, 프로덕션 환경에서 컨테이너를 생성하거나 관리하는 데 사용해서는 안 된다.
- 주의점
더보기
crictl 명령어 정리
# 현재 노드에서 실행 중인 컨테이너 목록을 확인
crictl ps
# 종료된 컨테이너를 포함하여 모든 컨테이너 목록을 확인
crictl ps -a
# 노드에 저장된 모든 이미지 목록을 확인
crictl images
# 특정 이미지를 레지스트리에서 다운로드
crictl pull [이미지 이름]
# 종료된 컨테이너 시작
crictl start [컨테이너 ID]
# 실행중인 컨테이너 중지
crictl stop [컨테이너 ID]
# 특정 컨테이너 삭제
crictl rm [컨테이너 ID]
# 특정 컨테이너 로그확인
crictl logs [컨테이너 ID]
# 특정 컨테이너의 상세정보 확인
crictl inspect [컨테이너 ID]
# pod 목록 확인
crictl pods
# 실행중인 pod 중지
crictl stopp [Pod ID]
# 특정 pod 삭제 (Pod과 관련된 모든 리소스 삭제됨)
crictl rmp [Pod ID]
# 특정 컨테이너에서 명령 실행
crictl exec -it [컨테이너 ID] [명령어]
4. Kubernetes에서의 Docker와 Containerd
- Kubernetes 1.24 버전 이후, Docker는 공식적으로 지원되지 않으며, Containerd와 같은 CRI 호환 런타임이 권장된다.
- Docker의 CLI 명령어들은 nerdctl로 대체 가능하며, Kubernetes 환경에서는 crictl이 주로 사용된다.
'Kubernetes' 카테고리의 다른 글
17. Core Concepts - Kube API Server (1) | 2024.09.20 |
---|---|
16. Core Concepts - ETCD (0) | 2024.09.19 |
14. Tips - Imperative vs Declarative (0) | 2024.09.12 |
13. Core Concepts - Namespace (2) | 2024.09.11 |
12. Tips - create YAML (0) | 2024.09.11 |