[Kubernetes] CRI-O 에 관하여

 최근에 기회가 생겨서 CRI-O 코드를 볼 수 있는 기회가 생겨서 코드를 약간 보았습니다. 

 

그러면서 아직 더 깊이 보지 못했지만 대략의 구조를 볼 수 있게 되었고 이를 통해서 더 많은 이해를 할 수 있었습니다. 

 

그래서 CRI-O 가 하는 역할에 대해서 간략하지만 이해를 도울 수 있는 내용을 다루어 보겠습니다. 

 

tag v1.30.0 를 기준으로 이 글을 작성했습니다. 

https://github.com/cri-o/cri-o/tree/v1.30.0

GitHub - cri-o/cri-o: Open Container Initiative-based implementation of Kubernetes Container Runtime Interface

 

 

1. CRI 

 

https://kubernetes.io/docs/concepts/architecture/cri/

Container Runtime Interface (CRI)

 

" The CRI is a plugin interface which enables the kubelet to use a wide variety of container runtimes, without having a need to recompile the cluster components"

 

즉 CRI 는 kubelet 으로 하여금 container runtime 을 사용할 수 있게 하는 플러그인 인터페이스 라고 볼 수 있습니다. 

 

조금 더 간단하게 이야기 하자면 Kubernetes 은 container orchestration 툴인거지 실제적으로 컨테이너를 만드는 요소들은 container runtime 이라고 봐야 할것입니다. 

여기서 말하는 container runtime 이란 

* containerd

* CRI-O

* Docker Engine 

* Mirantis Container Runtime 

 

이 있습니다. 

https://kubernetes.io/docs/setup/production-environment/container-runtimes/

Container Runtimes

 

우리는 여기서 CRI-O 를 주목 해볼 것입니다.

 

2. CRI-O 

 

https://cri-o.io/

cri-o

 

 

"CRI-O is an implementation of the Kubernetes CRI (Container Runtime Interface) to enable using OCI (Open Container Initiative) compatible runtimes"

 

즉 kubelet 에서 CRI 가 OCI 호환가능 runtime 을 사용할 수 있게 하는 implementation 이다. 

 

즉 CRI 는 CRI-O 를 통해 실제 컨테이너 생성, 제거, 정지 등 여러 작업을 실행합니다. 

 

그렇다면 CRI-O 는 어떻게 생겼을까요? 

 

cri-o 구조

CRI-O 는 위와 같은 구조를 가지고 있다고 설명이 되어 있는데 사실 한눈에 다 알기는 어렵습니다. 

 

사용자 입장에서는 결국 Kubelet 과 통신하고 runtime service ( container 생성, 제거, 정지 등 에 관련된 ) , image service ( container image 관련되 ) 서비스들을 제공한다고 알면 편할것입니다.

물론 더 많은 내용이 있고 그 안은 더 복잡한 코드가 존재하지만 우선 저 두가지를 한다고 보시면 될거 같습니다. 

 

그래서 실제로 확인 해보면 OCI spec 을 이용해서 컨테이너 생성이 가능한 runc 와 같은 툴을 사용하고 있다고 보시면 될거 같습니다. 

 

그렇다면 그 과정은 어떻게 진행이 될까요? 

 

실제 과정은 CRI-O 에서는 아래와 같이 설명 하고 있습니다. 

 

3. CRI-O 에서 컨테이너 생성 과정

The architectural components are as follows:

• Kubernetes contacts the kubelet to launch a pod.
  • Pods are a kubernetes concept consisting of one or more containers sharing the same IPC, NET and PID namespaces and living in the same cgroup.
• The kubelet forwards the request to the CRI-O daemon VIA kubernetes CRI (Container runtime interface) to launch the new POD.
• CRI-O uses the containers/image library to pull the image from a container registry.
• The downloaded image is unpacked into the container’s root filesystems, stored in COW file systems, using containers/storage library.
• After the rootfs has been created for the container, CRI-O generates an OCI runtime specification json file describing how to run the container using the OCI Generate tools.
• CRI-O then launches an OCI Compatible Runtime using the specification to run the container proceses. The default OCI Runtime is runc.
• Each container is monitored by a separate conmon process. The conmon process holds the pty of the PID1 of the container process. It handles logging for the container and records the exit code for the container process.
• Networking for the pod is setup through use of CNI, so any CNI plugin can be used with CRI-O.

 

