[쿠버네티스] 쿠버네티스와 컨테이너 역사

본 글은 인프런 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2을 직접 정리한 내용입니다:)

◼️ 리눅스 흐름으로 이해하는 컨테이너

🟢 정리

1. 주로 사용하는 리눅스에는 Debian과 RedHat 계열이 있다.
2. 쿠버네티스 설치도 크게 이 두 가지 계열을 지원한다.
3. RedHat 계열의 하나인 CentOS는 곧 종료가 된다(됐다).
4. Rocky Linux는 CentOS의 대체재 중 하나다.

결론: Rocky Linux는 쿠버네티스 설치할 때 Redhat 계열을 보면 된다.

Linux OS

 

 

🟢 컨테이너 오케스트레이션

1. App을 컨테이너에 담아서 배포한다.
2. 시스템 운영 노하우를 많이 가지고 있다.

⚪️ 정리

• Kubernetes는 현재 표준을 넘어 여러 분야에서 활용되고 있다.
• Kubernetes는 컨테이너를 더 쉽게 사용 할 수 있게 해준다.
• 컨테이너는 Kubernetes와의 인터페이스가 중요하다.

◼️ 쿠버네티스 흐름으로 이해하는 컨테이너

🔶 컨테이너 런타임

이는 컨테이너를 생성해주는 역할을 한다.

Low Level

• LXC(LinuX Container): 커널레벨의 기술을 가지고 만든 Low Level 컨테이너 런타임
• libcontainer: 도커가 만든 LXC기반 컨테이너 런타임

High Level

• Docker: libcontainer를 사용자 친화적으로 만든 컨테이너 런타임

Docker는 App들을 독립적 환경에서 띄울려고 사용한다.

LXC는 운영체제를 컨테이너 가상화로 나누기 위한 목적이다.

kube-apiserver: 쿠버네티스로 보내는 모든 API를 받는다.

kublet: 컨테이너 런타임에 명령을 날린다. (컨테이너런타임이 받을 수 있는 형태의 Api 호출)

 

그런데 위 구조(V1.0)는, 런타임이 늘어날 때마다 kublet 소스를 건드려야하는 구조이다.따라서 이를 해결하려면 구조를 바꿔야한다.

 

 

🔶 Docker와 Kubernetes 통합: CRI 도입부터 cri-dockerd까지

• Docker v1.0: Docker가 처음으로 API를 제공하여 개발자들이 쉽게 컨테이너를 관리하고 사용할 수 있게 됨.
• Docker v1.5: Kubernetes와 함께 사용하기 위해 Docker가 CRI(Container Runtime Interface)라는 표준을 따르는 dockershim이라는 기능을 추가하여, Kubernetes에서 Docker 컨테이너를 쉽게 실행할 수 있게 함.
• Docker v1.23: Mirantis가 Docker를 인수한 후, 기존의 dockershim을 별도의 컨테이너로 분리한 cri-dockerd라는 어댑터를 개발하여 Kubernetes와의 통합을 더욱 간편하게 만듦.

🔶 컨테이너 런타임 표준화: OCI와 CRI

• OCI (Open Container Initiative): 다양한 컨테이너 런타임을 표준화하기 위해, 컨테이너 생성 시 따라야 할 규약 관리 표준
• runC: Docker는 OCI 규격에 맞추기 위해 runC라는 low-level 런타임을 개발했고, 이를 containerd에서도 사용하도록 변경함.

🔶 Kubernetes와 CRI의 발전

• libcontainer와 runc: Docker는 LXC를 사용하지 않고 커널 레벨의 가상화 기술을 직접 사용함.
• Kubernetes에서 컨테이너 런타임이 바뀔 때마다 CRI 구현체가 수정되어야 하는 문제를 해결하기 위해 CRI-Plugin 기능이 추가됨.
• cri-o: Red Hat이 CRI 규격에 맞춰 개발한 런타임, 태생부터 Kubernetes와의 호환성을 고려해 설계됨.

전체 흐름도

컨테이너 런타임

본 글은 인프런 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 을 직접 정리한 내용입니다:)