(1) 컨테이너 한방 정리 - Linux, Container, Container Orchestration, Kernel, kubelet

 

⚓ 쿠버네티스 어나더 클래스 (지상편) - Spring 1, 2 을 듣고 작성하는 복습 블로그 입니다.

 

 

[리눅스 흐름으로 이해하는 컨테이너]

출처URL : https://inf.run/k7mF

1. 리눅스 배포판 선택

1-1. 리눅스(Linux) 란 ?

리눅스는 컴퓨터 운영체제(OS) 중 하나이다. 

쉽게 말해서 컴퓨터 하드웨어와 소프트웨어를 연결해주는 시스템이다.

 

1-2. 리눅스 기반 여러 배포판 

리눅스를 사용하기 위해서 여러 배포판 중 하나를 선택해서 사용할 수 있는데, 크게 두 가지로 나뉜다.

1. Debian 계열 : 무료 (커뮤니티용)

2. Redhat 계열 : 유료 (기업용)

 

1-3. Debian 계열

Debian 은 무료로 사용할 수 있는 리눅스 기반 배포판이다. 

이 Debian 에 편의기능을 추가해서 사용 편의서을 높인 배포판이 바로 Ubuntu 로, 현재 가장 널리 사용된다.

 

1-4. Redhat 계열

먼저, Redhat 기반 linux 배포판이 생성되는 순서에 대해서 알아보자

fedora linux -> redhat linux -> CentOS 순서로 배포판이 만들어진다.

• fedora linux : 최신 기능과 기술을 실험하고 개발하는 버전 (무료)
• redhat linux : fedora 에서 검증되고 안정화된 기능을 기반으로 한 기업용 배포판 (유료, 보통 기업들이 사용)
• CentOS : redhat linux 의 복제판, 유지보수를 직접 할 여력이 되는 기업이 보통 사용 (무료)

이지만, centos 가 종료되었다. 🔚

 

그렇기 때문에 centos 를 대체하기 위해서

1. redhat linus 로 전환
2. CentOS 버전에 대한 기술 지원 유지
3. 타 OS 로 마이그레이션 스크립트 제공하여 이전
4. CentOS 와 비슷한 복제 버전 선택 (Rocky Linux, AlmaLinux)

4가지의 방법 중 하나를 선택해야 한다.

 ⇒ 강의에서는 Rocky Linux 를 대체 배포판으로 선택했다.

 

---

 

2. Container

 

2-1. LXC

LXC 는 리눅스의 커널 기능들을 조합해서 만든 최초의 컨테이너 기술이다.

2008년에 등장했으며 아래의 리눅스 커널 기능들이 결합되어 컨테이너 환경을 구성했다.

• chroot : 유저, 파일, 네트워크 격리
• cgroup : 자원격리 (cpu, memory) 
• namespace : 프로세스 격리 

이런 기능들로 경량화된 가상화 기술의 시초가 되었다.

 

2-2. docker

LXC 를 기반으로 docker 가 등장했다. 

하지만, root 권한으로 설치하고 실행을 해야하기 때문에 보안이 취약할 수도 있다는 단점이 존재했지만

rootless 설치 모드의 등장으로 보안이 강화되었다.

 

2-3. rkt

rkt는 CoreOS에서 만든 컨테이너 런타임이였지만, CoreOS가 Red Hat에 인수되고,

Red Hat은 Kubernetes에 최적화된 런타임인 CRI-O 개발에 집중하면서 rkt 는 입지를 잃고 개발도 종료됐다.

 

---

 

3. Container Orchestration

Container Orchestrantion 은 여러 개의 컨테이너를 효율적으로 관리하고 자동화하는 기술이다. 

자동으로 배포, 관리, 확장, 복구 등의 기능을 제공하며 복잡한 시스템을 안정적이고 효율적으로 운영할 수 있게 해준다.

 

3-1. Kubernetes

Docker 가 등장하면서 컨테이너 사용이 대중화 되었다. 

이 후 컨테이너를 효율적으로 관리하기 위한 오케스트레이션 도구들이 등장했고,

그 중 Kubernetes(K8s) 가 가장 빠르게 주목받고 성장했다.

시간이 지나면서 K8s 는 사실상 표준으로 자리를 잡았고, 이후 어떤 컨테이너 런타임이 K8s와 잘 맞는가가 중요한 경쟁 요소가 되었다.

 

3-2. container

K8s가 중심이 되면서, Docker 외에 새로운 컨테이너 런타임들이 등장했다. 

가장 대표적인 컨테이너는 아래와 같다.

1. containerd : Docker 에서 분리되어 만들어진 범용 컨테이너 런타임
2. CRI-O : Red Hat 주도로 개발된 K8s에 최적화된 경량 컨테이너 런타임

---

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

출처URL : https://inf.run/k7mF

1. Contanier runtime

