[Cloud] 쿠버네티스(Kubernetes, k8s) 소개

 Kubernetes란 컨테이너로 구성된 서비스를 관리하기 위한 오픈 소스 플랫폼입니다. 지난 시간에 포스팅한 Container Orchestrator의 일종으로 구글의 GO 언어로 만들어졌습니다. 다양한 플러그인과 결합하는 특성으로 확장성과 이식성에 뛰어나다는 장점이 있습니다. 다른 Container Orchestrator들이 있지만, 위와 같은 장점들 때문에 업계 표준으로 자리매김하였습니다.

쿠버네티스, Kubernetes, k8s

 

 Kubernetes의 동작 과정

Kubernetes의 work flow

 쿠버네티스는 kubectl 명령어로 api server에 pod 생성을 요청합니다. -> controller-manager과 scheduler에서 pod 생성 여부를 확인합니다. -> 생성된 pod가 없는 경우에 api server는 kubelet에 pod 생성 요청을 전달합니다. -> api server에서 pod 생성 확인 요청을 합니다. -> CRI를 통해 컨테이너를 생성합니다.

 

 그렇다면, CRI는 무엇일까요?

 

 CRI란 쿠버네티스는 컨테이너 런타임을 플러그처럼 교체 가능한 방법을 제공하기 위해 CRI(Container Runtime Interface) API의 개념을 적용하였습니다. CRI를 사용하여 컨테이너를 관리하고 OCI 표준을 따르는 컨테이너 런타임은 쿠버네티스에서 사용할 수 있습니다. 즉, CRI는 컨테이너를 실행하고 관리하는 API입니다. CRI의 대표로는 유명한 Docker, containerd, rkt, cri-o, gVistor 등이 있습니다.

CRI의 work flow

Docker : Docker는 유연하고 배포가 쉬운 Linux 기반의 컨테이너 기술입니다. 현재 컨테이너 런타임의 표준이며, CRI 뿐만 아니라 Docker hub에서 이미지 관리 등의 역할을 하고 있습니다. 초기의 Linux 기반의 LXC로 컨테이너 관리를 하였으나, 현재는 containerd와 runc를 기반으로 동작합니다. 서버-클라이언트 아키텍처로 REST API(HTTP API 기반)을 통해 조작이 가능하고 CLI 명령어로 개발자들이 접근할 수 있습니다.

->즉, 다수 사용자가 사용하고, 가장 성숙한 런타임과 수많은 생태계를 사용할 수 있습니다.

 

containerd : Docker의 컨테이너 런타임 부분을 독립적인오픈 소스 프로젝트인 Containerd로 분리하였고, 컨테이너 표준인 OCI 기준으로 구현하였습니다. containerd는 컨테이너를 실행하고, runc (노드에서 이미지를 관리하는데 최소한의 기능) OCI 호환 컨테이너 런타임입니다.

->즉, 가볍게 사용할 수 있지만 요즘 사용하지 않는 런타임입니다.

 

CRI-O : CRI-O는 Docker보다 가벼운 컨테이너 런타임으로 쿠버네티스 자원을 지향합니다. OCI 호환 컨테이너 이미지를 지원하고, 이 또한 역시 runc 기반의 OCI 호환 컨테이너 런타임입니다.

->Container 안정성이 커졌으며 Docker보다 가볍기 때문에 사용합니다.

 

gVisitor : 구글에서 컨테이너 격리와 관련된 보안 문제를 해결하기 위해 gVisitor을 출시하였으며 샌드박스 컨테이너를 실행하는 runsc를 기반으로 새로운 공간 커널로 컨테이너를 실행하여 오버헤드를 낮추고, 보안성이 올라갔습니다. 커널을 부분적으로 공유하기 때문에 퍼포먼스 속도는 느릴 수밖에 없습니다.

->느린 속도이지만, 높은 보안을 제공하는 tradeoff가 있는 런타임입니다.

 

 

 틀린 정보는 댓글 부탁드립니다.