• Kubernetes  가 Kubelet 으로 하여금 pod 를 실행시키게 합니다. 
  • Pod 는 Kuberentes 의 가정 기본 구성 단위입니다, 하나 이상의 컨테이너가 존재 하면서 같은 IPC, NET 그리고 PID namespace 를 공유하고 있고 같은 cgroup 위에 있습니다. 
• Kubelet 은 새로운 Pod 를 시작하기 위해 요청을 Kubernetes CRI ( Container Runtime Interface ) 를 통해 CRI-O daemon 으로 보내줍니다.
• CRI-O 는 container/image library 를 활용해서 container registry ( container 이미지를 저장하는 장소 ) 에서 이미지를 불러 옵니다. ( pull ) 
• 다운로드 ( Download ) 된 이미지는 Container/storage library 를 활용해서 COW ( copy on write ) 파일 시스템 위에 작성되어 있는 Container 의 루트 파일 시스템에 압축을 풉니다.
• Container 에 rootfs 가 생성된 이후 CRI-O 는 OCI 를 활용해서 container 를 실행시키는 것에 대해서 적혀 있는 OCI runtime specification json 파일을 만들어냅니다.
• CRI-O 는 Container 프로세스를 실행시키기 위해서 specification 을 활용해서 OCI 호환 되는 runtime 을 실행 시킵니다. 기본적인 OCI runtime 은 runc 입니다. 
• 각각의 Container 는 별도의 common 프로세스로 모니터링 됩니다. common 프로세스는 Container 프로세스의 PID1 의 pty 를 보유 합니다. Container 에 대한 logging 을 처리하고 Container 프로세스에 대한 종료 코드를 기록합니다. Pod networking 은 CNI ( Container Network Interface )를 사용하여 설정 되므로 모든 CNI  플로그인을 CRI-O 와 함께 사용하실 수 있습니다.

제가 번역에 재능이 없어서 우선은 했지만 약간의 설명을 보태자면 

• pty

crio container pty는 CRI-O로 실행되는 컨테이너 내에서 pseudo-terminal(가상 터미널)을 설정하고 사용할 수 있는 기능을 의미합니다. 이를 통해 사용자는 CRI-O 컨테이너 내부에서 직접 명령어를 실행하고, 디버깅하거나, 로그를 실시간으로 볼 수 있습니다. 이러한 기능은 특히 컨테이너의 상태를 점검하거나 문제를 해결하는 데 유용합니다.

CRI-O 는 Daemon 으로써 Kubelet 의 요청을 받아 들이고 이후 OCI 호환 가능한 runtime, CNI 를 활용해서  container 를 생성 및 그에 필요한 것들을 설정해주는 역할을 하고 있습니다. 

 

그래서 다음 글에서 목표는 

• Kubelet 의 요청을 받아 들이는 grpcServer 코드에 대한 간략한 요약 
• 실제 runc 명령어를 실행하기 위한 crioServer 가 존재하는데 이것은 어떻게 되어 있는지 

이렇게 살펴볼 예정입니다. 

물론 제가 아직 많이 부족해서 두개다 볼 수 없을 수 있지만 최대한 잘 작성해서 오도록 하겠습니다. 

 

부족한 글을 읽어주셔서 감사하고 틀린 내용, 오타가 있으면 언제든지 말씀해주시는데로 수정할 수 있도록 하겠습니다. 

 

 

[reference]

https://github.com/containers/storage

GitHub - containers/storage: Container Storage Library

https://github.com/containers/image

https://github.com/opencontainers/runc

https://kubernetes.io/docs/setup/production-environment/container-runtimes/

Container Runtimes

https://github.com/cri-o/cri-o/tree/v1.30.0

GitHub - cri-o/cri-o: Open Container Initiative-based implementation of Kubernetes Container Runtime Interface

https://kubernetes.io/docs/concepts/architecture/cri/

Container Runtime Interface (CRI)

https://cri-o.io/