container runtime 에는 High Level (사용자 친화적) 과 Low Level (기계 친화적) 이 있다.

 

1-1. Low Level

• LXC (최초의 컨테이너) : Low Level 컨테이너 런타임
• libcontainer : docker 가 LXC 를 기반으로 만든 Low Level 컨테이너 런타임
• rkt : docker 보다 보안에는 좋지만, Low Level 이라 사용자에게 잊혀지고 있다

 

1-2. High Level

• docker : libcontainer 를 사용해서 만든 High Level 컨테이너 런타임
  dockerd -> containerd -> libcontainer -> runC
  dockerd : CLI 나 Log 등 다양한 부가 기능
  containerd : 컨테이너를 만들어주는 역할
• docker vs LXC
  docker → App 들을 독립적인 환경에서 띄울려고 사용 (for APP)
  LXC → 운영체제를 컨테이너 가상화로 나누기 위한 목적 (for OS)
  각각 컨테이너를 만들어주지만 그 목적이 다르다

 

---

 

2. Container Orchestration

 

2-1. 💬 Pod 안에 컨테이너 두 개를 만들라는 명령이 왔을 때의 흐름

 

kube-apiserver

• k8s 로 들어오는 모든 API 를 받는다
• 🤔 현재 받은 API 가 Pod 생성에 관련된 내용이니깐 ,,, 이걸 담당하는 kubelet 하나에 전달해

 

kubelet

• Pod 내용을 까보니깐 컨테이너가 두개네
• 각 컨테이너 생성 요청을 컨테이너 런타임에 전달한다.
  💬 "컨테이너 두 개 생성해줘!" → 2번 요청

 

Container Runtime

• 실질적으로 컨테이너를 생성하는 역할
• 요청을 받아 컨테이너를 생성한다.
• 결과적으로 컨테이너를 생성해주는 역할을 하는게 컨테이너 런타임이고, 컨테이너는 생성물

 

 

2-2. 컨테이너 런타임을 변경하면 이미지를 다시 만들어야할까?

🙅‍♀️ 안 만들어도 된다.

 

이유는 표준화 덕분이다. 

컨테이너 기술이 다양해지면서 표준의 필요성이 대두되었고, 그래서 OCI 가 만들어졌다. 

OCI 는 이미지 사양, 런타임 사양 등을 정의했고, 이 규약을 따르면, 서로 다른 컨테이너 런타임 간 이미지 공유가 가능하다. 

 

예시

• Docker는 OCI 표준을 맞추기 위해 runC라는 low-level 런타임 도구를 만듦.
• containerd도 내부적으로 runC를 사용.
• runC는 LXC 대신 커널 레벨의 가상화 기술을 사용하여 더 직접적인 접근 제공.

 

---

 

3. kubelet 과 컨테이너 런타임의 관계 변화

 

3-1. kublet 의 역할

• Pod 정의를 받아서, 실제 컨테이너 런타임에 컨테이너 생성 요청을 전달하는 역할
• 런타임이 이해할 수 있는 형태의 API 를 호출한다.

 

3-2. k8s 1.0 버전 (초기 구조)

• kubelet 내부에 컨테이너 런타임별 분기 로직 (ex. case문) 내장
  docker, rkt 등 런타임을 직접 구분하여 API 호출.
• 문제점: 런타임이 늘어날수록 kubelet 소스를 계속 수정해야 한다.
  -> 유지보수 어렵고, 확장성 부족.

 

 

3-3. k8s 1.5 버전 

• CRI (Container Runtime Interface) 도입.
  • kubelet ↔ 런타임 사이에 표준 인터페이스 계층 생성
  • kubelet은 오직 CRI 인터페이스에만 의존한다. 
• 실제 런타임 호출은 CRI의 구현체에서 수행
  예: dockershim, cri-o, containerd 등
• 런타임을 바꿔도 kubelet 수정 없이 CRI 구현체만 바꾸면 된다.

 

 

3-4. k8s 1.24 버전

• K8s 가 공식적으로 dockershim 을 제거했다.
• 대신 Mirantis 가 docker 를 인수하고 cri-dockerd 라는 외부 어댑터를 만들어서 docker 연동을 계속 지원했다. 
  ⇒ 미란티스 컨테이너 런타임
• 이유 : docker 에 새 기능이 생기면 k8s 도 같이 패치를 해야 했기 때문에
  → 컨테이너 런타임이 변경될 때마다 CRI 의 구현체도 수정을 해야함
• kubelet 에서 컨테이너 런타임으로 바로 받을 수 있도록 구조를 변경
• 이 구조를 지원하기 위해서 containerd 에 CRI-Plugin 기능 추가
• cri-o 는 태생부터 redhat 이 규격을 맞춰서 만든 런타임

⇒ 1.27 버전에서 이걸 기반으로 POD 를 만든다