컨테이너 한방 정리

인프런 [쿠버네티스 어나더 클래스] 강의를 보고 정리한 글

---

1. 컨테이너란?

호스트 OS에 격리된 공간을 만들고, 그 안에서 독립된 프로세스를 실행하는 기술

컨테이너가 격리하는 것들:

• 파일 → chroot
• 자원(CPU, Memory) → cgroup
• 프로세스 / 유저 / 네트워크 → namespace

이 세 가지 Linux 커널 기능이 컨테이너의 핵심이다. Docker 이전에도 LXC(LinuX Container)가 이 기술을 사용했고, Docker는 LXC를 기반으로 만들어졌다.

---

2. Linux OS 계보

UNIX (최초)
 └── Linux (무료, 1991)
      ├── Debian → Ubuntu (편의기능 추가)
      └── Red Hat (유료)
           ├── Fedora (개발버전, 무료)
           └── RHEL (안정화, 유료)
                └── CentOS (RHEL 무료 복제판)
                     └── CentOS 8 → 2021 종료
                         CentOS 7 → 2024 종료
                              └── Rocky Linux / AlmaLinux (복제, 무료)

CentOS가 종료되면서 그 대안으로 Rocky Linux와 AlmaLinux가 등장했다. 둘 다 RHEL을 그대로 복제한 무료 버전이라 기업 환경에서 많이 쓰인다.

---

3. 계층 구조로 이해하는 서버

[ Spring Boot 앱 ]
       ↑
[ Tomcat (WAS) ]       ← 미들웨어. Java 앱 실행
       ↑
[ Nginx (웹서버) ]     ← 앞단 리버스 프록시 (선택)
       ↑
[ Linux OS ]           ← 운영체제
       ↑
[ 하드웨어 / VM / 컨테이너 ]

• Linux OS = 모든 것의 기반
• Tomcat = Linux 위에서 실행되는 Java 서블릿 컨테이너 (WAS)
• Nginx = 정적 파일 제공 + 리버스 프록시 (웹서버)

---

4. Docker Engine 내부 구조

Docker CLI (docker run, docker-compose up ...)
         ↓
    [ dockerd ]  ← 메인 데몬. CLI/API, Build, Network, Storage, Logs 등 담당
         ↓
  [ containerd ]  ← 컨테이너 생명주기 관리 (High Level 런타임)
         ↓
    [ runC ]      ← 실제 컨테이너 생성, OS 커널 호출 (Low Level 런타임)
         ↓
  [ Linux Kernel ] ← chroot + cgroup + namespace

docker run 한 번 치면 이 과정이 전부 자동으로 일어난다.

---

5. 컨테이너 런타임이란?

컨테이너를 실제로 실행시켜주는 엔진을 컨테이너 런타임이라고 한다.

구분	이름	역할
High Level	containerd	이미지 pull, 컨테이너 생명주기 관리
High Level	Docker Engine	containerd를 감싼 형태
High Level	CRI-O	Kubernetes 전용 경량 런타임
Low Level	runC	실제 컨테이너 생성, OS 커널 직접 호출

 

---

6. Kubernetes에서 Docker가 제거된 이유

과거 (v1.20 이전)

Kubernetes → Docker → containerd → runC

Kubernetes가 컨테이너를 띄우려면 Docker를 거쳐야 했다.

문제

 

• Docker가 CRI를 구현하지 않았다 Kubernetes는 런타임과 통신하는 표준 인터페이스 CRI를 만들었는데, Docker는 이를 지원하지 않았다. 그래서 Kubernetes가 직접 dockershim이라는 변환 레이어를 만들어야 했다.
• dockershim 유지보수 부담 dockershim은 원래 임시방편으로 만든 것인데, 시간이 지나면서 CNCF 생태계 여러 도구들이 dockershim에 의존하게 됐고 취약한 코드가 쌓였다. Kubernetes 관리자들이 계속 유지보수해야 하는 부담이 커졌다.
• 새로운 기능 개발이 막혔다 cgroups v2, user namespace 같은 새 기능들이 dockershim과 호환되지 않아서 발전이 막혔다.
• 대안이 충분히 성숙해졌다 containerd, CRI-O 같이 CRI를 직접 구현하는 런타임들이 이미 안정화됐다.

 

 

해결

• v1.20: Docker Deprecated 경고
• v1.24: dockershim 제거 (Docker 자체가 아니라, Kubernetes 내장 Docker 연결 레이어가 제거된 것)

v1.24 이후 Kubernetes의 컨테이너 런타임 연결 방식:

# 기본 (별도 설치 필요 없음)
kubelet → CRI(grpc) → containerd → runC
kubelet → CRI(grpc) → CRI-O     → runC

# Docker를 계속 쓰고 싶다면 (cri-dockerd 별도 설치 필요)
kubelet → CRI(grpc) → cri-dockerd → Docker → runC

cri-dockerd는 Mirantis가 만든 외부 프로젝트로, dockershim이 제거된 후에도 Docker를 Kubernetes와 연결하고 싶을 때 따로 설치해서 쓴다. 하지만 실무에서는 굳이 cri-dockerd까지 쓰는 경우는 드물고, 그냥 containerd를 기본 런타임으로 쓰는 게 일반적이다.

 

개발자 입장에서는 전혀 상관없다. Docker로 만든 이미지 형식(OCI 표준)은 그대로 호환된다.

 

ai로 정리한거라 틀린게 있을수도 있음..